SENDTEMPLATE Tracking Issue #33691

1. 
   ajtowns commented at 4:11 pm on October 23, 2025: contributor

   Plan:

   • Protocol specification BIN25-2 and BIP153 PR#1937
   • Implementation:
     • PR#33191 - Providing templates to peers
     • sendtemplate3 branch - Using templates from peers
   • Live tests
     • signet: inquisition 29.x (#96) nodes provide templates, eg inquisition.bitcoin-signet.net
     • mainnet: cornflower.erisian.com.au provides templates currently
     • warnet simulation?
   • Discussion:
     • https://delvingbitcoin.org/t/sharing-block-templates/1906
   • Potential benefits: (tick with data confirming benefit)
     • Quick population of mempool on initial start
     • Quicker relay of top-of-mempool transactions
     • Improved compact block propagation with diverse mempool policies
     • Transaction rebroadcast without participation of sender/receiver
   • Future ideas:
     • Include 2MvB of transactions, not just the next block
     • Send templates shortly after construction
     • Coordinate template construction with INV announcements better
     • Send diffs since prior templates to reduce bandwidth
     • Use set reconciliation to improve compact block reconstruction (see delving discussion)
     • Use reduced siphash to make compact block calculations faster?
2. ajtowns added the label Tracking Issue on Oct 23, 2025
3. bitcoin deleted a comment on Oct 25, 2025
4. 
   ajtowns commented at 2:53 pm on December 4, 2025: contributor

   It looks like reusing compact block messages doesn’t make sense – including two blocks’ worth of data seems pretty useful, but that could result in an ~8MB blocktxns data if your mempool was empty and the top of the mempool was full of inscriptions, which would in turn exceed the 4MB maximum message size we have. We could expand the maximum message size, but large messages can be a DoS vector, so splitting the template response up probably makes more sense. That also provides the opportunity to describe the block template more directly, rather than pretending it’s a block with a header committing to the txids and perhaps a coinbase committing to the wtxids. So current work is on redesigning the p2p messages and making template reconstruction an iterative thing (“here’s the first batch of missing transactions”, …, “here’s the next batch of missing transactions”) rather than a one shot (“here’s all the missing transactions, you now have a template!”)

Contributors
ajtowns

Labels
Tracking Issue