On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins <andypark...@gmail.com> wrote: > On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: >> Here's a simple proposal to start discussion from... > > It seems to me that the biggest failure was not the development of two > chains, but the assurance to users (by the client) that their transactions
The development of two chains was maximally bad because the state was irreconcilable without the manual intervention. The only reason you're saying that it was only the false confirms that were bad is because manual intervention resolved the worse badness. :) A whole bunch of people spending coins that can only exist in the different exclusive chains would have been very bad indeed. > Is it possible to change the definition of "6 confirmations" so that it's > something like: "six confirmations clear of any other chain". While there > are two competing chains, it's possible that one will go pop at any moment. > That makes the confirmation count of any transaction on one of those chains, > zero. Not reliably, you will only hear of a competing chain if some of your peers have accepted it. If your peers were all pre-0.8 or all 0.8 you only would have heard of one chain. Relaying non-primary chains has some obvious and subtle challenges— Obviously you need some way of preventing it from being a DOS vector, but thats not a fundamental issue— you could rate limit by only relaying chains which are close to the current best in sum difficulty— just a software engineering one. A more subtle issue is it that it's not in a node's self-interest to tell peers about a chain it thinks is invalid: it wants its peers on _its_ view of the consensus, not some other one. Though perhaps this could be addressed by only relaying headers for non-primary chains. ------------------------------------------------------------------------------ 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
