diff --git a/bip-ajtowns-sendtemplate.md b/bip-ajtowns-sendtemplate.md new file mode 100644 index 0000000000..4a4bae0c0a --- /dev/null +++ b/bip-ajtowns-sendtemplate.md @@ -0,0 +1,150 @@ +``` + BIP: TBD + Layer: Peer Services + Title: Sharing Block Templates with Peers + Author: Anthony Towns + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-TBD + Status: Draft + Type: Standards Track + Created: 2025-08-08 + License: BSD-3-Clause + Post-History: https://gnusha.org/pi/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/T/#u + https://delvingbitcoin.org/t/sharing-block-templates/1906 +``` + +## Abstract + +This BIP describes the use of [BIP-152 compact blocks][BIP-152] encoding +for sharing block templates (ie, the next block's predicted transactions) +with peers. + +## Motivation + +The primary goal of sharing block templates is to improve the +effectiveness of compact block reconstruction, particularly for nodes +who have a more restrictive transaction relay policy than their peers. + +Secondary benefits of this approach are that it (a) allows nodes that have +not been online recently to quickly repopulate the top of their mempool, +and (b) provides a way for transactions that may have dropped out of +nodes' mempools to be rebroadcast across the network by third parties, +potentially providing better privacy than if only the nodes directly +involved in the transaction would rebroadcast it. + +## Specification + +This introduces three new messages (`sendtemplate`, `gettemplate`, +`template`), and reuses two others (`getblocktxn`, `blocktxn`, defined in +[BIP-152][BIP-152]). + +### `sendtemplate` + +1. The `sendtemplate` message is defined as a message with `pchCommand == +"sendtemplate"`. +2. No payload data should be provided, however, for upgrade purposes, +any payload data received should be ignored. +3. If a node implements this BIP, it must send the `sendtemplate` +message after `version` and before `verack`. + +### `gettemplate` + +1. The `gettemplate` message is defined as a message with `pchCommand == +"gettemplate"`. +2. No payload data should be provided. +3. If the node received a `sendtemplate` message, it may send a +`gettemplate` message at any time after `verack`, in order +to request a new template. +3. A `gettemplate` message must not be sent if a `sendtemplate` message +was not already received. +4. Upon receipt of a `gettemplate` message, a node may reply with a +`template` message. + +### `template` + +1. The `template` message is defined as a message with `pchCommand == +"template"` and a payload of a serialized `HeaderAndShortIDs` message +(see [BIP-152][BIP-152]) containing a recent template. +2. A `template` message may only be sent in response to a `gettemplate` +message. +3. The `header` hash included in the payload must be a unique hash, +and should be the hash of a block made up of those transactions. +4. The transactions making up the payload of the template should be +valid for block inclusion -- for example all unconfirmed parents of a +transaction should be included before the transaction, and consensus +limits should be respected. +5. The cumulative weight of the transactions making up the +payload must not exceed eight million weight units as defined in +[BIP-141][BIP-141]. Note that this is twice the block weight limit, and +does not include the overhead that assembling those transactions into +a block would involve (header, coinbase and tx count serialization), +so this can be slightly more than two blocks' worth of transactions. +6. After sending a `template` message, a node should accept a +`sendblocktxns` message that specify the template's `header` hash, and +respond with a `blocktxns` message including the appropriate transaction +data, exactly as if it had sent a `cmpctblock` message with the same +payload as the `template` message. It should be able to provide such +transactions for a moderate amount of time after sending a template +(eg, five minutes). If it cannot provide a correct `blocktxns` response, +it should ignore the request. + +## Rationale + +### Protocol design + +This design closely follows the "low-bandwidth mode" specified in +[BIP-152][BIP-152], providing a negotiation message, the ability for +a peer to request data, and a response encoding the data via shortids. +This is designed to be relatively low bandwidth, but importantly also +to be simple to implement and deploy in any software that has already +implemented compact block relay. + +### Template size + +This BIP specifies a maximum template size equivalent to two blocks' +worth of transactions. This is chosen so that even if two blocks are +mined in quick succession, prior templates that were shared using this +protocol are likely to have included the transactions from both blocks. + +If blocks are found randomly, it is expected that 5% of blocks will +be found within 30 seconds of the previous block, which is about 7 per +day; so this seems frequent enough to address explicitly. In contrast, +the chances of finding two blocks within 30 seconds of a block is only +0.12%, so even in ideal circumstances, is only expected to occur about +once per week, and thus further optimisation does not seem warranted. + +### Forward compatibility + +It is likely that improvements can be made to this design, particularly +to further reduce the bandwidth needed for updating templates. This +could be achieved by: + + * defining a new payload for the `template` message with a new, more + efficient encoding of (changes to) the template data + * adding a payload to the `gettemplate` message so that peers can + indicate they will accept a new encoding of the template + * adding a payload to the `sendtemplate` message to indicate that the + `gettemplate` payload will be accepted + +## Recommendations + +TBA + +## Backward compatibility + +Older clients remain fully compatible and interoperable after this change, +provided they do not disconnect peers who send unexpected messages between +`version` and `verack`. + +## Acknowledgements + +Thanks to Gregory Sanders who made a similar proposal around [compact +weak blocks][Sanders24] which was the inspiration for this. + +## Copyright + +This document is licensed under the 3-clause BSD license. + +[BIP-141]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki +[BIP-152]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki +[Sanders24]: https://delvingbitcoin.org/t/second-look-at-weak-blocks/805