Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-11-23 🗒️ Summary of this message: A proposal to ...

📅 Original date posted:2011-11-23
🗒️ Summary of this message: A proposal to normalize the block generation rate in Bitcoin by having every node generate the most difficult block it can, without a target difficulty.
📝 Original message:Hello,

One problem with Bitcoin is that if large numbers of miners suddenly switch
off, the network takes a long time to adapt (since the adaption time is a
function of blocks generated, and the block generation rate has changed). The
same problem exists in the other direction, but an increased generation rate
for a little while doesn't really do any harm.

I had this idea as a way of completely normalising the block generation rate,
regardless of network power. I hesitate to offer it, as I get shouted down a
lot, but what the hell...

Let's imagine that the whole network shares a clock (which it does already).
Let's abandon the idea of a target difficulty. Instead, every node just
generates the most difficulty block it can. Simultaneously, every node is
listening for "the most difficult block generated before time T"; with T being
picked to be the block generation rate (10 minutes).

Every node is therefore generating blocks and comparing not against some
moving average determined target, but rather against the most difficult
recently received block. If the generated block is harder than the received
block, then it gets broadcast.

Clearly, early on in the block, the traffic would be high, but that could be
limited with a bit of intelligence -- there's no point broadcasting your best
blocks in minute 0 of the current block... you know everyone will beat it, as
it was so easy. So the rule would be broadcasts only start at T/2 plus a
little randomisation. There wouldn't be that many because someone will have
generated a pretty good block by chance in the first half, and that will
quickly stop anybody else from bothering to broadcast their easier block.
There is no advantage to broadcasting a lesser block, so there is no incentive
to cheat.

As always: the most difficult chain wins; and blocks with out-of-bounds times
are rejected regardless of difficulty. Everyone therefore has an incentive to
base their next block on the block with highest difficulty from the previous
period.

The block period is now guaranteed to be 10 minutes (or in fact, whatever
period you like, there is no danger at all in changing it to 2 minutes); and
there is no change of block generation rate with network power. Changes in
network power merely adjust the average difficulty of the best block per
period. The cost is higher network traffic, because there are block
broadcasts that don't necessarily make it to the end. However, there's no
need to broadcast the full block, only the header. If that block turns out to
be the winner, then the other nodes will request the full block at the end of
the period, and will check it's valid. If it's not then the next highest on
the list will be requested. So again,

I recognise that this is a pretty large change to make; and so don't really
expect it to happen. Perhaps one day though... when all the wishlist items go
into one huge protocol overhaul.



Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/3a6d159f/attachment.sig>;