I think formalizing the specification could go a long way and encouraging alternate implementations is going to be the best way to reduce unexpected small bugs having a bad effect except on the "buggy" node. That being said, it's a huge chicken and egg problem. No one wants to go off the reference client since it could lead to working on a forked chain as a miner or having bad data as a client. I don't know if there is a good way to try to take small pieces, get consensus, possibly have some type of universal test cases and running on testnet that would solve the problem. I wouldn't mind taking on parts of this when I have time, specifically transactions/scripting. Obviously if there are better qualified people who are interested, have at it! On Wed, Oct 23, 2013 at 4:07 PM, Pieter Wuille wrote: > On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd wrote: > > On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote: > >> On 23/10/13 21:40, Peter Todd wrote: > >> > >> >The reference implementation is the specification - the "specification" > >> >on the wiki is best thought of as a set of Coles Notes on the real > >> >specification. If you don't already understand that and the nuance of > >> >that statement you should assume the protocol is fixed in stone and > >> >doesn't evolve at all; that statement is not quite true, but it's very > >> >close to the truth. > >> > >> Does that imply that the notes are deliberately obscured to force > >> everyone to check the source code? > > > > What's on the wiki is mostly the work of people who aren't working on > > the reference implementation, so no, you can't say that. > > Indeed, I know of few people who are familiar with the source code > that use the wiki. > > I do think that is a pity. The openness and transparency of the > protocol is essential to trusting the system (and shouldn't be limited > to those digging through the source code), and for that reason alone I > think it needs to be well-documented. > > I also do agree with earlier comments, that due to the nature of the > consensus problem Bitcoin solves, it will always be the network that > dictates what the actual rules are - anything else can result in > inresolvable forks. If a "formal" specification were written, and we > would find out that the majority of nodes on the network deviate from > it in a subtle way, those nodes would be buggy in the sense that they > aren't doing what was expected, but it would be the specification that > is incorrect for not following the rules of the network. In short, > consistency is more important than correctness, and for that reason, > writing alternate implementation will always be hard and dangerous. > > However, I do not think that making it hard to find information about > the details of the system is the way to go. Alternate implementations > are likely inevitable, and in the long run probably a win for the > ecosystem. If effort is put into accurately describing the rules, it > should indeed carry a strong notice about it being descriptive rather > than normative. > > If someone is willing to work on that, I am (and likely many people in > #bitcoin-dev are) available for any questions about the protocol and > its semantics. > > -- > Pieter > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >