[Bitcoin-development] Difficulty adjustment / time issues

Gregory Maxwell gmaxwell at gmail.com
Wed Sep 14 20:09:00 UTC 2011


On Wed, Sep 14, 2011 at 3:52 PM, Aidan Thornton <makosoft at gmail.com> wrote:
> Of course, if only a small percentage of mining power adopts this
> scheme, everyone that does so will presumably be harming themselves by
> doing so since they're essentially increasing the odds that the next
> block they mine will become invalid...

Perhaps better thing to do is to also delay the _forwarding_ of these
blocks _and_ blocks that extend them, until extended one more time.

This policy, if adopted by the forwarding nodes (who really shouldn't
care for much other than the overall health of bitcoins) puts miners
at risk if they don't run the augmented extension policy.


Though I generally agree with Luke that we should just fix the root
cause even though it forks the chain. Not for his reasons (I don't
give a crap about the burden on _one_ pool operator— the rest cope
with bitcoind scaling fine without excessive dependance on ntime
rolling),  but simply because not fixing it makes the bitcoin security
model harder to explain and analyze.

"Here is a vulnerability, but its offset by this workaround" is
inferior to "the system is secure against this kind of attack".




More information about the bitcoin-dev mailing list