Template Sharing 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!”)
5. ajtowns renamed this:
   SENDTEMPLATE Tracking Issue
   Template Sharing Tracking Issue
   on Mar 2, 2026
6. 
   ajtowns commented at 6:33 am on March 2, 2026: contributor

   Have an updated approach ~90% specced and implemented at:

   • Updated spec
   • Implementation branch

   The main change is it no longer attempts to reuse the compact block messages, but has its own scheme:

   • GETTMPLT [oldtemplatehash]
   • TMPLT [newtemplatehash] [tiphash] [what txns to pull from old template] [shortids for new txns]
   • GETTMPLTTXNS [templatehash] [delta encoded idxs to missing txs]
   • TMPLTTXNS [templatehash] [~100kB of requested txns]
   • TMPLTTXNS [templatehash] [~100kB of requested txns]
   • TMPLTTXNS [templatehash] [~100kB of requested txns]

   Splitting the actual txns from the template into chunk avoids messages potentially going over 4MB and also allows the sender to interleave other messages in between (eg their own tx requests, or a block announcement if a real block comes in).

   The implementation has a bunch of privacy code (particularly providing different templates on different networks, building the template at the same time as we would be announcing INVs, extremely limited template relay over block-relay-only connections), but the final commits are still a bit vibe-codey, though I think the idea is roughly sound. The spec is still missing proper rationale descriptions for a bunch of concerns, including things the implementation takes into account.

   I did a flamegraph as a quick performance check. It ended up dominated by leveldb compaction, but it looks like the ratio between CreateNewBlock() + GenerateTemplate() + GetNextTemplateTx() and the existing TxDownloadManager::GetRequestsToSend() is about 67 to 119, so at idle (when it’s just regularly generating templates for the “outbounds” “network”) cpu usage seems fine at least.

   Anyway, if anyone wants to take a look, mess around, or otherwise provide feedback before I do another round of dev to get it more polished, links are above.

Contributors
ajtowns

Labels
Tracking Issue