BIP: Increasing the Network Hashing Power by reducing block propagation time

[Mike Hearn]

Bear in mind that nodes already tell each other about what transactions they have and their peers track that, via inv broadcasts and mapAlreadyHave.

The Bloom filtering infrastructure already uses this. If you set a no-op 0xFF filter on a connection, then as long as you've announced a transaction via an inv, it won't be sent to you again when a block is relayed. If you did NOT announce it, the peer will push the tx data to you automatically, you don't have to ask for it.

[1715170638]

1715170638

[1715170638]

1715170638

[1715170638]

1715170638

[1715170638]

1715170638

[TierNolan]

Bear in mind that nodes already tell each other about what transactions they have and their peers track that, via inv broadcasts and mapAlreadyHave.

If you have already sent a "template", then you can confirm a block by sending the 80 byte header and a 32 byte hash. 

To distribute a block with 2000 350 byte transactions requires

Full Block: 2000 * 350 + 80 = 500kB
Header + tx hashes: 2000 * 32 + 80 = 64kB + coinbase
Header + short hashes: 2000 * 4 + 80 = 8kB + coinbase
Template: 32 + 80 = 112 bytes + coinbase

If the coinbase was included in the template, then it is simply 112 bytes.

If the template is sent 16 times per block, this represents 16 * 32 * 2000 = 1MB of extra data.  This means a 3X increase in network traffic.

If templates required 1/4 of the block difficulty, then sending the templates would require 50% increase in network bandwidth.

However, there is nothing preventing someone from reusing a template.  A miner who receives a template could verify it, and then just mine against it.

[rebroad]

What happened with this? This seems like a very good idea - and it also facilitates more power to node operators who, if they want, can more easily choose not to relay blocks containing very few transactions.