diff options
| -rw-r--r-- | bip-0011.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0016.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0061.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0098.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0116.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0117.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0143.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0157.mediawiki | 2 |
8 files changed, 12 insertions, 12 deletions
diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index bb0a308..e5052eb 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -38,7 +38,7 @@ OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig: (OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack). -The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes. +The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes. ==Rationale== diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index d5d39ef..ba828e1 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -101,7 +101,7 @@ If a majority of hashing power does not support the new validation rules, then r ===520-byte limitation on serialized script size=== -As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. +As a consequence of the requirement for backwards compatibility the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. ==Reference Implementation== diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki index 1e3d41f..b08739d 100644 --- a/bip-0061.mediawiki +++ b/bip-0061.mediawiki @@ -83,7 +83,7 @@ the reject message, "client" is the peer that will receive the message. ==== reject version codes ==== -Codes generated during the intial connection process in response to a "version" message: +Codes generated during the initial connection process in response to a "version" message: {| | Code || Description diff --git a/bip-0098.mediawiki b/bip-0098.mediawiki index 118a8e2..8540d1a 100644 --- a/bip-0098.mediawiki +++ b/bip-0098.mediawiki @@ -57,8 +57,8 @@ The following image depicts an example unbalanced hash-tree: '''A''', '''B''', and '''C''' are leaf labels, 32-byte double-SHA256 hashes of the data associated with the leaf. '''Node''' and '''Root''' are inner nodes, whose labels are fast-SHA256 (defined below) hashes of their respective children's labels. -'''Node''' is labelled with the fast-SHA256 hash of the concatination of '''B''' and '''C'''. -'''Root''' is labelled with the fast-SHA256 hash of the concatination of '''A''' and '''Node''', and is the ''Merkle root'' of the tree. +'''Node''' is labelled with the fast-SHA256 hash of the concatenation of '''B''' and '''C'''. +'''Root''' is labelled with the fast-SHA256 hash of the concatenation of '''A''' and '''Node''', and is the ''Merkle root'' of the tree. Nodes with single children are not allowed. The ''double-SHA256'' cryptographic hash function takes an arbitrary-length data as input and produces a 32-byte hash by running the data through the SHA-256 hash function as specified in FIPS 180-4[3], and then running the same hash function again on the 32-byte result, as a protection against length-extension attacks. @@ -96,7 +96,7 @@ The application of fast-SHA256 to inner node label updates is safe in this limit so the sorts of attacks prevented by message padding and double-hashing do not apply. The 'initialization vector' for fast-SHA256 is changed in order to prevent a category of attacks on higher level protocols where a partial collision can serve as both a leaf hash and as an inner node commitment to another leaf hash. -The IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatability with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported. +The IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatibility with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported. The data hashed is a nothing-up-my-sleeve number that is unlikely to have a known hash preimage. The prime 23 was chosen as the leading fractional bits of the first eight (8) primes, two (2) through nineteen (19), are constants used in the setup of SHA-256 itself. Using the next prime in sequence reduces the likelihood of introducing weakness due to reuse of a constant factor. diff --git a/bip-0116.mediawiki b/bip-0116.mediawiki index 7f103ec..86b0f9a 100644 --- a/bip-0116.mediawiki +++ b/bip-0116.mediawiki @@ -69,7 +69,7 @@ A source of malleability in Merkle proofs could potentially lead to spend vulner For example, a compact 2-of-N policy could be written by using MERKLEBRANCHVERIFY to prove that two keys are extracted from the same tree, one at a time, then checking the proofs for bitwise equality to make sure the same entry wasn't used twice. With the vulnerable Merkle tree implementation there are privledged positions in unbalanced Merkle trees that allow multiple proofs to be constructed for the same, single entry. -BIP141 (Segregated Witness)[3] provides support for a powerful form of scirpt upgrades called script versioning, which is able to achieve the sort of upgrades which would previously have been hard-forks. +BIP141 (Segregated Witness)[3] provides support for a powerful form of script upgrades called script versioning, which is able to achieve the sort of upgrades which would previously have been hard-forks. If script versioning were used for deployment then MERKLEBRANCHVERIFY could be written to consume its inputs, which would provide a small 2-byte savings for many anticipated use cases. However the more familiar NOP-expansion soft-fork mechanism used by BIP65 (CHECKLOCKTIMEVERIFY)[5] and BIP112 (CHECKSEQUENCEVERIFY)[6] was chosen over script versioning for the following two reasons: @@ -99,7 +99,7 @@ The low-order bit of the first parameter, 2, is clear, meaning that there is one As described by Pieter Wuille[8] the 1-of-N scheme is particularly useful for constructing honeypots. The desire is to put a large bounty on a server, larger than the value of the server itself so that if the server is compromised it is highly likely that the hacker will claim the bitcoin, thereby revealing the intrusion. However if there are many servers, e.g. 1,000, it becomes excessively expensive to lock up separate bounties for each server. -It would be desireable if the same bounty was shared across multiple servers in such a way that the spend would reveal which server was compromised. +It would be desirable if the same bounty was shared across multiple servers in such a way that the spend would reveal which server was compromised. This is accomplished by generating 1,000 different keys, building a hash tree of these public keys, and placing each key and associated Merkle path on separate servers. When the honeypot is claimed, the (previous) owner of the coins can tell which server was compromised from the key and path used to claim the funds. diff --git a/bip-0117.mediawiki b/bip-0117.mediawiki index f4d1b4a..4b5706e 100644 --- a/bip-0117.mediawiki +++ b/bip-0117.mediawiki @@ -48,7 +48,7 @@ If the above conditions hold except for the last one, such that: then the top-most element of the main stack is dropped, and the N=2 (<code>0x51</code>) to 17 (<code>0x60</code>) further elements are popped from the main stack, continuing from the alt stack if the main stack is exhausted, -and concatinated together in reverse order to form a serialized script, +and concatenated together in reverse order to form a serialized script, which is then executed with the remaining elements of both stacks remaining in place as inputs. The presence of CHECKSIG or CHECKMULTISIG within the subscript do not count towards the global MAX_BLOCK_SIGOPS_COST limit, diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index c1332b3..ed07c82 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -67,7 +67,7 @@ The item 6 is a 8-byte value of the amount of bitcoin spent in this input. <code>hashOutputs</code>: *If the sighash type is neither <code>SINGLE</code> nor <code>NONE</code>, <code>hashOutputs</code> is the double SHA256 of the serialization of all output amount (8-byte little endian) with <code>scriptPubKey</code> (serialized as scripts inside CTxOuts); *If sighash type is <code>SINGLE</code> and the input index is smaller than the number of outputs, <code>hashOutputs</code> is the double SHA256 of the output amount with <code>scriptPubKey</code> of the same index as the input; -*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>.<ref>In the original algorithm, a <code>uint256</code> of <code>0x0000......0001</code> is committed if the input index for a <code>SINGLE</code> signature is greater than or equal to the number of outputs. In this BIP a <code>0x0000......0000</code> is commited, without changing the semantics.</ref> +*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>.<ref>In the original algorithm, a <code>uint256</code> of <code>0x0000......0001</code> is committed if the input index for a <code>SINGLE</code> signature is greater than or equal to the number of outputs. In this BIP a <code>0x0000......0000</code> is committed, without changing the semantics.</ref> The <code>hashPrevouts</code>, <code>hashSequence</code>, and <code>hashOutputs</code> calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n). @@ -303,7 +303,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac ^^ - (please note that the not-yet-exectued OP_CODESEPARATOR is not removed from the scriptCode) + (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode) preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000 sigHash: 82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391 public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae diff --git a/bip-0157.mediawiki b/bip-0157.mediawiki index 61ffc7e..565a941 100644 --- a/bip-0157.mediawiki +++ b/bip-0157.mediawiki @@ -468,4 +468,4 @@ Golomb-Rice Coded sets: https://github.com/Roasbeef/btcutil/tree/gcs/gcs == Copyright == -This document is licensed under the Creative Commons CC0 1.0 Universal lisence. +This document is licensed under the Creative Commons CC0 1.0 Universal license. |