public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
Date: Wed, 23 Oct 2013 16:42:14 -0500	[thread overview]
Message-ID: <CAJfRnm4wJzk885rzV7Gn_9AF10M8O=3GV06MN2oag64YpmMUJA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjv5We415atZocrZniKexFnKmUXB+bMC-tSG4ehQK9rwQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]

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@gmail.com>wrote:

> On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd <pete@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.
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 5113 bytes --]

  reply	other threads:[~2013-10-23 21:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 14:30 [Bitcoin-development] Revisiting the BIPS process, a proposal Jeff Garzik
2013-10-21 14:34 ` Jeff Garzik
2013-10-21 15:46   ` Andreas Schildbach
2013-10-21 16:14     ` Jeff Garzik
2013-10-21 17:17 ` Jeff Garzik
2013-10-21 19:38   ` Jean-Paul Kogelman
2013-10-21 19:47     ` Luke-Jr
2013-10-21 20:57       ` Benjamin Cordes
2013-10-21 20:59       ` Benjamin Cordes
2013-10-22  6:39       ` Martin Sustrik
2013-10-22  6:59         ` Jean-Paul Kogelman
2013-10-22  7:03           ` Gregory Maxwell
2013-10-22  7:34             ` Martin Sustrik
2013-10-22  7:49               ` Peter Todd
2013-10-22  7:56               ` Gregory Maxwell
2013-10-22  8:20                 ` Martin Sustrik
2013-10-22 14:08               ` Jeff Garzik
2013-10-23  7:38                 ` Martin Sustrik
2013-10-23 19:40                   ` Peter Todd
2013-10-23 20:05                     ` Martin Sustrik
2013-10-23 20:27                       ` Peter Todd
2013-10-23 21:07                         ` Pieter Wuille
2013-10-23 21:42                           ` Allen Piscitello [this message]
2013-10-23 21:49                             ` Luke-Jr
2013-10-24  7:03                           ` Martin Sustrik
2013-10-24 10:39                             ` Jeff Garzik
2013-10-24 11:11                             ` Christian Decker
2013-10-24 19:43                               ` Jeremy Spilman
2013-11-19 16:32 ` Wladimir
2013-11-19 16:53   ` Drak
2013-11-19 17:01     ` Gregory Maxwell
2013-11-19 17:07       ` Drak
2013-11-19 17:45       ` Wladimir
2013-11-19 17:54         ` Gregory Maxwell
2013-11-19 17:06   ` Peter Todd
     [not found]     ` <CA+s+GJA=p+yvoJqUAMQQRcfYK1B8eMVSJDWaXW8o+X5dzCXkdA@mail.gmail.com>
2013-11-19 17:21       ` [Bitcoin-development] Fwd: " Wladimir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJfRnm4wJzk885rzV7Gn_9AF10M8O=3GV06MN2oag64YpmMUJA@mail.gmail.com' \
    --to=allen.piscitello@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox