BIP Draft SENDTEMPLATE

[ajtowns]

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

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

https://gnusha.org/pi/bitcoindev/[email protected]/T/#u

[jonatack]

Post to bitcoindev group hasn't made it through

fixed, published

[murchandamus]

Interesting idea, thanks for sharing.

[murchandamus]

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]

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]

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