diff options
Diffstat (limited to 'bip-0141.mediawiki')
| -rw-r--r-- | bip-0141.mediawiki | 107 |
1 files changed, 61 insertions, 46 deletions
diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index a73cf35..8fdc795 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -48,7 +48,7 @@ A new <code>wtxid</code> is defined: the double SHA256 of the new serialization Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization. -The <code>marker</code> MUST be <code>0x00</code>. +The <code>marker</code> MUST be a 1-byte zero value: <code>0x00</code>. The <code>flag</code> MUST be a 1-byte non-zero value. Currently, <code>0x01</code> MUST be used. @@ -60,28 +60,30 @@ A non-witness program (defined hereinafter) txin MUST be associated with an empt A new block rule is added which requires a commitment to the <code>wtxid</code>. The <code>wtxid</code> of coinbase transaction is assumed to be <code>0x0000....0000</code>. -A witness root hash is calculated with all those <code>wtxid</code> as leaves, in a way similar to the hashMerkleRoot in the block header. +A <code>witness root hash</code> is calculated with all those <code>wtxid</code> as leaves, in a way similar to the <code>hashMerkleRoot</code> in the block header. -The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is: +The commitment is recorded in a <code>scriptPubKey</code> of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is: 1-byte - OP_RETURN (0x6a) 1-byte - Push the following 36 bytes (0x24) 4-byte - Commitment header (0xaa21a9ed) - 32-byte - Commitment hash: Double-SHA256(witness root hash|witness nonce) + 32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value) 39th byte onwards: Optional data with no consensus meaning -and the coinbase's input's witness must consist of a single 32-byte array for the witness nonce. +and the coinbase's input's witness must consist of a single 32-byte array for the <code>witness reserved value</code>. -If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment. +If there are more than one <code>scriptPubKey</code> matching the pattern, the one with highest output index is assumed to be the commitment. + +If all transactions in a block do not have witness data, the commitment is optional. === Witness program === -A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". +A <code>scriptPubKey</code> (or <code>redeemScript</code> as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig: -# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty. -# Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript. +# Triggered by a <code>scriptPubKey</code> that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. (''"native witness program"'') +# Triggered when a <code>scriptPubKey</code> is a P2SH script, and the BIP16 <code>redeemScript</code> pushed in the <code>scriptSig</code> is exactly a push of a version byte plus a push of a witness program. The <code>scriptSig</code> must be exactly a push of the BIP16 <code>redeemScript</code> or validation fails. (''"P2SH witness program"'') If the version byte is 0, and the witness program is 20 bytes: * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program. @@ -91,14 +93,14 @@ If the version byte is 0, and the witness program is 20 bytes: If the version byte is 0, and the witness program is 32 bytes: * It is interpreted as a pay-to-witness-script-hash (P2WSH) program. -* The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript"). -* The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program. -* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item). +* The witness must consist of an input stack to feed to the script, followed by a serialized script (<code>witnessScript</code>). +* The <code>witnessScript</code> (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the <code>witnessScript</code> must match the 32-byte witness program. +* The <code>witnessScript</code> is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item). * The script must not fail, and result in exactly a single TRUE on the stack. -If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail. +If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.<ref>For example, a scriptPubKey with OP_0 followed by a 40-byte non-zero data push will fail due to incorrect program size. However, a scriptPubKey with OP_0 followed by a 41-byte non-zero data push will pass, since it is not considered to be a witness program</ref> -If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions. +If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.<ref>For backward compatibility, for any version byte from 0 to 16, the script must fail if the witness program has a <code>CastToBool</code> value of zero. However, having a hash like this is a successful preimage attack against the hash function, and the risk is negligible.</ref> === Other consensus critical limits === @@ -106,17 +108,23 @@ If the version byte is 1 to 16, no further interpretation of the witness program Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows: -''Block cost'' is defined. The cost of each byte in the existing header and transactions is 4, while the cost of each byte in witness data is 1. +''Block cost'' is defined as ''Base size'' * 3 + ''Total size''. (rationale<ref>Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.</ref>) + +''Base size'' is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node. -The new rule is total ''block cost'' ≤ 4,000,000. +''Total size'' is the block size in bytes with transactions serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data. + +The new rule is ''block cost'' ≤ 4,000,000. ==== Sigops ==== Sigops per block is currently limited to 20,000. We change this restriction as follows: -''Sigop cost'' is defined. The cost of a sigop in traditional script is 4, while the cost of a sigop in witness program is 1. +Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value. +The sigop limit is likewise quadrupled to ≤ 80,000. -The new rule is total ''sigop cost'' ≤ 80,000. +In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script. +That is, CHECKSIG in a witness program is counted as only 1 sigop, and CHECKMULTISIG in a witness program is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program. == Examples == @@ -126,8 +134,8 @@ The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) wit witness: <signature> <pubkey> scriptSig: (empty) - scriptPubKey: 0 <20-byte-hash> - (0x0014{20-byte-hash}) + scriptPubKey: 0 <20-byte-key-hash> + (0x0014{20-byte-key-hash}) The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program. @@ -137,6 +145,24 @@ The signature is verified as Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness. +=== P2WPKH nested in BIP16 P2SH === + +The following example is the same P2WPKH witness program, but nested in a BIP16 P2SH output. + + witness: <signature> <pubkey> + scriptSig: <0 <20-byte-key-hash>> + (0x160014{20-byte-key-hash}) + scriptPubKey: HASH160 <20-byte-script-hash> EQUAL + (0xA914{20-byte-script-hash}87) + +The only item in scriptSig is hashed with HASH160, compared against the 20-byte-script-hash in scriptPubKey, and interpreted as: + + 0 <20-byte-key-hash> + +The P2WPKH witness program is then executed as described in the previous example. + +Comparing with the previous example, the scriptPubKey is 1 byte bigger and the scriptSig is 23 bytes bigger. Although a nested witness program is less efficient, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0. + === P2WSH witness program === The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program. @@ -158,13 +184,13 @@ A P2WSH witness program allows arbitrarily large script as the 520-byte push lim The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 2<sup>80</sup> work is not infeasible anymore (By the end of 2015, 2<sup>84</sup> hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness. -=== Witness program nested in BIP16 P2SH === +=== P2WSH nested in BIP16 P2SH === The following example is the same 1-of-2 multi-signature P2WSH witness program, but nested in a BIP16 P2SH output. witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> scriptSig: <0 <32-byte-hash>> - (0x0020{32-byte-hash}) + (0x220020{32-byte-hash}) scriptPubKey: HASH160 <20-byte-hash> EQUAL (0xA914{20-byte-hash}87) @@ -174,18 +200,17 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte- The P2WSH witness program is then executed as described in the previous example. -Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0. +Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig. === Extensible commitment structure === -The new commitment in coinbase transaction is a hash of the witness root hash and a witness nonce. The nonce currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in -coinbase becomes: +The new commitment in coinbase transaction is a hash of the <code>witness root hash</code> and a <code>witness reserved value</code>. The <code>witness reserved value</code> currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in coinbase becomes: - Double-SHA256(Witness root hash|Hash(new commitment|witness nonce)) + Double-SHA256(Witness root hash|Hash(new commitment|witness reserved value)) -For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way. +For backward compatibility, the <code>Hash(new commitment|witness reserved value)</code> will go to the coinbase witness, and the <code>witness reserved value</code> will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way. -Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the witness nonce to preserve the ability to do upgrades of the Bitcoin consensus protocol. +Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the <code>witness reserved value</code> to preserve the ability to do upgrades of the Bitcoin consensus protocol. The optional data space following the commitment also leaves room for metadata of future softforks, and MUST NOT be used for other purpose. @@ -249,33 +274,23 @@ As a soft fork, older software will continue to operate without modification. N == Deployment == -We reuse the double-threshold IsSuperMajority() switchover mechanism used in -BIP65 with the same thresholds, but for nVersion = 5. The new rules are -in effect for every block (at height H) with nVersion = 5 and at least -750 out of 1000 blocks preceding it (with heights H-1000..H-1) also -have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks -preceding a block do have nVersion >= 5, nVersion < 5 blocks become -invalid, and all further blocks enforce the new rules. +This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit 1. -(It should be noted that BIP9 involves permanently setting a high-order bit to -1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus -no bits in nVersion are permanently lost.) +For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD). -=== SPV Clients === - -While SPV clients are unable to fully validate blocks, -they are able to validate block headers and, thus, can check block version and proof-of-work. -SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have -nVersion >= 5 to prevent false confirmations from the remaining 5% of -non-upgraded miners when the 95% threshold has been reached. +For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800). == Credits == Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. +== Footnotes == + +<references /> + == Reference Implementation == -https://github.com/sipa/bitcoin/commits/segwit +https://github.com/bitcoin/bitcoin/pull/7910 == References == |