On Wednesday, March 13, 2013 5:41:29 PM you wrote: > I'm not sure I understand the need for hard forks. We can get through this > crisis by mining pool collusion to prevent forking blocks until there is > widespread adoption of patched clients.
Anything requiring widespread adoption of patched clients *is by definition* a hard fork. > Proposal: > > 1) Patch the pre-0.8 branches to support an increased lock count, whatever > number is required to make sure that this problem never shows up again at > the current block size (I defer to Luke-Jr and gmaxwell's numbers on this). This is a hard fork. The only way to avoid a hard fork is to apply the existing lock limit to all clients forever. That would be fine, except that pre-0.8 clients cannot reorg N blocks without dividing that limit by (N * 2) + 1; that leaves us with the limit of around 1000 locks per block on average. Each transaction uses at least 3 locks on average (many times more). So about 300 transactions per block. This is a much smaller limit than the 1 MB we've been assuming is the bottleneck so far, and the need to increase it is much more urgent - as Pieter noted on IRC, we are probably already using more than that even ignoring DP spam. The only reason pre-0.8 clients have survived as well as they have thus far is because the blockchain has managed to avoid very deep reorgs. Luke ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
