diff options
| -rw-r--r-- | bip-0141.mediawiki | 36 | ||||
| -rw-r--r-- | bip-0142.mediawiki | 30 | ||||
| -rw-r--r-- | bip-0143.mediawiki | 119 | ||||
| -rw-r--r-- | bip-0144.mediawiki | 8 |
4 files changed, 144 insertions, 49 deletions
diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index c769abd..7114ddd 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -21,7 +21,7 @@ The entirety of the transaction's effects are determined by output consumption ( By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed: -# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/edit/master/bip-0062.mediawiki BIP62]): +# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62]): #* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation) #* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62) #* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability @@ -34,13 +34,35 @@ By removing this data from the transaction structure committed to the transactio ==Specification== +=== Transaction ID === + +A new data structure, <code>witness</code>, is defined. Each transaction will have 2 IDs. + +Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format: + + [nVersion][txins][txouts][nLockTime] + +A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data: + + [nVersion][marker][flag][txins][txouts][witness][nLockTime] + +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>flag</code> MUST be a 1-byte non-zero value. Currently, <code>0x01</code> MUST be used. + +The <code>witness</code> is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a <code>var_int</code> to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a <code>var_int</code> to indicate the length. Witness data is NOT script and is not restricted by the 520-byte push limit. + +A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a <code>0x00</code>. If all txins are not witness program, a transaction's <code>wtxid</code> is equal to its <code>txid</code>. + === Commitment structure === -A new block rule is added which requires a commitment to the witness hashes, the double SHA256 of a transaction including witnesses. The witness hash of coinbase transaction is assumed to be 0x0000....0000. +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 witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header. +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. -The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is: +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: 1-byte - OP_RETURN (0x6a) 1-byte - Push the following 36 bytes (0x24) @@ -206,9 +228,9 @@ The 32-byte limitation for witness program could be easily extended through a so === Per-input lock-time and relative-lock-time === -Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/edit/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution. +Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution. -With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/edit/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/edit/master/bip-0112.mediawiki BIP112]). +With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]). == Backward compatibility == @@ -254,7 +276,7 @@ Special thanks to Gregory Maxwell for originating many of the ideas in this BIP == Reference Implementation == -https://github.com/sipa/bitcoin/commits/segwit3 +https://github.com/sipa/bitcoin/commits/segwit == References == diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki index 7d7b1d2..ff831cb 100644 --- a/bip-0142.mediawiki +++ b/bip-0142.mediawiki @@ -19,7 +19,7 @@ To define standard payment address for native segregated witness (segwit) transa 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 new address is encoded in a simlar way as existing address formats: +The new address is encoded in a way similar to existing address formats: base58-encode: [1-byte address version] @@ -32,23 +32,23 @@ For P2WPKH address, the address version is 6 (0x06) for a main-network address o For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet 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 witness program version is a 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. -Following the witness program version is a 0x00 padding to make sure that each witness program version will have an unique prefix. +Following the witness program version is a 0x00 padding to make sure that each witness program version will have a unique prefix. 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: +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 versions will have a unique prefix, as 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) +!colspan=2 style=""|20-byte (36 characters) +!colspan=2 style=""|32-byte (53 characters) |- !Mainnet !Testnet @@ -94,12 +94,12 @@ All addresses generated with this scheme will have a constant length, with 36 di == Rationale == -The BIP141 defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes: +BIP141 defines 2 ways of encoding a "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; * 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 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. +Considering 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 method of payment. 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 @@ -108,13 +108,13 @@ The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Sin 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. -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. +While P2WPKH address is specific for simple payment to a single public key, P2WSH address allows arbitrarily complex segwit transactions, similar to the BIP13 P2SH address. == Compatibility == -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 not backward-compatible. However, an older implementation will report the new address type as invalid, and refuse to create a transaction. -This proposal is forward compatible to the future versions of witness program of 20 and 32 bytes. +This proposal is forward-compatible with future versions of witness programs of 20 and 32 bytes. == Example == @@ -126,7 +126,7 @@ when encoded as a P2PKH template, would become: DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG -And the corresponding version 1 Bitcoin address is +With the corresponding version 1 Bitcoin address being: 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM @@ -134,17 +134,19 @@ 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: +Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is: p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm == Reference implementation == +https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80 + == References == * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]] * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash]] -* [[bip-0070.mediawiki|BIP 70: Payment Protocal]] +* [[bip-0070.mediawiki|BIP 70: Payment Protocol]] * [[bip-0141.mediawiki|BIP 141: Segregated Witness]] == Copyright == diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 3d7e856..72ef22d 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -1,4 +1,4 @@ -<pre> +<pre> BIP: 143 Title: Transaction Signature Verification for Version 0 Witness Program Author: Johnson Lau <jl2012@xbt.hk> @@ -24,35 +24,43 @@ Deploying the aforementioned fixes in the original script system is not a simple == Specification == 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 - 3. hashSequence - 4. transaction id and output index of the output spent by this input - 5. subscript of the input - 6. value of the output spent by this input - 7. nSequence of the input - 8. hashOutputs - 9. nLocktime of the transaction - 10. sighash type of the signature - -The items 1, 4, 5, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref> + 1. nVersion of the transaction (4-byte little endian) + 2. hashPrevouts (32-byte hash) + 3. hashSequence (32-byte hash) + 4. outpoint (32-byte hash + 4-byte little endian) + 5. scriptCode of the input (varInt for the length + script) + 6. value of the output spent by this input (8-byte little endian) + 7. nSequence of the input (4-byte little endian) + 8. hashOutputs (32-byte hash) + 9. nLocktime of the transaction (4-byte little endian) + 10. sighash type of the signature (4-byte little endian) + +All components in the original algorithm, including the behavior <code>OP_CODESEPERATOR</code>, remains unchanged. The only difference is the way of serialization and the inclusion of amount being spent. + +The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref> + +The item 5: +*For P2WPKH witness program, the scriptCode is <code>0x1976a914{20-byte-pubkey-hash}88ac</code>. +*For P2WSH witness program, +**if the <code>witnessScript</code> does not contain any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is a <code>varInt</code> for the length of the <code>witnessScript</code>, followed by the <code>witnessScript</code>. +**if the <code>witnessScript</code> contains any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is the evaluated script, with all <code>OP_CODESEPARATOR</code> and everything up to the last <code>OP_CODESEPARATOR</code> before the signature checking opcode being executed removed, and prepended by a <code>varInt</code> for the length of the truncated script. The item 6 is a 8-byte value of the amount of bitcoin spent in this input. -hashPrevouts: -*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all transaction ids and output indexes involved in this transaction; -*Otherwise, hashPrevouts is a uint256 of 0x0000......0000. +<code>hashPrevouts</code>: +*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints; +*Otherwise, <code>hashPrevouts</code> is a <code>uint256</code> of <code>0x0000......0000</code>. -hashSequence: +<code>hashSequence</code>: *If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs; -*Otherwise, hashSequence is a uint256 of 0x0000......0000. +*Otherwise, <code>hashSequence</code> is a <code>uint256</code> of <code>0x0000......0000</code>. -hashOutputs: -*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output scriptPubKey with value; -*If sighash type is SINGLE and the input index is not greater than the number of outputs, hashOutputs is the double SHA256 of the output scriptPubKey with value of the same index as the input; -*Otherwise, hashOutputs is a uint256 of 0x0000......0000. +<code>hashOutputs</code>: +*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output value (8-byte little endian) with scriptPubKey (<code>varInt</code> for the length + script); +*If sighash type is SINGLE and the input index is not greater than the number of outputs, <code>hashOutputs</code> is the double SHA256 of the output value 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>. -The hashPrevouts, hashSequence, and hashOutputs 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). +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). Refer to the reference implementation, reproduced below, for the precise algorithm: @@ -112,6 +120,69 @@ Refer to the reference implementation, reproduced below, for the precise algorit return ss.GetHash(); </source> +== Example == + + + The following is an unsigned transaction: + 0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000 + + nVersion: 01000000 + txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff + ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff + txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac + 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac + nLockTime: 11000000 + + The first input comes from an ordinary P2PK: + scriptPubKey: 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25 + + The second input comes from a P2WPKH witness program: + scriptPubKey: 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6 + + To sign it with a nHashType of 1 (SIGHASH_ALL): + + hashPrevouts: + dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000) + = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 + + hashSequence: + dSHA256(eeffffffffffffff) + = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b + + hashOutputs: + dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac) + = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 + + hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000 + + nVersion: 01000000 + hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 + hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b + outpoint: ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000 + scriptCode: 1976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac + amount: 0046c32300000000 + nSequence: ffffffff + hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 + nLockTime: 11000000 + nHashType: 01000000 + + sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670 + signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee + + The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000 + + nVersion: 01000000 + marker: 00 + flag: 01 + txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01 eeffffff + ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff + txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac + 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac + witness 00 + 02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357 + nLockTime: 11000000 + +The new serialization format is described in BIP144 <ref>[[bip-0144.mediawiki|BIP144: Segregated Witness (Peer Services)]]</ref> == Deployment == This proposal is deployed with Segregated Witness softfork (BIP 141) @@ -122,7 +193,7 @@ As a soft fork, older software will continue to operate without modification. No == Reference Implementation == -https://github.com/sipa/bitcoin/commits/segwit3 +https://github.com/sipa/bitcoin/commits/segwit == References == diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 1106c39..9b2422b 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -63,8 +63,8 @@ The serialization has the following structure: | A list of one or more transaction outputs |- | 1+ -| witness -| witness +| script_witnesses +| script_witnesses[] | The witness structure as a serialized byte array |- | 4 @@ -77,7 +77,7 @@ Parsers supporting this BIP will be able to distinguish between the old serializ If the witness is empty, the old serialization format should be used. -Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] (Consensus segwit BIP), and treats it as an arbitrary byte array. +Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. * '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used. @@ -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/segwit3 +https://github.com/sipa/bitcoin/commits/segwit == Copyright == This document is placed in the public domain. |