diff options
| -rw-r--r-- | README.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0009.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0009/assignments.mediawiki | 8 | ||||
| -rw-r--r-- | bip-0021.mediawiki | 3 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0050.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0068.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0112.mediawiki | 16 | ||||
| -rw-r--r-- | bip-0113.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0114.mediawiki | 10 | ||||
| -rw-r--r-- | bip-0126.mediawiki | 98 | ||||
| -rw-r--r-- | bip-0141.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0143.mediawiki | 353 | ||||
| -rw-r--r-- | bip-0151.mediawiki | 32 | ||||
| -rw-r--r-- | bip-0152.mediawiki | 34 | ||||
| -rw-r--r-- | bip-0152/protocol-flow.png | bin | 25231 -> 17398 bytes |
16 files changed, 527 insertions, 49 deletions
diff --git a/README.mediawiki b/README.mediawiki index ee7b0d8..b745f51 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -446,6 +446,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0126.mediawiki|126]] +| Best Practices for Heterogeneous Input Script Transactions +| Kristov Atlas +| Informational +| Draft +|- | [[bip-0130.mediawiki|130]] | sendheaders message | Suhas Daftuar diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 44e29a9..7270abd 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -109,7 +109,7 @@ referred to as MTP in the diagram above, and is treated as a monotonic clock def After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set, and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their -version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 for testnet (75% of 2016). +version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016). The transition to FAILED takes precendence, as otherwise an ambiguity can arise. There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the other one simultaneously transitions to STARTED, which would mean both would demand setting the bit. @@ -202,7 +202,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account. '''Modified thresholds''' -The 1915 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. +The 1916 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. '''Conflicting soft forks''' At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes. @@ -224,7 +224,7 @@ upgrades for successful soft forks. ==Deployments== -A living list of deployment proposals can be found [[bips-0009/assignments.mediawiki|here]]. +A living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]]. ==Copyright== diff --git a/bip-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki index ee56e17..e145ceb 100644 --- a/bip-0009/assignments.mediawiki +++ b/bip-0009/assignments.mediawiki @@ -18,11 +18,11 @@ State can be defined, active, failed. Dates are in UTC. | csv | 0 | 2016-05-01 00:00:00 -| 2017-05-01 00:00:00 -| defined +| 2017-05-01 00:00:00 +| active since #419328 | 2016-03-01 00:00:00 | 2017-05-01 00:00:00 -| active since #770111 +| active since #770112 | [[/bip-0068.mediawiki|68]], [[/bip-0112.mediawiki|112]], [[/bip-0113.mediawiki|113]] |- | segwit @@ -32,6 +32,6 @@ State can be defined, active, failed. Dates are in UTC. | - | 2016-05-01 00:00:00 | 2017-05-01 00:00:00 -| defined +| active since #834624 | [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]] |} diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index e7094e5..a3c2d4e 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -122,3 +122,6 @@ Characters must be URI encoded properly. === Bitcoin clients === * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. +=== Libraries === +* Javascript - https://github.com/bitcoinjs/bip21 +* [[BitcoinPaymentURI|https://github.com/SandroMachado/BitcoinPaymentURI]] Java library to process and generate Bitcoin payment URI's. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index c44ad3e..b553666 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -139,4 +139,4 @@ Haskell - https://github.com/haskoin/haskoin .NET C# (PCL) - https://github.com/NicolasDorier/NBitcoin -JavaScript - https://github.com/bitpay/bitcore-mnemonic +JavaScript - https://github.com/bitpay/bitcore-mnemonic, https://github.com/bitcoinjs/bip39 diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index 4f48fca..fbc1c0f 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -41,7 +41,7 @@ This would be an issue even if the entire network was running version 0.7.2. It ===Immediately=== '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules: -# Reject blocks that would probably could cause more than 10,000 locks to be taken. +# Reject blocks that would probably cause more than 10,000 locks to be taken. # Limit the maximum block-size created to 500,000 bytes # Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000 # Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot. diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index 0082db3..0303924 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -49,6 +49,8 @@ The block produced time is equal to the median-time-past of its previous block. When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter. +The new rules are not applied to the nSequence field of the input of the coinbase transaction. + ==Implementation== A reference implementation is provided by the following pull request diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 19f74b6..e19e0e9 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -138,10 +138,10 @@ A simple output, paying to Alice might then look like: HASH160 <revokehash> EQUAL IF - <Bob key hash> + <Bob's pubkey> ELSE "24h" CHECKSEQUENCEVERIFY DROP - <Alice key hash> + <Alice's pubkey> ENDIF CHECKSIG @@ -153,10 +153,10 @@ With CHECKLOCKTIMEVERIFY, this would look like: HASH160 <revokehash> EQUAL IF - <Bob key hash> + <Bob's pubkey> ELSE "2015/12/15" CHECKLOCKTIMEVERIFY DROP - <Alice key hash> + <Alice's pubkey> ENDIF CHECKSIG @@ -181,13 +181,13 @@ Alice might look like the following in Alice's commitment transaction: IF "24h" CHECKSEQUENCEVERIFY 2DROP - <Alice key hash> + <Alice's pubkey> ELSE <Commit-Revocation-Hash> EQUAL NOTIF "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP ENDIF - <Bob key hash> + <Bob's pubkey> ENDIF CHECKSIG @@ -196,12 +196,12 @@ and correspondingly in Bob's commitment transaction: HASH160 DUP <R-HASH> EQUAL SWAP <Commit-Revocation-Hash> EQUAL ADD IF - <Alice key hash> + <Alice's pubkey> ELSE "2015/10/20 10:33" CHECKLOCKTIMEVERIFY "24h" CHECKSEQUENCEVERIFY 2DROP - <Bob key hash> + <Bob's pubkey> ENDIF CHECKSIG diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 7497f50..8290c13 100644 --- a/bip-0113.mediawiki +++ b/bip-0113.mediawiki @@ -64,6 +64,8 @@ This method takes the block time as one parameter. This BIP proposes that after activation calls to IsFinalTx() within consensus code use the return value of `GetMedianTimePast(pindexPrev)` instead. +The new rule applies to all transactions, including the coinbase transaction. + A reference implementation of this proposal is provided by the following pull request: diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki index 2d16084..aee8646 100644 --- a/bip-0114.mediawiki +++ b/bip-0114.mediawiki @@ -96,20 +96,20 @@ The following is the "Hashed TIme-Lock Contract" example in [[bip-0112.mediawiki IF "24h" CHECKSEQUENCEVERIFY 2DROP - <Alice key hash> + <Alice's pubkey> ELSE <Commit-Revocation-Hash> EQUAL NOTIF "Timestamp" CHECKLOCKTIMEVERIFY DROP ENDIF - <Bob key hash> + <Bob's pubkey> ENDIF CHECKSIG To create a MAST Root, it is flattened to 3 mutually exclusive branches: - HASH160 <R-HASH> EQUALVERIFY "24h" CHECKSEQUENCEVERIFY DROP <Alice key hash> CHECKSIG - HASH160 <Commit-Revocation-Hash> EQUALVERIFY <Bob key hash> CHECKSIG - "Timestamp" CHECKLOCKTIMEVERIFY DROP <Bob key hash> CHECKSIG + HASH160 <R-HASH> EQUALVERIFY "24h" CHECKSEQUENCEVERIFY DROP <Alice's pubkey> CHECKSIG + HASH160 <Commit-Revocation-Hash> EQUALVERIFY <Bob's pubkey> CHECKSIG + "Timestamp" CHECKLOCKTIMEVERIFY DROP <Bob's pubkey> CHECKSIG which significantly improves readability and reduces the witness size when it is redeemed. diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki new file mode 100644 index 0000000..eed0c3e --- /dev/null +++ b/bip-0126.mediawiki @@ -0,0 +1,98 @@ +<pre> + BIP: 126 + Title: Best Practices for Heterogeneous Input Script Transactions + Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org> + Status: Draft + Type: Informational + Created: 2016-02-10 +</pre> + +==Abstract== + +When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due to the natural fragmentation of wallet balances over time. + +This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts. + +==Copyright== + +This BIP is in the public domain. + +==Definitions== + +* '''Heterogenous input script transaction (HIT)''': A transaction containing multiple inputs where the scripts of the previous transaction outputs being consumed are not identical (e.g. a transaction spending outputs which were sent to more than one Bitcoin address) +* '''Unavoidable heterogenous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output +* '''Intentional heterogenous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) + +Throughout this procedure, when input scripts are evaluated for uniqueness, "input script" should be interpreted to mean, "the script of the previous output referenced by an input to a transaction". + +==Motivations== + +The recommendations in this document are designed to accomplish three goals: + +# Maximise the effectiveness of user-protecting protocols: Users may find that protection protocols are counterproductive if such transactions have a distinctive fingerprint which renders them ineffective. +# Minimise the adverse consequences of unavoidable heterogenous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis. +# Limiting the effect on UTXO set growth: To date, non-standardized intentional HITs tend to increase the network's UTXO set with each transaction; this standard attempts to minimize this effect by standardizing unavoidable and intentional HITs to limit UTXO set growth. + +In order to achieve these goals, this specification proposes a set of best practices for heterogenous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII. + +In order to achieve this, two forms of HIT are proposed: Standard form and alternate form. + +==Standard form heterogenous input script transaction== + +===Rules=== + +A HIT is Standard form if it adheres to all of the following rules: + +# The number of unique output scripts must be equal to the number of unique inputs scripts (irrespective of the number of inputs and outputs). +# All output scripts must be unique. +# At least one pair of outputs must be of equal value. +# The largest output in the transaction is a member of a set containing at least two identically-sized outputs. + +===Rationale=== + +The requirement for equal numbers of unique input/output scripts instead of equal number of inputs/outputs accommodates user-protecting UTXO selection behavior. Wallets may contain spendable outputs with identical scripts due to intentional or accidental address reuse, or due to dusting attacks. In order to minimise the adverse consequences of address reuse, any time a UTXO is included in a transaction as an input, all UTXOs with the same spending script should also be included in the transaction. + +The requirement that all output scripts are unique prevents address reuse. Restricting the number of outputs to the number of unique input scripts prevents this policy from growing the network’s UTXO set. A standard form HIT transaction will always have a number of inputs greater than or equal to the number of outputs. + +The requirement for at least one pair of outputs in an intentional HIT to be of equal value results in optimal behavior, and causes intentional HITs to resemble unavoidable HITs. + +==Alternate form heterogenous input script transactions== + +The formation of a standard form HIT is not possible in the following cases: + +# The HIT is unavoidable, and the user’s wallet contains an insufficient number or size of UTXOs to create a standard form HIT. +# The user wishes to reduce the number of utxos in their wallet, and does not have any sets of utxos with identical scripts. + +When one of the following cases exist, a compliant implementation may create an alternate form HIT by constructing a transaction as follows: + +===Procedure=== + +# Find the smallest combination of inputs whose value is at least the value of the desired spend. +## Add these inputs to the transaction. +## Add a spend output to the transaction. +## Add a change output to the transaction containing the difference between the current set of inputs and the desired spend. +# Repeat step 1 to create a second pair of outputs, where one output has the same value as the spend output of the previous step. +# (optional) Repeat step 2 until the desired number of inputs have been consumed and/or the desired number outputs have been created. +# Adjust the change outputs as necessary to pay the desired transaction fee. + +Clients which create intentional HITs must have the capability to form alternate form HITs, and must do so for a non-zero fraction of the transactions they create. + +===Rules=== + +An HIT formed via the preceding procedure will adhere to the following conditions: + +# The number of unique inputs scripts must exceed the number of output scripts. +# All output scripts must be unique. +# At least one pair of outputs must be of equal value. +## "Standard outputs" refers to the set of outputs with equal value +## "Standard value" refers to the value of the standard outputs +## "Change outputs" refers to all outputs which are not standard outputs +# For a HIT containing n standard outputs, there must exist at least one possible way to organize the inputs and outputs into n sets, where all sets satisfy the following: +## The set contains one or more inputs, exactly one standard output, and exactly one change output +## An input or output that appears in one set must not appear in any other set +## The sum of the inputs in the set minus the value of the change output is equal to the standard value with a tolerance equal to the transaction fee. +## Change outputs with a value of zero (virtual change outputs) are permitted. The are defined for the purpose of testing whether or not a HIT adheres to this specification but are not present in the version of the transaction which is broadcast to the network. + +==Non-compliant heterogenous input script transactions== + +If a user wishes to create an output that is larger than half the total size of their spendable outputs, or if their inputs are not distributed in a manner in which the alternate form procedure can be completed, then the user can not create a transaction which is compliant with this procedure. diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index f02acf9..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. diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index bf56594..892c027 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -39,6 +39,7 @@ Semantics of the original sighash types remain unchanged, except the followings: # The way of serialization is changed; # All sighash types commit to the amount being spent by the signed input; # <code>FindAndDelete</code> of the signature is not applied to the <code>scriptCode</code>; +# <code>OP_CODESEPARATOR</code>(s) after the last executed <code>OP_CODESEPARATOR</code> are not removed from the <code>scriptCode</code>; # <code>SINGLE</code> does not commit to the input index. When <code>ANYONECANPAY</code> is not set, the semantics are unchanged since <code>hashPrevouts</code> and <code>outpoint</code> together implictly commit to the input index. When <code>SINGLE</code> is used with <code>ANYONECANPAY</code>, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index. The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref> @@ -46,8 +47,8 @@ The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref n 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 the <code>witnessScript</code> serialized as scripts inside CTxOuts. -**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, serialized as scripts inside CTxOuts. +**if the <code>witnessScript</code> does not contain any <code>OP_CODESEPARATOR</code>, the <code>scriptCode</code> is the <code>witnessScript</code> serialized as scripts inside CTxOuts. +**if the <code>witnessScript</code> contains any <code>OP_CODESEPARATOR</code>, the <code>scriptCode</code> is the evaluated script, with everything up to and including the last executed <code>OP_CODESEPARATOR</code> before the signature checking opcode being executed removed, serialized as scripts inside CTxOuts. The item 6 is a 8-byte value of the amount of bitcoin spent in this input. @@ -60,9 +61,9 @@ The item 6 is a 8-byte value of the amount of bitcoin spent in this input. *Otherwise, <code>hashSequence</code> is a <code>uint256</code> of <code>0x0000......0000</code>. <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 value (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 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>.<ref>In the original algorithm, a <code>uint256</code> of <code>0x0000......0001</code> is commited if the input index for a <code>SINGLE</code> signature is greater than the number of outputs. In this BIP a <code>0x0000......0000</code> is commited, without changing the semantics.</ref> +*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 commited 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> 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). @@ -125,7 +126,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit </source> == Example == - +=== Native P2WPKH === The following is an unsigned transaction: 0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000 @@ -138,7 +139,8 @@ Refer to the reference implementation, reproduced below, for the precise algorit nLockTime: 11000000 The first input comes from an ordinary P2PK: - scriptPubKey: 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25 + scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25 + private key : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866 The second input comes from a P2WPKH witness program: scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6 @@ -188,7 +190,344 @@ Refer to the reference implementation, reproduced below, for the precise algorit 02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357 nLockTime: 11000000 +=== P2SH-P2WPKH === + + + The following is an unsigned transaction: 0100000001db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a54770100000000feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac92040000 + + nVersion: 01000000 + txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 00 feffffff + txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac + 0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac + nLockTime: 92040000 + + The input comes from a P2SH-P2WPKH witness program: + scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10 + redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089 + private key : eb696a065ef48a2192da5b28b694f87544b30fae8327c4510137a922f32c6dcf + public key : 03ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873 + + To sign it with a nHashType of 1 (SIGHASH_ALL): + + hashPrevouts: + dSHA256(db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000) + = b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a + + hashSequence: + dSHA256(feffffff) + = 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198 + + hashOutputs: + dSHA256(b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac) + = de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83 + + hash preimage: 01000000b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001976a91479091972186c449eb1ded22b78e40d009bdf008988ac00ca9a3b00000000feffffffde984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c839204000001000000 + + nVersion: 01000000 + hashPrevouts: b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a + hashSequence: 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198 + outpoint: db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000 + scriptCode: 1976a91479091972186c449eb1ded22b78e40d009bdf008988ac + amount: 00ca9a3b00000000 + nSequence: feffffff + hashOutputs: de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83 + nLockTime: 92040000 + nHashType: 01000000 + + sigHash: 64f3b0f4dd2bb3aa1ce8566d220cc74dda9df97d8490cc81d89d735c92e59fb6 + signature: 3044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01 + + The serialized signed transaction is: 01000000000101db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001716001479091972186c449eb1ded22b78e40d009bdf0089feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac02473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb012103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a2687392040000 + nVersion: 01000000 + marker: 00 + flag: 01 + txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 1716001479091972186c449eb1ded22b78e40d009bdf0089 feffffff + txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac + 0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac + witness 02 473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01 2103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873 + nLockTime: 92040000 + +=== Native P2WSH === + +This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGHASH_SINGLE</code> are processed: + + + + The following is an unsigned transaction: + 0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000 + + nVersion: 01000000 + txin: 02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff + 0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff + txout: 01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac + nLockTime: 00000000 + + The first input comes from an ordinary P2PK: + scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625 + private key: b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c + signature: 304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL) + + The second input comes from a native P2WSH witness program: + scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49 + witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac + <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPERATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG + + To sign it with a nHashType of 3 (SIGHASH_SINGLE): + + hashPrevouts: + dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000) + = ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41 + + nVersion: 01000000 + hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41 + hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 + outpoint: 0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000 + scriptCode: (see below) + amount: 0011102401000000 + nSequence: ffffffff + hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output) + nLockTime: 00000000 + nHashType: 03000000 + + scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac + ^^ + (please note that the not-yet-exectued OP_CODESEPARATOR is not removed from the scriptCode) + preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000 + sigHash: 82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391 + public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae + private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd + signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703 + + scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac + (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed) + preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000 + sigHash: fef7bd749cce710c5c052bd796df1af0d935e59cea63736268bcbe2d2134fc47 + public key: 0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465 + private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec + signature: 304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503 + + The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000 + + +This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, and <code>SINGLE|ANYONECANPAY</code> does not commit to the input index: + + + + The following is an unsigned transaction: + 0100000002e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac00000000 + + nVersion: 01000000 + txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff + 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff + txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac + 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac + nLockTime: 00000000 + + The first input comes from a native P2WSH witness program: + scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215 + witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + 0 IF CODESEPERATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG + + The second input comes from a native P2WSH witness program: + scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215 + witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + 1 IF CODESEPERATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG + + To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY): + + nVersion: 01000000 + hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 + hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 + outpoint: (see below) + scriptCode: (see below) + amount: ffffff0000000000 + nSequence: ffffffff + hashOutputs: (see below) + nLockTime: 00000000 + nHashType: 83000000 + + outpoint: e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000 + scriptCode: 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + (since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode) + hashOutputs: b258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d2 + preimage: 0100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffffb258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d20000000083000000 + sigHash: e9071e75e25b8a1e298a72f0d2e9f4f95a0f5cdf86a533cda597eb402ed13b3a + public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98 + private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d + signature: 3045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 + + outpoint: 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000 + scriptCode: 2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed) + hashOutputs: 91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca + preimage: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b000000002468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffff91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca0000000083000000 + sigHash: cd72f1f1a433ee9df816857fad88d8ebd97e09a75cd481583eb841c330275e54 + public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98 + private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d + signature: 30440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 + + The serialized signed transaction is: + 01000000000102e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 + nVersion: 01000000 + marker: 00 + flag: 01 + txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff + 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff + txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac + 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac + witness 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + nLockTime: 00000000 + + Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the the input-output pairs are swapped: + 0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 + nVersion: 01000000 + marker: 00 + flag: 01 + txin: 02 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff + e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff + txout: 02 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac + 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac + witness 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac + nLockTime: 00000000 + +=== P2SH-P2WSH === + +This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different <code>SIGHASH</code> types. + + + + The following is an unsigned transaction: 010000000136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000000ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac00000000 + + nVersion: 01000000 + txin: 01 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e 01000000 00 ffffffff + txout: 02 00e9a43500000000 1976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac + c0832f0500000000 1976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac + nLockTime: 00000000 + + The input comes from a P2SH-P2WSH 6-of-6 multisig witness program: + scriptPubKey : a9149993a429037b5d912407a71c252019287b8d27a587, value: 9.87654321 + redeemScript : 0020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54 + witnessScript: 56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae + + hashPrevouts: + dSHA256(36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000) + = 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 + + hashSequence: + dSHA256(ffffffff) + = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 + + hashOutputs for ALL: + dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac) + = bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc + + hashOutputs for SINGLE: + dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac) + = 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708 + + hash preimage for ALL: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa03bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504436641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000001000000 + nVersion: 01000000 + hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 + hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 + outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000 + scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae + amount: b168de3a00000000 + nSequence: ffffffff + hashOutputs: bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc + nLockTime: 00000000 + nHashType: 01000000 + sigHash: 185c0be5263dce5b4bb50a047973c1b6272bfbd0103a89444597dc40b248ee7c + public key: 0307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba3 + private key: 730fff80e1413068a05b57d6a58261f07551163369787f349438ea38ca80fac6 + signature: 304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01 + + hash preimage for NONE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000002000000 + nVersion: 01000000 + hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 + hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 + outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000 + scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae + amount: b168de3a00000000 + nSequence: ffffffff + hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000 + nLockTime: 00000000 + nHashType: 02000000 + sigHash: e9733bc60ea13c95c6527066bb975a2ff29a925e80aa14c213f686cbae5d2f36 + public key: 03b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b + private key: 11fa3d25a17cbc22b29c44a484ba552b5a53149d106d3d853e22fdd05a2d8bb3 + signature: 3044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502 + + hash preimage for SINGLE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000003000000 + nVersion: 01000000 + hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 + hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 + outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000 + scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae + amount: b168de3a00000000 + nSequence: ffffffff + hashOutputs: 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708 + nLockTime: 00000000 + nHashType: 03000000 + sigHash: 1e1f1c303dc025bd664acb72e583e933fae4cff9148bf78c157d1e8f78530aea + public key: 034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a + private key: 77bf4141a87d55bdd7f3cd0bdccf6e9e642935fec45f2f30047be7b799120661 + signature: 3044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403 + + hash preimage for ALL|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000081000000 + nVersion: 01000000 + hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 + hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 + outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000 + scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae + amount: b168de3a00000000 + nSequence: ffffffff + hashOutputs: bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc + nLockTime: 00000000 + nHashType: 81000000 + sigHash: 2a67f03e63a6a422125878b40b82da593be8d4efaafe88ee528af6e5a9955c6e + public key: 033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f4 + private key: 14af36970f5025ea3e8b5542c0f8ebe7763e674838d08808896b63c3351ffe49 + signature: 3045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381 + + hash preimage for NONE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000082000000 + nVersion: 01000000 + hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 + hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 + outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000 + scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae + amount: b168de3a00000000 + nSequence: ffffffff + hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000 + nLockTime: 00000000 + nHashType: 82000000 + sigHash: 781ba15f3779d5542ce8ecb5c18716733a5ee42a6f51488ec96154934e2c890a + public key: 03a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac16 + private key: fe9a95c19eef81dde2b95c1284ef39be497d128e2aa46916fb02d552485e0323 + signature: 3045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a0882 + + hash preimage for SINGLE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000083000000 + nVersion: 01000000 + hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 + hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 + outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000 + scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae + amount: b168de3a00000000 + nSequence: ffffffff + hashOutputs: 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708 + nLockTime: 00000000 + nHashType: 83000000 + sigHash: 511e8e52ed574121fc1b654970395502128263f62662e076dc6baf05c2e6a99b + public key: 02d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b + private key: 428a7aee9f0c2af0cd19af3cf1c78149951ea528726989b2e83e4778d2c3f890 + signature: 30440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783 + + The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000 + + 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) diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 18d3901..cc79712 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -36,17 +36,22 @@ Encryption initialization must happen before sending any other messages to the r === Symmetric Encryption Cipher Keys === -The symmetric encryption cipher keys will be calculated with ECDH by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be calculated with <code>HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key")</code>. +The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification: -<code>K_1</code> must be the left 32bytes of the <code>HMAC_SHA512</code> hash. +1. HKDF extraction +<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinechd", ikm=ecdh_secret|cipher-type)</code>. -<code>K_2</code> must be the right 32bytes of the <code>HMAC_SHA512</code> hash. +2. Derive Key1 +<code>K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32)</code> -It is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks. +3. Derive Key2 +<code>K_2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK2", L=32)</code> + +It is important to include the cipher-type into the symmetric cipher key derivation to avoid weak-cipher-attacks. === Session ID === -Both sides must also calculate the 256bit session-id using <code>HMAC_SHA256(key=ecdh_secret,msg="session id")</code>. The session-id can be used for linking the encryption-session to an identity check. +Both sides must also calculate the 256bit session-id using <code>SID = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinSessionID", L=32)</code>. The session-id can be used for linking the encryption-session to an identity check. === The <code>encinit</code> message type === @@ -69,19 +74,19 @@ Possible symmetric key ciphers types === ChaCha20-Poly1305 Cipher Suite === -ChaCha20 is a stream cipher designed by Daniel Bernstein [2]. It operates by permuting 128 fixed bits, 128 or 256 bits of key, +ChaCha20 is a stream cipher designed by Daniel Bernstein [3]. It operates by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded. -Poly1305, also by Daniel Bernstein [3], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use +Poly1305, also by Daniel Bernstein [4], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use 256 bit secret key. -The chacha20-poly1305@openssh.com specified and defined by openssh [4] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [5], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. +The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. <code>K_1</code> must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. <code>K_2</code> must be used in conjunction with poly1305 to build an AEAD. -Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304 [5]. +Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304. === The <code>encack</code> message type === @@ -164,10 +169,11 @@ This proposal is backward compatible. Non-supporting peers will ignore the <code == References == * [1] http://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf -* [2] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf -* [3] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf -* [4] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305 -* [5] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 +* [2] HKDF (RFC 5869) https://tools.ietf.org/html/rfc5869 +* [3] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf +* [4] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf +* [5] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305 +* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 == Acknowledgements == * Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP. diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index b9a83f9..cfae0c0 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -114,7 +114,8 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde ====MSG_CMPCT_BLOCK==== # getdata messages may now contain requests for MSG_CMPCT_BLOCK objects. -# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object with the hash of a block which was recently announced and after having sent the requesting peer a sendcmpct message, nodes MUST respond with a cmpctblock message containing appropriate data representing the block being requested. +# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object with the hash of a block which was recently announced and is close to the tip of the best chain of the receiver and after having sent the requesting peer a sendcmpct message, nodes MUST respond with a cmpctblock message containing appropriate data representing the block being requested. +# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object for which a cmpctblock message is not sent in response, a block message containing the requested block in non-compact form MUST be sent. # MSG_CMPCT_BLOCK inv objects MUST NOT appear anywhere except for in getdata messages. ====cmpctblock==== @@ -150,7 +151,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde # Nodes MAY impose additional requirements on when they announce new blocks by sending cmpctblock messages. For example, nodes with limited outbound bandwidth MAY choose to announce new blocks using inv/header messages (as per BIP130) to conserve outbound bandwidth. -# Note that the MSG_CMPCT_BLOCK section does not require that nodes respond to MSG_CMPCT_BLOCK getdata requests for blocks which they did not recently announce. This allows nodes to calculate cmpctblock messages at announce-time instead of at request-time. Thus, nodes MUST NOT request blocks using MSG_CMPCT_BLOCK getdatas unless it is in response to an inv/headers block announcement (as per BIP130), and MUST NOT request blocks using MSG_CMPCT_BLOCK getdatas in response to headers messages which were, themselves, responses to getheaders requests. +# Note that the MSG_CMPCT_BLOCK section does not require that nodes respond to MSG_CMPCT_BLOCK getdata requests for blocks which they did not recently announce. This allows nodes to calculate cmpctblock messages at announce-time instead of at request-time. Blocks which are requested with a MSG_CMPCT_BLOCK getdata, but which are not responded to with a cmpctblock message MUST be responded to with a block message, allowing nodes to request all blocks using MSG_CMPCT_BLOCK getdatas and rely on their peer to pick an appropriate response. # While the current version sends transactions with the same encodings as is used in tx messages and elsewhere in the protocol, the version field in sendcmpct is intended to allow this to change in the future. For this reason, it is recommended that the code used to decode PrefilledTransaction and BlockTransactions messages be prepared to take a different transaction encoding, if and when the version field in sendcmpct changes in a future BIP. @@ -162,11 +163,32 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde There have been many proposals to save wire bytes when relaying blocks. Many of them have a two-fold goal of reducing block relay time and thus rely on the use of significant processing power in order to avoid introducing additional worst-case RTTs. Because this work is not focused primarily on reducing block relay time, its design is much simpler (ie does not rely on set reconciliation protocols). Still, in testing at the time of writing, nodes are able to relay blocks without the extra getblocktxn/blocktxn RTT around 90% of the time. With a smart compact-block-announcement policy, it is thus expected that this work might allow blocks to be relayed between nodes in 0.5*RTT instead of 1.5*RTT at least 75% of the time. ====Short transaction ID calculation==== -The short transaction ID calculation is designed to take absolutely minimal processing time during block compaction to avoid introducing serious DoS vulnerabilities such as those introduced by the bloom-filtering in BIP 37. As such, it is possible for a node to construct one compact-block representation of a block for relay to multiple peers. Additionally, only one cryptographic hash (2 SHA rounds) is used when calculating the short transaction IDs for an entire block. -SipHash-2-4 is used for calculating short transaction IDs primarily because it is fast and is reasonably able to limit the ability of an attacker who does not know the block hash or nonce to cause collisions in short transaction IDs. If an attacker were able to cause such collisions, filling mempools (and, thus, blocks) with them would cause poor network propagation of new (or non-attacker, in the case of a miner) blocks. As SipHash was designed, in part, to be used as a key selector for hash maps with malicious data, it should work very well for our use. +There are several design goals for the Short ID calculation: +* '''Performance''' The sender needs to compute short IDs for all block transactions, and the receiver for all mempool transactions they are being compared to. As we're easily talking about several thousand transactions, sub-microsecond processing per-transactions is needed. +* '''Space''' cmpctblock messages are never optional in this protocol, and contain a short ID for each non-prefilled transaction in the block. Thus, the size of short IDs is directly proportional to the maximum bandwidth savings possible. +* '''Collision resistance''' It should be hard for network participants to create transactions that cause collisions. If an attacker were able to cause such collisions, filling mempools (and, thus, blocks) with them would cause poor network propagation of new (or non-attacker, in the case of a miner) blocks. -The 8-byte nonce in short transaction ID calculation is used to introduce additional entropy on a per-node level. While the use of 8 bytes is sufficient for an attacker to maliciously cause short transaction ID collisions in their own block relay, this would have less of an effect than if such an attacker were relaying headers/invs and not responding to requests for the full block. +SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisons, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior. + +====Random collision probabilty==== + +Thanks to the block-header-based SipHash keys, we can assume that the only collisions on links between honest nodes are random ones. + +For each of the ''t'' block transactions, the receiver will compare its received short ID with that of a set of ''m'' mempool transactions. We assume that each of those ''t'' has a chance ''r'' to be included in that set of ''m''. If we use ''B'' bits short IDs, for each comparison between a received short ID and a mempool transaction, there is a chance of ''P = 1 - 1 / 2^B'' that a mismatch is detected as such. + +When comparing a given block transaction to the whole set of mempool transactions, there are 5 cases to distinguish: +# The receiver has exactly one match, which is the correct one. This has chance ''r * P^(m - 1)''. +# The receiver has no matches. This has chance ''(1 - r) * P^m''. +# The receiver has at least two matches, one of which is correct. This has chance ''r * (1 - P^(m - 1))''. +# The receiver has at least two matches, both of which are incorrect. This has chance ''(1 - r) * (1 - P^m - m * (1 - P) * P^(m - 1))''. +# The receiver has exactly one match, but an incorrect one. This has chance ''(1 - r) * m * (1 - P) * P^(m - 1)''. + +(note that these 5 numbers always add up to 100%) + +In case 1, we're good. In cases 2, 3, or 4, we request the full transaction because we know we're uncertain. Only in case 5, we fail to reconstruct. The chance that case 5 does not occur in any of the ''t'' transactions in a block is ''(1 - (1 - r) * m * (1 - P) * P^(m - 1))^t''. This expression is well approximated by ''1 - (1 - r) * m * (1 - P) * t'' = ''1 - (1 - r) * m * t / 2^B''. Thus, if we want only one in F block transmissions between honest nodes to fail under the conservative ''r = 0'' assumption, we need ''log2(F * m * t)'' bits hash functions. + +This means that ''B = 48'' bits short IDs suffice for blocks with up to ''t = 10000'' transactions, mempools up to ''m = 100000'' transactions, with failure to reconstruct at most one in ''F = 281474'' blocks. Since failure to reconstruct just means we fall back to normal inv/header based relay, it isn't necessary to avoid such failure completely. It just needs to be sufficiently rare they have a lower impact than random transmission failures (for example, network disconnection, node overloaded, ...). ==Backward compatibility== @@ -174,7 +196,7 @@ Older clients remain fully compatible and interoperable after this change. ==Implementation== -https://github.com/TheBlueMatt/bitcoin/tree/udp +https://github.com/bitcoin/bitcoin/pull/8068 ==Acknowledgements== diff --git a/bip-0152/protocol-flow.png b/bip-0152/protocol-flow.png Binary files differindex 207a78e..0d2b07d 100644 --- a/bip-0152/protocol-flow.png +++ b/bip-0152/protocol-flow.png |
