I've been looking at weak blocks and I'm trying to sort out the good and the bad about it.
How it works
Weak blocks are blocks that does not appear in the blockchain, only in the p2p network. Miners produce these blocks with reduced difficulty, for example 1/20 of the strong block target difficulty. A message using weak blocks (weak or strong) can reference a previous weak block and add/remove transactions to/from it:
The good
Propagating B3 will only have to include the hash of WB3, a hash of T1, and the transaction T6. Rusty Russell and I did simulations on weak blocks using his bitcoin-corpus project. The result was that bytes sent at strong block propagation time was decreased from 825MB to 27 MB
This is a major improvement compared to sending raw strong blocks.
The bad
Overall bandwidth usage will increase from 825MB to roughly 1.5GB. In the minimalistic example above, The reasons are explained by T1 and T2 being propagated eventhough they are not used in the final strong block. Also T5 will be propagated twice (in WB3 and in WB4).
We often mention IBLT and weak blocks in the same sentence. There is no specific reason for it, they are both able to be implemented on its own, but the combination is an intriguing proposal. We would get the benefit of IBLTs on top of the benefit from weak blocks. However, using IBLT in combination with Weak blocks will mean that you take the transactions added in the new weak block and encode them in an IBLT. This is unfortunate, because new transactions included in the weak blocks are, well, new transactions. New transactions are expected to be more expensive to encode in IBLT since they may not have propagated the network fully yet. The result is that for every weak and strong block, we will encode the worst possible set of transactions, the "last minute transactions".
With plain IBLT we will encode all transactions in the block, including the last minute transactions. But with IBLT + weak blocks we will have to create eg 20 IBLTs, one for each weak and strong block, each encoding the last minute transactions. This means that the IBLT for the strong block will not be much smaller than the plain IBLT solution, the main cost lies within the last minute transactions.
On the good side, one benefit of using the combo (IBLT+weak blocks) is that if the IBLT decoding fails, we don't have to revert to raw block transfer. We can use plain weak blocks instead.
Doubts
I'm not totally convinced miners and full nodes will have incentives enough to use their bandwidth to propagate weak blocks:
Full nodes
Full nodes mostly care about overall bandwidth usage, they have no incentive to propagate things faster. They just want to keep up with things happening. More total bandwith as weak blocks implies, is probably just bad for them.
Miners
-
A miner mining an exotic block (one that cannot efficiently make use of any existing weak block) will benefit from weak blocks only if it finds and publishes its own weak block prior to actually finding a strong block.
-
A miner mining a mainstream block will benefit from everybody else's weak blocks. It will also benefit from its own published weak block IF it directly preceeds its own strong block which is unlikely.
So full nodes might not be interested in propagating weak blocks, while miners have very limited incentives to do it. However, they may still do it because rumour has it that miners mostly run with default settings of Bitcoin Core.
I asked about my doubt on the bitcoin-dev list and got an interesting answer from Gregory Maxwell, which I think is worth a read, but I don't think he said anything that changed my mind.
Conclusion
To conclude this post, I'm not sure Weak Blocks will work, and if it works, it may not add more than marginal improvements compared to an IBLT-only solution.
I've been a bit doubtful about weak blocks since day 1, eventhough I even gave a presentation with Rusty Russell about it (well, he did all the talking about weak blocks, I talked about IBLT, but I shared the stage with someone talking about weak blocks.)
I'd really appreciate any input you may have on this, because I probably don't have the full picture. Comment below, or drop me a line at kalle@popeller.io. Thank you!
