diff options
| -rw-r--r-- | README.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0141.mediawiki | 88 | ||||
| -rw-r--r-- | bip-0142.mediawiki | 178 | ||||
| -rw-r--r-- | bip-0143.mediawiki | 8 | ||||
| -rw-r--r-- | bip-0144.mediawiki | 2 |
5 files changed, 138 insertions, 142 deletions
diff --git a/README.mediawiki b/README.mediawiki index 9c28fc1..1ce3a76 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -423,13 +423,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- | [[bip-0142.mediawiki|142]] -| Address Formats for Witness Program +| Address Format for Segregated Witness | Johnson Lau | Standard | Draft |- | [[bip-0143.mediawiki|143]] -| Transaction signature verification for version 0 and version 1 witness program +| Transaction Signature Verification for Version 0 Witness Program | Johnson Lau, Pieter Wuille | Standard | Draft diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 6474256..74fbf0f 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -61,18 +61,22 @@ New rules for scriptSig: * In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty. * In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript. -If the version byte is 0, the witness program is the actual script: -* The script is executed after normal script evaluation but with data from the witness rather than the scriptSig. -* The program must not fail and must result in exactly a single TRUE on the stack. - -If the version byte is 1, the witness program must be 32 bytes, as a SHA256 hash of the actual script: -* The witness must consist of an input stack to feed to the program, followed by the serialized program. -* The serialized program is popped off the initial witness stack. SHA256 of the serialized program must match the hash pushed in the witness program. -* The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack. +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. +* The witness must consist of exactly 2 items. The first one is a signature, and the second one is a public key. +* HASH160 of the public key must match the 20-byte witness program. +* After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack. + +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. +* The serialized script is popped off the initial witness stack. SHA256 of the serialized script must match the 32-byte witness program. +* The serialized script is deserialized, and executed after normal script evaluation with the remaining witness stack. * The script must not fail, and result in exactly a single TRUE on the stack. -* If the witness program is between 2 and 31 bytes, the script must fail. -If the version byte is 2 to 16, no further interpretation of the witness program or witness happens. +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 1 to 16, no further interpretation of the witness program or witness happens. === Other consensus critical limits === @@ -94,35 +98,33 @@ The new rule is total ''sigop cost'' ≤ 80,000. == Examples == -=== Version 0 witness program === +=== P2WPKH witness program === -The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output. +The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) witness program: witness: <signature> <pubkey> scriptSig: (empty) - scriptPubKey: 0 <DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG> - (0x001976A914{20-byte-hash}88AC) - -The '0' indicates the following push is a version 0 witness program. The witness program is deserialized and becomes: + scriptPubKey: 0 <20-byte-hash> + (0x0014{20-byte-hash}) - DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG +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. -The script is executed with the data from witness +The signature is verified as - <signature> <pubkey> DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG + <signature> <pubkey> CHECKSIG -Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness. +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. -=== Version 1 witness program === +=== P2WSH witness program === -The following example is an 1-of-2 multi-signature version 1 witness program. +The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program. witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> scriptSig: (empty) - scriptPubKey: 1 <32-byte-hash> - (0x5120{32-byte-hash}) + scriptPubKey: 0 <32-byte-hash> + (0x0020{32-byte-hash}) -The '1' in scriptPubKey indicates the following push is a version 1 witness program. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized: +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 P2WSH type. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized: 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG @@ -130,27 +132,27 @@ The script is executed with the remaining data from witness: 0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG -Since the actual program is larger than 32 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed. +A P2WSH witness program allows arbitrarily large script as the 520-byte push limit is bypassed. -The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of 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 P2SH output but is moved to witness. +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 Pay-to-Script-Hash === +=== Witness program nested in BIP16 P2SH === -The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output. +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: <1 <32-byte-hash>> - (5120{32-byte-hash}) + scriptSig: <0 <32-byte-hash>> + (0x0020{32-byte-hash}) scriptPubKey: HASH160 <20-byte-hash> EQUAL - (0x76A914{20-byte-hash}88AC) + (0xA914{20-byte-hash}87) The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash in scriptPubKey, and interpreted as: - 1 <32-byte-hash> + 0 <32-byte-hash> -The version 1 witness program is then executed as described in the last example +The P2WSH witness program is then executed as described in the previous example -Comparing with the last 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, 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. === Extensible commitment structure === @@ -159,11 +161,11 @@ coinbase becomes: Double-SHA256(Witness root hash|Hash(new commitment|witness nonce)) -:: 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 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. 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. -The optional data space following the commitment also leaves room for metadata of future softforks. +The optional data space following the commitment also leaves room for metadata of future softforks, and MUST NOT be used for other purpose. === Trust-free unconfirmed transaction dependency chain === @@ -210,7 +212,7 @@ With a soft fork, it is possible to introduce a separate witness structure to al == Backward compatibility == -As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. '''What a non-upgraded wallet can do''' @@ -252,14 +254,14 @@ Special thanks to Gregory Maxwell for originating many of the ideas in this BIP == Reference Implementation == -https://github.com/sipa/bitcoin/commits/segwit2 +https://github.com/sipa/bitcoin/commits/segwit3 == References == -*[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16 Pay to Script Hash] -*[https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki BIP142 Address Formats for Witness Program] -*[https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143 Transaction signature verification for version 0 and version 1 witness program] -*[https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki BIP144 Segregated Witness (Peer Services)] +*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] +*[[bip-0142.mediawiki|BIP142 Address Formats for Segregated Witness]] +*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] +*[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]] == Copyright == diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki index fdf5202..7d7b1d2 100644 --- a/bip-0142.mediawiki +++ b/bip-0142.mediawiki @@ -1,6 +1,6 @@ <pre> BIP: 142 - Title: Address Formats for Witness Program + Title: Address Format for Segregated Witness Author: Johnson Lau <jl2012@xbt.hk> Status: Draft Type: Standards Track @@ -9,148 +9,142 @@ == Abstract == -This BIP describes 2 new types of Bitcoin address to support native Segregated Witness (segwit) transactions. The first type resembles the original P2PKH base-58 address. The second type is a z-base-32 representation of a witness program with Damm algorithm checksum, which supports arbitrarily complex transactions, and is forward compatible to new version witness programs in the future. +This BIP describes new types of Bitcoin address to support native segregated witness transactions with 20-byte and 32-byte program. == Motivation == -To define standard payment addresses for native segwit transactions to promote early adoption of the more efficient transaction method. +To define standard payment address for native segregated witness (segwit) transactions to promote early adoption of the more efficient transaction method. == Specification == -=== P2PKH segwit address === +The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH). -The first new Bitcoin address format defined is specific to pay-to-public-key-hash segwit transaction. The scriptPubKey is an OP_0 followed by a push of version 0 witness program: - OP_0 <DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG> -The new address is encoded exactly in the same way as the original pay-to-public-key-hash address: - base58-encode: [1-byte version][20-byte-hash-value][4-byte checksum] -Version byte is 0x19 for a main-network address, 0x41 for a testnet address. The following 20-byte is the public key hash. And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and public key hash. +The new address is encoded in a simlar way as existing address formats: + + base58-encode: + [1-byte address version] + [1-byte witness program version] + [0x00] + [20/32-byte-hash] + [4-byte checksum] + +For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address. -All addresses generated with this scheme will a constant length of 34 characters, with a "B" prefix for main-network and "T" prefix for testnet. +For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address. -=== General segwit address === +The witness program version is an 1-byte value between 0 (0x00) and 16 (0x10). Only version 0 is defined in BIP141. Versions 1 to 16 are reserved for future extensions. -The second new bitcoin address format defined is applicable to witness program of version 0 to 15 with a length of 2 to 32 bytes. +Following the witness program version is a 0x00 padding to make sure that each witness program version will have an unique prefix. -The z-base-32 character set is used: -{|class="wikitable" style="width:40ex; text-align: center; margin: 0 auto 0 auto;" -!width="12%"|Value -!width="12%"|Symbol -!width="12%"|Value -!width="12%"|Symbol -!width="12%"|Value -!width="12%"|Symbol -!width="12%"|Value -!width="12%"|Symbol +Following the padding is the program hash, 20 byte for a P2WPKH address and 32 byte for a P2WSH address. + +The 4-byte checksum is the first four bytes of the double SHA256 hash of the serialization of the previous items. + +All addresses generated with this scheme will have a constant length, with 36 digits for 20-byte and 53 digits for 32-byte. Different witness program version will have an unique prefix shown in the following table: + +{|class="wikitable" style="text-align: center;" +|- +!rowspan=3 style=""|Witness program version +!colspan=4 style=""|Hash size +|- +!colspan=2 style=""|20-byte (36 digits) +!colspan=2 style=""|32-byte (53 digits) +|- +!Mainnet +!Testnet +!Mainnet +!Testnet +|- +|0||p2||QW||7Xh||T7n +|- +|1||p4||QY||7Xq||T7w +|- +|2||p6||Qa||7Xz||T85 +|- +|3||p7||Qc||7Y9||T8E +|- +|4||pA||Qe||7YH||T8N +|- +|5||pB||Qf||7YS||T8X +|- +|6||pD||Qh||7Ya||T8g +|- +|7||pF||Qj||7Yj||T8p +|- +|8||pG||Qm||7Yt||T8y |- -| 0 || y || 8 || e || 16 || o || 24 || a +|9||pJ||Qn||7Z2||T97 |- -| 1 || b || 9 || j || 17 || t || 25 || 2 +|10||pL||Qp||7ZB||T9G |- -| 2 || n || 10 || k || 18 || 1 || 26 || 4 +|11||pN||Qr||7ZK||T9Q |- -| 3 || d || 11 || m || 19 || u || 27 || 5 +|12||pQ||Qt||7ZU||T9Z |- -| 4 || r || 12 || c || 20 || w || 28 || h +|13||pS||Qv||7Zc||T9i |- -| 5 || f || 13 || p || 21 || i || 29 || 7 +|14||pT||Qw||7Zm||T9r |- -| 6 || g || 14 || q || 22 || s || 30 || 6 +|15||pV||Qy||7Zv||TA1 +|- +|16||pX||R1||7a4||TA9 |- -| 7 || 8 || 15 || x || 23 || z || 31 || 9 |} -It is case-insensitive and includes all alphanumeric characters excluding 0, 2, l, v. The order of alphabet is chosen so that less ambiguous alphabet characters will appear more frequently than others. - -An address is a 270-bit string in z-base-32 with the following components: - - 5 address version bits - 5 length bits - 4 witness program version bits - 256 witness program bits - -The address version bits is 00001<sub>b</sub> for the main-network and 11001<sub>b</sub> for the testnet. - -Value of the length bits is the length of the witness program in byte minus 1. - -Witness program version bits indicates version of the witness program (v0 to v15). - -The witness program is padded with leading 0<sub>b</sub> to 256 bits. - -The 270-bit string is transformed to z-base-32 with 54 digits. - -The 54-digit raw address is then divided into 9 equal segments. For each segment, a checksum is calculated with Damm algorithm and appended to the end of the segment. This makes the length increases to 63 digits. - -A second round of checksum is calculated by taking the digits in the same position of the 9 segments, and appended to the end of the address. This is the final address with 69 digits. - == Rationale == -The segregated witness soft fork (BIP x) defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes: +The BIP141 defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes: * A native witness program output is a scriptPubKey with a push of version byte followed by a push of witness program, and nothing else; -* A witness program in P2SH is a P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output. +* Segwit-in-P2SH is a BIP16 P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output. -As the P2SH address has been defined in 2012, using witness program in P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is less collision-resistance than a native witness program, and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method. +As the BIP13 P2SH address has been defined in 2012, using segwit-in-P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method. The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Since then, better payment methods have been proposed or deployed, for example: *BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets *BIP63 Stealth Addresses *BIP70 Payment protocol -However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. As P2PKH transactions are still dominating the blockchain, the author believes that the proposed P2PKH segwit addresses is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain. +However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. It is believed that the proposed P2WPKH and P2WSH address format is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain. -The P2PKH segwit addresses only allow simple payment to a single public key. For arbitrarily complex segwit transactions, the general segwit address is used. The use of z-base-32 eliminates case-sensitiveness and simplifies transformation to and from hexadecimals. The Damm algorithm checksum allows detection of all single-digit errors and all adjacent transposition errors. With the excellent upgradability of witness program, this proposal is also forward compatible to new version witness programs that is not longer than 32 bytes. +While P2WPKH address is specific for simple payment to a single public key, P2WSH address allows arbitrarily complex segwit transactions, resemble to the BIP13 P2SH address. == Compatibility == -This proposal is not backward compatible, but it fails gracefully -- if an older implementation is given one of these new Bitcoin addresses, it will report the address as invalid and will refuse to create a transaction. +This proposal is not backward compatible. However, an older implementation will report the new address type as invalid and will refuse to create a transaction. -This proposal is forward compatible to any new witness program format with version 2 to 15 and length of 2 to 32 bytes. +This proposal is forward compatible to the future versions of witness program of 20 and 32 bytes. == Example == -=== P2PKH segwit address === - The following public key, + 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6 + when encoded as a P2PKH template, would become: + DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG + And the corresponding version 1 Bitcoin address is + 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM -When the same script is encoded as a version 0 witness program, the scriptPubKey becomes: - OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC> -Using 0x19 as the address version, the equivalent witness program address is: - B4YZZ3nMBETWVF9ZSfotSwTxVnqhdkTi7r - -=== General segwit address === - -With the same 25 bytes version 0 witness program in the last example: - OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC> -The address version bits is 00001<sub>b</sub> - 00001<sub>b</sub> -The lengths bits is 11000<sub>b</sub> (24 = 25 - 1) - 00001-11000<sub>b</sub> -The witness program version bits is 0000 - 00001-11000-0000<sub>b</sub> -Appended by the zero-padded witness program - 00001-11000-0000-0-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-11101...01100 -The 270-bit string is transformed to z-base-32 with 54 digits and split into 9 equal segments: - bayyyy -yyyyyy -yyq4wt -eyejc3 -5sybwi -8iksqo -h6mah9 -o4oprh -767nfc -Calculate the Damm checksum for each segment: - For example: Damm(bayyyy) = 7 - bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4 -Calculate the Damm checksum for digits in the same position of different segments: - For example: Damm(byye58ho7) = j - bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4-jwk86o - -== Implementation == - -From arbitrary witness program to general segwit address: https://gist.github.com/jl2012/760b0f952715b8b6c608 + +When the same public key is encoded as P2WPKH, the scriptPubKey becomes: + + OP_0 <010966776006953D5567439E5E39F86A0D273BEE> + +Using 0x06 as witness version, followed 0x00 as witness version, and a 0x00 padding, the equivalent P2WPKH address is: + + p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm + +== Reference implementation == == References == * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]] -* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]] +* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash]] +* [[bip-0070.mediawiki|BIP 70: Payment Protocal]] * [[bip-0141.mediawiki|BIP 141: Segregated Witness]] == Copyright == diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 4aca2db..3d7e856 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -1,6 +1,6 @@ <pre> BIP: 143 - Title: Transaction signature verification for version 0 and version 1 witness program + Title: Transaction Signature Verification for Version 0 Witness Program Author: Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> Status: Draft @@ -9,7 +9,7 @@ </pre> == Abstract == -This proposal defines a new transaction digest algorithm for signature verification in version 0 and version 1 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature. +This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature. == Motivation == There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <ref name=wiki>[https://en.bitcoin.it/wiki/OP_CHECKSIG]</ref> @@ -22,7 +22,7 @@ Unfortunately, there are at least 2 weaknesses in the original transaction diges Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. <ref>[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus layer)]</ref> == Specification == -A new transaction digest algorithm is defined, but only applicable to sigops in version 0 and version 1 witness program: +A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program: Double SHA256 of the serialization of: 1. nVersion of the transaction 2. hashPrevouts @@ -122,7 +122,7 @@ As a soft fork, older software will continue to operate without modification. No == Reference Implementation == -https://github.com/sipa/bitcoin/commits/segwit2 +https://github.com/sipa/bitcoin/commits/segwit3 == References == diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index e3843a8..736fadd 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -116,7 +116,7 @@ MSG_WITNESS_BLOCK requests will return a block message with transactions that ha 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. == Reference Implementation == -https://github.com/sipa/bitcoin/commits/segwit +https://github.com/sipa/bitcoin/commits/segwit3 == Copyright == This document is placed in the public domain. |