Re: [bitcoin-dev] Weak block thoughts...

[Rusty Russell <rusty@rustcorp.com.au>]

Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> I've been thinking about 'weak blocks' and SPV mining, and it seems to me
> weak blocks will make things better, not worse, if we improve the mining
> code a little bit.
>
> First:  the idea of 'weak blocks' (hat tip to Rusty for the term) is for
> miners to pre-announce blocks that they're working on, before they've
> solved the proof-of-work puzzle. To prevent DoS attacks, assume that some
> amount of proof-of-work is done (hence the term 'weak block') to rate-limit
> how many 'weak block' messages are relayed across the network.
>
>
> Today, miners are incentivized to start mining an empty block as soon as
> they see a block with valid proof-of-work, because they want to spend as
> little time as possible mining a not-best chain.
>
> Imagine miners always pre-announce the blocks they're working on to their
> peers, and peers validate those 'weak blocks' as quickly as they are able.
>
> Because weak blocks are pre-validated, when a full-difficulty block based
> on a previously announced weak block is found, block propagation should be
> insanely fast-- basically, as fast as a single packet can be relayed across
> the network the whole network could be mining on the new block.

The bandwidth/latency argument is solid.  And if a block encodes to <
~3k, then we can just spray it to (some?) peers rather than using INV.

But validation is only trivially cachable if the delta to the previous
weak block is zero.  The "partially validated" cases need to be coded
with care (eg. total opcode constraints, tx order).

I was thinking as a first cut we do the opposite: don't validate weak
blocks at all (other than PoW), and just use them as a bandwidth
optimization.

Ambition is good though!

Chers,
Rusty.
PS.  Original idea came to me from Greg Maxwell; Peter Todd called it
     "near blocks" and extolled their virtues 2 years ago...