On Wed, Sep 14, 2011 at 3:52 PM, Aidan Thornton <makos...@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". ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
