diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 2e4da43c..7270abd2 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. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index c44ad3e8..b5536665 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-0068.mediawiki b/bip-0068.mediawiki index 0082db38..03039242 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 19f74b60..e19e0e92 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -138,10 +138,10 @@ A simple output, paying to Alice might then look like: HASH160 EQUAL IF - + ELSE "24h" CHECKSEQUENCEVERIFY DROP - + ENDIF CHECKSIG @@ -153,10 +153,10 @@ With CHECKLOCKTIMEVERIFY, this would look like: HASH160 EQUAL IF - + ELSE "2015/12/15" CHECKLOCKTIMEVERIFY DROP - + ENDIF CHECKSIG @@ -181,13 +181,13 @@ Alice might look like the following in Alice's commitment transaction: IF "24h" CHECKSEQUENCEVERIFY 2DROP - + ELSE EQUAL NOTIF "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP ENDIF - + ENDIF CHECKSIG @@ -196,12 +196,12 @@ and correspondingly in Bob's commitment transaction: HASH160 DUP EQUAL SWAP EQUAL ADD IF - + ELSE "2015/10/20 10:33" CHECKLOCKTIMEVERIFY "24h" CHECKSEQUENCEVERIFY 2DROP - + ENDIF CHECKSIG diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 7497f50b..8290c137 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 2d160842..aee8646b 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 - + ELSE EQUAL NOTIF "Timestamp" CHECKLOCKTIMEVERIFY DROP ENDIF - + ENDIF CHECKSIG To create a MAST Root, it is flattened to 3 mutually exclusive branches: - HASH160 EQUALVERIFY "24h" CHECKSEQUENCEVERIFY DROP CHECKSIG - HASH160 EQUALVERIFY CHECKSIG - "Timestamp" CHECKLOCKTIMEVERIFY DROP CHECKSIG + HASH160 EQUALVERIFY "24h" CHECKSEQUENCEVERIFY DROP CHECKSIG + HASH160 EQUALVERIFY CHECKSIG + "Timestamp" CHECKLOCKTIMEVERIFY DROP CHECKSIG which significantly improves readability and reduces the witness size when it is redeemed. diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 309dfabe..892c0278 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -47,8 +47,8 @@ The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. 0x1976a914{20-byte-pubkey-hash}88ac. *For P2WSH witness program, -**if the witnessScript does not contain any OP_CODESEPERATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOuts. -**if the witnessScript contains any OP_CODESEPERATOR, the scriptCode is the evaluated script, with everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed removed, serialized as scripts inside CTxOuts. +**if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOuts. +**if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the evaluated script, with everything up to and including the last executed OP_CODESEPARATOR 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. @@ -139,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 @@ -248,7 +249,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit === Native P2WSH === -This example shows how OP_CODESEPERATOR and out-of-range SIGHASH_SINGLE are processed: +This example shows how OP_CODESEPARATOR and out-of-range SIGHASH_SINGLE are processed: @@ -264,6 +265,7 @@ This example shows how OP_CODESEPERATOR and out-of-range SIGHASH_SINGLE are proc 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 @@ -289,7 +291,7 @@ This example shows how OP_CODESEPERATOR and out-of-range SIGHASH_SINGLE are proc scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac ^^ - (please note that the not-yet-exectued OP_CODESEPERATOR is not removed from the scriptCode) + (please note that the not-yet-exectued OP_CODESEPARATOR is not removed from the scriptCode) preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000 sigHash: 82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391 public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae @@ -297,17 +299,17 @@ This example shows how OP_CODESEPERATOR and out-of-range SIGHASH_SINGLE are proc signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703 scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac - (everything up to the last executed OP_CODESEPERATOR, including that OP_CODESEPERATOR, are removed) + (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: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0000000047304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000 + The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000 -This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYONECANPAY does not commit to the input index: +This example shows how unexecuted OP_CODESEPARATOR is processed, and SINGLE|ANYONECANPAY does not commit to the input index: @@ -346,7 +348,7 @@ This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYO outpoint: e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000 scriptCode: 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac - (since the OP_CODESEPERATOR is not executed, nothing is removed from the scriptCode) + (since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode) hashOutputs: b258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d2 preimage: 0100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffffb258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d20000000083000000 sigHash: e9071e75e25b8a1e298a72f0d2e9f4f95a0f5cdf86a533cda597eb402ed13b3a @@ -356,7 +358,7 @@ This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYO outpoint: 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000 scriptCode: 2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac - (everything up to the last executed OP_CODESEPERATOR, including that OP_CODESEPERATOR, are removed) + (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed) hashOutputs: 91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca preimage: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b000000002468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffff91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca0000000083000000 sigHash: cd72f1f1a433ee9df816857fad88d8ebd97e09a75cd481583eb841c330275e54 @@ -392,7 +394,7 @@ This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYO === P2SH-P2WSH === -This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different SIGHASH types. +This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different SIGHASH types. @@ -418,7 +420,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 hashOutputs for ALL: - dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac) + dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac) = bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc hashOutputs for SINGLE: diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 036ba310..cfae0c0d 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. @@ -195,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 index 207a78e9..0d2b07d3 100644 Binary files a/bip-0152/protocol-flow.png and b/bip-0152/protocol-flow.png differ