mirror of
https://github.com/bitcoin/bips.git
synced 2025-05-12 12:03:29 +00:00
Merge remote-tracking branch 'upstream/master'
# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
This commit is contained in:
Matt David
commit
cd9d2d37b5
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -47,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 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.
|
||||
**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.
|
||||
|
||||
@ -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 <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGHASH_SINGLE</code> 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 <code>OP_CODESEPARATOR</code> is processed, and <code>SINGLE|ANYONECANPAY</code> 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 <code>SIGHASH</code> 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:
|
||||
|
||||
@ -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==
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 17 KiB |
Loading…
x
Reference in New Issue
Block a user