Topic: fastblockrelay (Read 1084 times)

One difference (covered in the 49% attack thread) is that you still need to verify the blocks.  The suggestion was to forward the block even without signature checks.

However, the "block" message would not be sent for unverified blocks.

The header message could have the merkle tree and POW checked, but not transaction signatures.

Miners could still do the check once they receive the entire block, but there is no point in relay nodes doing it, before relaying.

The POW itself prevents it being exploited for DOS attacks.

Yeah, the OP in this thread was a comment in another thread about how to reduce loss of hashing power (it was split as it was deemed as off-topic).

I didn't mean to claim to have thought of a new idea.

Check this proposal, which I think is almost exactly that you propose: Increasing the Network Hashing Power by reducing block propagation time
https://bitcointalksearch.org/topic/bip-increasing-the-network-hashing-power-by-reducing-block-propagation-time-145066

The transactions should be sent in advance anyway.  A miner who has mines against known transactions will have his block propagate faster.

The point of that section was that miners forward preview blocks made up of just hashes.

If the preview is well propagated, then the header is enough.

You could forward the header immediately and then the fast block (with unverified unchecked).

If round trips are dominating, then that is already super-fast.  Isn't the point that signatures take a few ms each, or does caching verifications already fix that mostly?

Matt already added an optimisation for full-match Bloom filters. Re-using that work is perhaps not the cleanest protocol ever, you end up shipping merkle tree bits too, but it's also really really easy to do because the code already exists.

adding multiple round trip times, this is the exact opposite of the desire here. Round trip times can easily dominate the process. You already largely know what txn your peers have because you know what they've advertised to you, and you know what you've sent them. Bloom filters this way already. It works great. Sending a bit of extra data is no biggie, if you don't like it— relay early.

I clipped out a lot of details, half was superfluous, half is already in that code linked above. Patches not posts if you want things to matter. This is really off the topic of the paper and should probably be in another thread.

This message could be a hashes only.

"fastblock"
block header
boolean verified
hash[] txHashes

These blocks could be forwarded as long as they (appear to) extend the main chain.  The verified field indicates if the block was verified.

I think p2pool does something like that?

Nodes could respond by asking for all transactions that they are missing.

Except for initial download, there seems little point in using the original block message.


SPV nodes are supposed to use number of confirms for security.  If there is a 6 block fork, they are already in danger.

However, the verified flag at least puts the attacker at risk of disconnect.


Sending only the hashes accomplishes mostly that.  Let the node ask for missing transactions.

If nodes didn't forward until they had all the transactions, then it creates an incentive to make sure transactions are pushed in advance.

I think a "blockpreview" message would also be useful.  It would be like the blockfast message but would not actually meet POW (nonce = 0).

The preview would be a list of hashes to be included in a block.  Nodes would store (merkle-root, Hash[]) maps.

For a miner, the block propagation process could be

Miner sends (unverified) "headers" message containing the new block [ * ]

Peer checks if the header extends the block tree, if not it does nothing [ ** ]

Peer checks if POW is met and difficulty value is correct, if not, it disconnects

Peer checks if merkle root is in preview map cache, if not, it requests a "fastblock"

Peer checks if all transactions are known, if not, it requests the extra transactions.

Once the transactions are all known, it forwards the headers message (unverified).

Once the transactions have all been verified, the block can be stored to disk and added to the chain.

[ * ] The headers message would need a verified field
[ ** ] Headers would be forwarded even if they extend an alternative chain (but probably only within the last few blocks)