[Bitcoin-development] Revisiting the BIPS process, a proposal
allen.piscitello at gmail.com
Wed Oct 23 21:42:14 UTC 2013
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 <pieter.wuille at gmail.com>wrote:
> On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd <pete at petertodd.org> 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.
> 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
> the latest Intel processors and coprocessors. See abstracts and register >
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev