Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-14 🗒️ Summary of this message: Delay ...
đź“… Original date posted:2011-09-14
🗒️ Summary of this message: Delay forwarding of blocks and extensions to increase Bitcoin's overall health. Miners at risk if they don't adopt this policy. Fix root cause to maintain security.
đź“ť Original message: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".
🗒️ Summary of this message: Delay forwarding of blocks and extensions to increase Bitcoin's overall health. Miners at risk if they don't adopt this policy. Fix root cause to maintain security.
đź“ť Original message: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".