diff options
| -rw-r--r-- | bip-0152.mediawiki | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 69abf7c..109bbb3 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -120,18 +120,18 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde # MSG_CMPCT_BLOCK inv objects MUST NOT appear anywhere except for in getdata messages. ====cmpctblock==== -# The cmpctblock message is defined as as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock". +# The cmpctblock message is defined as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock". # Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the short transaction ID for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message. # After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message. # A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block. # A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing chain with a valid proof-of-work. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing UTXO set entries. ====getblocktxn==== -# The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". +# The getblocktxn message is defined as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". # Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with either an appropriate blocktxn message, or a full block message. A blocktxn response MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. ====blocktxn==== -# The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn". +# The blocktxn message is defined as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn". # Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by: ## Taking the prefilledtxn transactions from the original cmpctblock and placing them in the marked positions. ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block. |