BIP153: SENDTEMPLATE

README.mediawiki

@@ -882,6 +882,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Matt Corallo
 | Standard
 | Final
+|-
+| [[bip-0153.md|153]]
+| Peer Services
+| Sharing Block Templates with Peers
+| Anthony Towns
+| Standard
+| Draft
 |- style="background-color: #ffcfcf"
 | [[bip-0154.mediawiki|154]]
 | Peer Services

bip-0153.md

@@ -0,0 +1,151 @@
+```
+  BIP: 153
+  Layer: Peer Services
+  Title: Sharing Block Templates with Peers
+  Author: Anthony Towns <[email protected]>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0153
+  Status: Draft
+  Type: Standards Track
+  Created: 2025-09-05
+  License: BSD-3-Clause
+  Post-History: https://gnusha.org/pi/bitcoindev/[email protected]/T/#u
+                https://delvingbitcoin.org/t/sharing-block-templates/1906
+  Requires: 141, 152
+```
+
+## 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 specifies 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