BIP153: SENDTEMPLATE

ajtowns commented at 1:32 am on August 18, 2025: contributor

Adds a BIP for SENDTEMPLATE, GETTEMPLATE, TEMPLATE p2p messages. Discussion links:

https://delvingbitcoin.org/t/sharing-block-templates/1906

https://gnusha.org/pi/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/T/#u

jonatack added the label New BIP on Aug 18, 2025

jonatack commented at 4:45 pm on August 18, 2025: member

Post to bitcoindev group hasn’t made it through

fixed, published

in bip-ajtowns-sendtemplate.md:16 in a89b303492 outdated

11+  License: BSD-3-Clause
12+```
13+
14+## Abstract
15+
16+This BIP describes the use of [BIP-152 compact blocks][BIP-152] enccoding

murchandamus commented at 10:32 pm on August 18, 2025:

0This BIP describes the use of [BIP-152 compact blocks][BIP-152] encoding

in bip-ajtowns-sendtemplate.md:74 in a89b303492 outdated

69+and should be the hash of a block made up of those transactions.
70+4. The transactions making up the payload of the template should be valid
71+as a block -- for example all unconfirmed parents of a transaction should be
72+included before the transaction, and consensus limits should be respected.
73+5. A block containing the transactions making up the payload must not
74+exceed four million weight units as defined in [BIP-141][BIP-141].

murchandamus commented at 10:48 pm on August 18, 2025:

Have you considered allowing more data than just the top block? Otherwise, would you recommend that a node requests a template after each block is found for the first few new blocks after they come online? Have you considered a reconciliation-based approach akin to Erlay?

ajtowns commented at 6:04 am on August 20, 2025:

See discussion in the delving thread.

I think having two blocks of txs could make sense, but in adversarial situations it doubles the potential memory usage and it’s not immediately clear what would be a sensible way of addressing that.

My thought is that deploying a simple design and getting some real-world data to iterate on makes sense. You could update the specification to announce “SENDTEMPLATE 2” indicating you support v2, which indicates to your peers they can send you a “GETTEMPLATE 2” message requesting a 2MvB template rather than a 1MvB template, eg.

Likewise sending set differences through could make sense (and wouldn’t need the complexity of minisketch since the sender knows their own previous templates), but there’s still a lot of design space left, so getting real-world data also seems useful for resolving that. (Likewise an updated spec could allow SENDTEMPLATE 2D to indicate deltas are supported, and GETTEMPLATE 2 $hash could request a 2MvB template encoded as a delta against the previous template with hash $hash)

ajtowns commented at 5:03 am on August 21, 2025:

Changed the limit from 4M weight units to 8M weight units.

murchandamus commented at 10:54 pm on August 18, 2025: contributor

Interesting idea, thanks for sharing.

ajtowns force-pushed on Aug 20, 2025

ajtowns force-pushed on Aug 21, 2025

murchandamus commented at 7:11 pm on August 26, 2025: contributor

From an editorial perspective, this looks close to ready. I noticed that there is no Rationale section, yet. You could perhaps link to the Delving discussion as that seems to have been the most active one I saw.

ajtowns commented at 4:25 am on August 27, 2025: contributor

Updated with post-history in metadata and some rationale

murchandamus commented at 9:34 pm on August 27, 2025: contributor

Thanks, good improvements.

ajtowns commented at 8:40 am on September 1, 2025: contributor

Time to request a bip number then I guess?

murchandamus commented at 8:53 pm on September 4, 2025: contributor

Let’s call this BIP 153 then!

murchandamus renamed this:
~~BIP Draft SENDTEMPLATE~~
BIP 153 SENDTEMPLATE
on Sep 4, 2025

murchandamus renamed this:
~~BIP 153 SENDTEMPLATE~~
BIP153: SENDTEMPLATE
on Sep 4, 2025

in bip-ajtowns-sendtemplate.md:52 in 6fbdd71cd4 outdated

47+3. If a node implements this BIP, it must send the `sendtemplate`
48+message after `version` and before `verack`.
49+
50+### `gettemplate`
51+
52+1. The `gettemplate` message is defined as a message with `pchCommand ==

Roasbeef commented at 10:05 pm on September 4, 2025:

Any reason to not also allocate a message ID from the range specific in BIP 324?

The guidelines specify that if a message is sent more than once per connection then a number you be allocated (IIUC both this and the template message):

We recommend reserving 1-byte type IDs for message types that are sent more than once per direction per connection.

in bip-ajtowns-sendtemplate.md:63 in 6fbdd71cd4 outdated

58+3. A `gettemplate` message must not be sent if a `sendtemplate` message
59+was not already received.
60+4. Upon receipt of a `gettemplate` message, a node may reply with a
61+`template` message.
62+
63+### `template`

Roasbeef commented at 10:06 pm on September 4, 2025:

blocktemplate instead? Otherwise, at a glance the semantics of the message are ambiguous.

ajtowns commented at 2:34 am on September 5, 2025:

Message type can only be 12 characters, blocktemplate has 13. I don’t think there’s anything very ambiguous about template in bitcoin even without block, however.

in bip-ajtowns-sendtemplate.md:35 in 6fbdd71cd4 outdated

30+and (b) provides a way for transactions that may have dropped out of
31+nodes' mempools to be rebroadcast across the network by third parties,
32+potentially providing better privacy than if only the nodes directly
33+involved in the transaction would rebroadcast it.
34+
35+## Specification

Roasbeef commented at 10:09 pm on September 4, 2025:

I notice there’s no p2p protocol version bump, why is that?. IIUC, this message is only useful if you’re talking with a peer that’s directly peered, or is the Bitcoin node backing a mining pool. A p2p version bump would permit nodes to seek out other nodes that meet this requirement, instead of blindly connecting out to find such nodes.

ajtowns commented at 2:38 am on September 5, 2025:

If you want to seek out peers that support a feature you need a service flag, not a protocol version. Using a pre-verack negotiation message gives you all the benefits of a protocol version bump, with less potential for contention where two bips developed at the same time both bump the protocol version to the same value.

Roasbeef commented at 1:38 am on September 6, 2025:

Ah yeah I meant service flag 😅.

The service flag would also allow for peers to find other supporting peers via DNS queries.

BIP153: add template sharing bip 86d20db638

ajtowns force-pushed on Sep 8, 2025

BIP153: SENDTEMPLATE #1937