diff options
| -rw-r--r-- | README.mediawiki | 24 | ||||
| -rw-r--r-- | bip-0008.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0032.mediawiki | 25 | ||||
| -rw-r--r-- | bip-0078.mediawiki | 8 | ||||
| -rw-r--r-- | bip-0079.mediawiki | 3 | ||||
| -rw-r--r-- | bip-0085.mediawiki | 26 | ||||
| -rw-r--r-- | bip-0131.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0134.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0140.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0156.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0171.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0174.mediawiki | 29 | ||||
| -rw-r--r-- | bip-0180.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0325.mediawiki | 72 | ||||
| -rw-r--r-- | bip-0339.mediawiki | 9 | ||||
| -rw-r--r-- | bip-0341.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0342.mediawiki | 4 |
17 files changed, 116 insertions, 100 deletions
diff --git a/README.mediawiki b/README.mediawiki index 7a44341..ca28339 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -651,13 +651,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Suhas Daftuar | Standard | Proposed -|- +|- style="background-color: #ffcfcf" | [[bip-0131.mediawiki|131]] | Consensus (hard fork) | "Coalescing Transaction" Specification (wildcard inputs) | Chris Priest | Standard -| Draft +| Rejected |- style="background-color: #ffcfcf" | [[bip-0132.mediawiki|132]] | @@ -672,13 +672,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Alex Morcos | Standard | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0134.mediawiki|134]] | Consensus (hard fork) | Flexible Transactions | Tom Zander | Standard -| Draft +| Rejected |- | [[bip-0135.mediawiki|135]] | @@ -700,13 +700,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Christopher Gilliard | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0140.mediawiki|140]] | Consensus (soft fork) | Normalized TXID | Christian Decker | Standard -| Draft +| Rejected |- style="background-color: #cfffcf" | [[bip-0141.mediawiki|141]] | Consensus (soft fork) @@ -805,13 +805,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Wladimir J. van der Laan | Standard | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0156.mediawiki|156]] | Peer Services | Dandelion - Privacy Enhancing Routing | Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath | Standard -| Draft +| Rejected |- | [[bip-0157.mediawiki|157]] | Peer Services @@ -833,13 +833,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Jonas Schnelli | Standard | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0171.mediawiki|171]] | Applications | Currency/exchange rate information API | Luke Dashjr | Standard -| Draft +| Rejected |- style="background-color: #cfffcf" | [[bip-0173.mediawiki|173]] | Applications @@ -882,13 +882,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Emil Engler, MarcoFalke, Luke Dashjr | Informational | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0180.mediawiki|180]] | Peer Services | Block size/weight fraud proof | Luke Dashjr | Standard -| Draft +| Rejected |- | [[bip-0197.mediawiki|197]] | Applications diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index a16c211..6fa8cea 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -127,7 +127,7 @@ Note that a block's state never depends on its own nVersion; only on that of its case STARTED: int count = 0; - walk = block.parent; + walk = block; for (i = 0; i < 2016; i++) { walk = walk.parent; if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 9339307..f2f1e48 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -272,31 +272,6 @@ Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45 ** ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y ** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L -==Implementations== - -Two Python implementations exist: - -PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features. BIP32Utils (https://pypi.org/project/bip32utils/) is a library and command line interface specifically focused on BIP0032 wallets and scripting. - -2 Java implementations exist: https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32 - -A C++ implementation is available at https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h - -An Objective-C implementation is available at https://github.com/oleganza/CoreBitcoin/blob/master/CoreBitcoin/BTCKeychain.h - -A Ruby implementation is available at https://github.com/GemHQ/money-tree - -Two Go implementations exist: - -hdkeychain (https://github.com/conformal/btcutil/tree/master/hdkeychain) provides an API for bitcoin hierarchical deterministic extended keys (BIP0032). Go HD Wallet (https://github.com/WeMeetAgain/go-hdwallet). - -Two JavaScript implementations exist: available at https://github.com/sarchar/brainwallet.github.com/tree/bip32 and https://github.com/bitpay/bitcore - -A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php - -A C# implementation is available at https://github.com/MetacoSA/NBitcoin (ExtKey, ExtPubKey) - -A Haskell implementation is available at https://github.com/haskoin/haskoin together with a CLI interface at https://github.com/np/hx ==Acknowledgements== diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki index 7d0b9bb..c795343 100644 --- a/bip-0078.mediawiki +++ b/bip-0078.mediawiki @@ -64,7 +64,7 @@ Other than that, our proposal is very similar. In a payjoin payment, the following steps happen: -* The receiver of the payment, presents a [[bip-021.mediawiki|BIP 21 URI]] to the sender with a parameter <code>pj=</code> describing a payjoin endpoint. +* The receiver of the payment, presents a [[bip-0021.mediawiki|BIP 21 URI]] to the sender with a parameter <code>pj=</code> describing a payjoin endpoint. * The sender creates a signed, finalized PSBT with witness UTXO or previous transactions of the inputs. We call this PSBT the <code>original</code>. * The receiver replies back with a signed PSBT containing his own signed inputs/outputs and those of the sender. We call this PSBT <code>Payjoin proposal</code>. * The sender verifies the proposal, re-signs his inputs and broadcasts the transaction to the Bitcoin network. We call this transaction <code>Payjoin transaction</code>. @@ -121,7 +121,7 @@ The payjoin proposal MUST NOT: ===BIP21 payjoin parameters=== -This proposal is defining the following new [[bip-021.mediawiki|BIP 21 URI]] parameters: +This proposal is defining the following new [[bip-0021.mediawiki|BIP 21 URI]] parameters: * <code>pj=</code>: Represents an http(s) endpoint which the sender can POST the original PSBT. * <code>pjos=0</code>: Signal to the sender that they MUST disallow [[#output-substitution|payment output substitution]]. (See [[#unsecured-payjoin|Unsecured payjoin server]]) @@ -665,11 +665,11 @@ A successful exchange with: ==Backward compatibility== -The receivers are advertising payjoin capabilities through [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]]. +The receivers are advertising payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]]. Senders not supporting payjoin will just ignore the <code>pj</code> variable and thus, will proceed to normal payment. ==Special thanks== Special thanks to Kukks for developing the initial support to BTCPay Server, to junderw, AdamISZ, lukechilds, ncoelho, nopara73, lontivero, yahiheb, SomberNight, andrewkozlik, instagibbs, RHavar for all the feedback we received since our first implementation. -Thanks again to RHavar who wrote the [[https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki|BIP79 Bustapay]] proposal, this gave a good starting point for our proposal. +Thanks again to RHavar who wrote the [[bip-0079.mediawiki|BIP79 Bustapay]] proposal, this gave a good starting point for our proposal. diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index 99430d9..c8f2104 100644 --- a/bip-0079.mediawiki +++ b/bip-0079.mediawiki @@ -5,10 +5,11 @@ Author: Ryan Havar <rhavar@protonmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0079 - Status: Proposed + Status: Replaced Type: Informational Created: 2018-10-05 License: CC0-1.0 + Superseded-By: 78 </pre> diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 029de1a..7c4cbca 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -58,7 +58,7 @@ INPUT: OUTPUT: * DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0 -* DERIVED ENTROPY=6bea85e51a05e6dbaf2ccee05097758213807997ba936589cef01c8f19c0079f395a0cd045efa3438677f3ef9ad34c9a68506626c5a17e51ed5e177852ee7fdc +* DERIVED ENTROPY=efecfbccffea313214232d29e71563d941229afb4338c21f9517c41aaa0d16f00b83d2a09ef747e7a64e8e2bd5a14869e693da66ce94ac2da570ab7ee48618f7 ====Test case 2==== INPUT: @@ -67,7 +67,7 @@ INPUT: OUTPUT * DERIVED KEY=503776919131758bb7de7beb6c0ae24894f4ec042c26032890c29359216e21ba -* DERIVED ENTROPY=6da87ce3a71869b7a644c9d574f67df168fee8c6b24bc0832ef3cc43e23ca5055dd0458431caa5b5b33113b1d7bbd706c20a5ea3b408808402f553ddf1a3d6d4 +* DERIVED ENTROPY=70c6e3e8ebee8dc4c0dbba66076819bb8c09672527c4277ca8729532ad711872218f826919f6b67218adde99018a6df9095ab2b58d803b5b93ec9802085a690e ==Reference Implementation== @@ -147,7 +147,7 @@ Words Table |} ====12 English words==== -BIP39 English 12 word mnemonic seed +BIP39 English 12 word mnemonic seed 128 bits of entropy as input to BIP39 to derive 12 word mnemonic @@ -188,12 +188,7 @@ OUTPUT: ===HD-Seed WIF=== Application number: 2' -Uses 256 bits of entropy as the secret exponent to derive a private key and encode as a compressed WIF which will be used as the hdseed for Bitcoin Core wallets. - -There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users should iterate to the next index). - -From BIP32: -> In case parse<sub>256</sub>(I<sub>L</sub>) ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.) +Uses 256 bits[1] of entropy as the secret exponent to derive a private key and encode as a compressed WIF which will be used as the hdseed for Bitcoin Core wallets. Path format is <code>m/83696968'/2'/{index}'</code> @@ -208,16 +203,16 @@ OUTPUT ===XPRV=== Application number: 32' -Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero. +Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero. Path format is <code>m/83696968'/32'/{index}'</code> INPUT: * MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb -* PATH: m/83696968'/39'/0' +* PATH: m/83696968'/32'/0' OUTPUT -* DERIVED ENTROPY=7040bb53104f27367f317558e78a994ada7296c6fde36a364e5baf206e502bb1 +* DERIVED ENTROPY=ead0b33988a616cf6a497f1c169d9e92562604e38305ccd3fc96f2252c177682 * DERIVED WIF=xprv9s21ZrQH143K2srSbCSg4m4kLvPMzcWydgmKEnMmoZUurYuBuYG46c6P71UGXMzmriLzCCBvKQWBUv3vPB3m1SATMhp3uEjXHJ42jFg7myX ===HEX=== @@ -254,6 +249,13 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo BIP32, BIP39 +==Footnotes== + +[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users should iterate to the next index). + +From BIP32: +> In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.) + ==Copyright== This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. diff --git a/bip-0131.mediawiki b/bip-0131.mediawiki index 5938138..25ba3a7 100644 --- a/bip-0131.mediawiki +++ b/bip-0131.mediawiki @@ -5,7 +5,7 @@ Author: Chris Priest <cp368202@ohiou.edu> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0131 - Status: Draft + Status: Rejected Type: Standards Track Created: 2015-11-30 License: PD diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki index 74f6302..b7c33cf 100644 --- a/bip-0134.mediawiki +++ b/bip-0134.mediawiki @@ -5,7 +5,7 @@ Author: Tom Zander <tomz@freedommail.ch> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0134 - Status: Draft + Status: Rejected Type: Standards Track Created: 2016-07-27 License: CC-BY-SA-4.0 diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki index 9fb52b4..88131f4 100644 --- a/bip-0140.mediawiki +++ b/bip-0140.mediawiki @@ -5,7 +5,7 @@ Author: Christian Decker <decker.christian@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0140 - Status: Draft + Status: Rejected Type: Standards Track Created: 2015-10-14 License: PD diff --git a/bip-0156.mediawiki b/bip-0156.mediawiki index dde928a..dcfed1f 100644 --- a/bip-0156.mediawiki +++ b/bip-0156.mediawiki @@ -9,7 +9,7 @@ Shaileshh Bojja Venkatakrishnan <shaileshh.bv@gmail.com> Pramod Viswanath <pramodv@illinois.edu> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0156 - Status: Draft + Status: Rejected Type: Standards Track Created: 2017-06-09 License: CC0-1.0 diff --git a/bip-0171.mediawiki b/bip-0171.mediawiki index 11eb109..c4a8414 100644 --- a/bip-0171.mediawiki +++ b/bip-0171.mediawiki @@ -5,7 +5,7 @@ Author: Luke Dashjr <luke+bip@dashjr.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0171 - Status: Draft + Status: Rejected Type: Standards Track Created: 2017-03-04 License: BSD-2-Clause diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index a6e2534..65fa9a9 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -143,13 +143,13 @@ The currently defined per-input types are defined as follows: * Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> ** Key: None. The key must only contain the 1 byte type. ***<tt>{0x00}</tt> -** Value: The transaction in network serialization format the current input spends from. This should only be present for inputs which spend non-segwit outputs. However, if it is unknown whether an input spends a segwit output, this type should be used. +** Value: The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref> *** <tt>{transaction}</tt> * Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> ** Key: None. The key must only contain the 1 byte type. *** <tt>{0x01}</tt> -** Value: The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. +** Value: The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt> *** <tt>{serialized transaction output({output value}|<scriptPubKey>)}</tt> * Type: Partial Signature <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> @@ -200,6 +200,30 @@ The currently defined per-input types are defined as follows: ** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. *** <tt>{porCommitment}</tt> +* Type: RIPEMD160 preimage <tt>PSBT_RIPEMD160 = 0x0a</tt> +** Key: The resulting hash of the preimage +*** <tt>{0x0a}|{20-byte hash}</tt> +** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm +*** <tt>{preimage}</tt> + +* Type: SHA256 preimage <tt>PSBT_SHA256 = 0x0b</tt> +** Key: The resulting hash of the preimage +*** <tt>{0x0b}|{32-byte hash}</tt> +** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm +*** <tt>{preimage}</tt> + +* Type: HASH160 preimage <tt>PSBT_HASH160 = 0x0c</tt> +** Key: The resulting hash of the preimage +*** <tt>{0x0c}|{20-byte hash}</tt> +** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm +*** <tt>{preimage}</tt> + +* Type: HASH256 preimage <tt>PSBT_HASH256 = 0x0d</tt> +** Key: The resulting hash of the preimage +*** <tt>{0x0d}|{32-byte hash}</tt> +** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice +*** <tt>{preimage}</tt> + * Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> ** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. *** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> @@ -349,6 +373,7 @@ The Signer must only accept a PSBT. The Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs. Before signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction. Before signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO. +The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO<tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref> The Signer should not need any additional data sources, as all necessary information is provided in the PSBT format. The Signer must only add data to a PSBT. Any signatures created by the Signer must be added as a "Partial Signature" key-value pair for the respective input it relates to. diff --git a/bip-0180.mediawiki b/bip-0180.mediawiki index 9f6bd18..721b0b7 100644 --- a/bip-0180.mediawiki +++ b/bip-0180.mediawiki @@ -5,7 +5,7 @@ Author: Luke Dashjr <luke+bip@dashjr.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0180 - Status: Draft + Status: Rejected Type: Standards Track Created: 2017-03-17 License: BSD-2-Clause diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki index f273e14..ff1a145 100644 --- a/bip-0325.mediawiki +++ b/bip-0325.mediawiki @@ -26,36 +26,48 @@ A new type of test network would be more suitable for integration testing by org A new type of network ("signet"), which takes an additional consensus parameter called the challenge (scriptPubKey). The challenge can be a simple pubkey (P2PKH style), or a k-of-n multisig, or any other script you would want. -The witness commitment of the coinbase transaction is extended to include a secondary commitment (the signature/solution): - - 1-4 bytes - Push the following (x + 4) bytes - 4 bytes - Signet header (0xecc7daa2) - x bytes - Solution (sigScript) - -Any push operations that do not start with the 4 byte signet header are ignored. Multiple push operations with the 4 byte signet header are ignored except for the first entry. - -Any signature operations contained within the challenge use SHA256d(modifiedBlockHash), i.e. the double-SHA256 digest of the following data as the sighash: - -{|class="wikitable" style="text-align: center;" -|- -!Type -!Size -!Name -|- -|Int32||4||nVersion -|- -|Uint256||32||hashPrevBlock -|- -|Uint256||32||modifiedMerkleRoot -|- -|Uint32||4||nTime -|- -|Uint32||4||nBits -|} - -The <code>modifiedMerkleRoot</code> hash is obtained by generating the merkle root of the block transactions, with the coinbase witness commitment as is, without the signet extension. This means the merkle root of the block is different from the merkle root in the signet commitment. This is needed, because the signature can never be included in the very message (in this case, a block) that is being signed. Apart from the signature, to facilitate block generation (mining), the block nonce value is the only other component of the block that the signet signature does not commit to. When grinding proof of work, the extended nonce cannot be used as it would invalidate the signature. Instead, simply resigning the same (or an updated) block will give a new search space. - -A block is considered fully validated if the above commitment is found, and its solution is valid. It is recommended that this verification is done directly before or after the witness commitment verification, as the data required to do both is approximately the same. +The witness commitment of the coinbase transaction is extended to include a secondary commitment (the signature/solution) of either: + + 1-4 bytes - Push the following (4 + x + y) bytes + 4 bytes - Signet scriptSig header (0xecc7daa2) + x bytes - scriptSig + y bytes - scriptWitness + +The scriptSig is serialized by first encoding its length as CompactSize. If the scriptWitness is empty, it is encoded as 0 bytes, otherwise it is encoded in the usual way (see BIP 141 "witness" encoding). + +Any push operations that do not start with the 4 byte Signet header are ignored. Multiple push operations with the 4 byte Signet header are ignored except for the first instance of the header. + +To sign the block or verify a block signature, two virtual transactions, each with a single input and output are constructed from the block as follows. + +The "to_spend" transaction is: + + nVersion = 0 + nLockTime = 0 + vin[0].prevout.hash = 0000...000 + vin[0].prevout.n = 0xFFFFFFFF + vin[0].nSequence = 0 + vin[0].scriptSig = OP_0 PUSH72[ block_data ] + vin[0].scriptWitness = [] + vout[0].nValue = 0 + vout[0].scriptPubKey = signet_challenge + +where block_data is the serialization of the block's nVersion, hashPrevBlock, signet_merkle_root, and nTime. The <code>signet_merkle_root</code> is obtained by generating the merkle root of the block transactions, after modifying the coinbase witness commitment by replacing the signet solution with an empty solution (that is, the witness commitment includes a four byte push of the Signet header with no additional solution data, and no prior pushes beginning with the Signet header). This means the merkle root of the block is different from the merkle root in the signet commitment. This is needed, because the signature can never be included in the very message (in this case, a block) that is being signed. + +The "to_sign" transaction is: + + nVersion = 0 + nLockTime = 0 + vin[0].prevout.hash = to_spend.txid + vin[0].prevout.n = 0 + vin[0].nSequence = 0 + vout[0].nValue = 0 + vout[0].scriptPubKey = signet_challenge + +The scriptSig and/or scriptWitness for <code>vin[0]</code> are filled in from the Signet header push above. + +To simplify block generation (mining), the signature also does not commit to the the block nonce value, so that rolling the nonce to generate proof-of-work does not also require regenerating signatures. When grinding proof of work, the extended nonce cannot be used as it would invalidate the signature. Instead, simply resigning the same (or an updated) block will give a new search space. + +A block is considered fully validated only if the to_sign transaction is a valid spend of the to_spend transaction. It is recommended that this verification is done directly before or after the witness commitment verification, as the data required to do both is approximately the same. == Genesis Block and Message Start == diff --git a/bip-0339.mediawiki b/bip-0339.mediawiki index 1b04d38..806ba1c 100644 --- a/bip-0339.mediawiki +++ b/bip-0339.mediawiki @@ -18,7 +18,7 @@ based on the BIP 141 wtxid of a transaction, rather than its txid. ==Motivation== -Historically, the INV messages sent on the Bitcoin peer-to-peer network to +Historically, the inv messages sent on the Bitcoin peer-to-peer network to announce transactions refer to transactions by their txid, which is a hash of the transaction that does not include the witness (see BIP 141). This has been the case even since Segregated Witness (BIP 141/143/144) has been adopted by @@ -41,9 +41,10 @@ announcing and fetching transactions. # A new wtxidrelay message is added, which is defined as an empty message where pchCommand == "wtxidrelay". # The protocol version of nodes implementing this BIP must be set to 70016 or higher. -# The wtxidrelay message must be sent in response to a VERSION message from a peer whose protocol version is >= 70016, and prior to sending a VERACK. -# A new inv type MSG_WTX (0x00000005) is added, for use in both INV messages and GETDATA requests, indicating that the hash being referenced is a transaction's wtxid. In the case of GETDATA requests, MSG_WTX implies that the transaction being requested should be serialized with witness as well, as described in BIP 144. -# After a node has sent and received a "wtxidrelay" message to/from a given peer, the node is required to use the MSG_WTX inv-type when announcing transactions to that peer, or requesting announced transactions from that peer. +# The wtxidrelay message MUST be sent in response to a version message from a peer whose protocol version is >= 70016 and prior to sending a verack. A wtxidrelay message received after a verack message MUST be ignored or treated as invalid. +# A new inv type MSG_WTX (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is a transaction's wtxid. In the case of getdata requests, MSG_WTX implies that the transaction being requested should be serialized with witness as well, as described in BIP 144. +# After a node has received a wtxidrelay message from a peer, the node MUST use the MSG_WTX inv type when announcing transactions to that peer. +# After a node has received a wtxidrelay message from a peer, the node SHOULD use a MSG_WTX getdata message to request any announced transactions. A node MAY still request transactions from that peer using MSG_TX getdata messages, such as for transactions not recently announced by that peer (like the parents of recently announced transactions). ==Backward compatibility== diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index f5e4e90..7ac5bf8 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -137,7 +137,7 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem ==== Taproot key path spending signature validation ==== To validate a signature ''sig'' with public key ''q'': -* If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSigHash</sub>(0x00 || SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSigHash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSigHash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. +* If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSighash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSighash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. * If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00<ref>'''Why can the <code>hash_type</code> not be <code>0x00</code> in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended</ref> and Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(sig[64], 0)), sig[0:64])''. * Otherwise, fail<ref>'''Why permit two signature lengths?''' By making the most common type of <code>hash_type</code> implicit, a byte can often be saved.</ref>. diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index c4af38a..3cf87a3 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -110,8 +110,8 @@ To validate a signature ''sig'' with public key ''p'': * Compute the tapscript message extension ''ext'', consisting of the concatenation of: ** ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#design|BIP341]] ** ''key_version'' (1): a constant value ''0x00'' representing the current version of public keys in the tapscript signature opcode execution. -** ''codesep_pos'' (4): the opcode position of the last executed <code>OP_CODESEPARATOR</code> before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed. -* If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSigHash</sub>(0x00 || SigMsg(0x00, 1) || ext), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. +** ''codesep_pos'' (4): the opcode position of the last executed <code>OP_CODESEPARATOR</code> before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed. Opcodes in parsed but unexecuted branches count towards this value as well. +* If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 1) || ext), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. * If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg(sig[64], 1) || ext), sig[0:64])''. * Otherwise, fail. |