From: Christian Decker <decker.christian@gmail•com>
To: Martin Sustrik <sustrik@250bpm•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
Date: Thu, 24 Oct 2013 13:11:05 +0200 [thread overview]
Message-ID: <CALxbBHVEdTmo1VWL5zj2ZBV6c-Td4TfpbQSQOWuLGbpxHSDRdA@mail.gmail.com> (raw)
In-Reply-To: <5268C632.3030005@250bpm.com>
I'd like to add some historical background about how the "protocol
specification" came to be in the first place.
A bit over three years [1] ago I started an attempt to document the
network protocol, by reverse engineering it from the satoshi
client. My goal, back then, was to enable like-minded engineers to
create alternative clients and move away from the client-monoculture
that is still predominant today. It was clear from the beginning that
it would merely be a reverse engineering effort, and that it would
likely lag a bit behind the changes in the main client. It was meant
as a help for engineers that are not well versed in C/C++ to enable
them to contribute by creating new clients, but the satoshi client
would always be the de-facto standard.
With the move from Google Code to the Bitcoin.it wiki somehow this
notion of it being a reverse engineering effort was lost and people
started assuming that if the behavior of the satoshi client did not
match the protocol description it was a bug on the client
side. Instead it is because the reverse engineering of the protocol is
incorrect or simply missing some details. Although the protocol
description is far more complete than it was back when we started, I
still don't feel comfortable giving it the name specification.
I still believe that a client monoculture is bad for the system as a
whole, because a single bug might bring down the whole network. Giving
people the necessary tools to implement new clients brings
stability. I do understand the criticism that writing a specification
might hinder future development as it restricts the possible changes
to the protocol, but isn't this already the case as long as we have
legacy versions of the client participating in the network? I would
also argue that having a specification allows an application
independent review of the protocol to identify possible improvements
and bugs.
I think the protocol description has an important place in the
development of Bitcoin, so much so that we pushed a long time ago to
separate protocol version from the client version. I would love to see
the protocol specification becoming official part of the bitcoin
github repository, which would ideally be maintained alongside the
satoshi client to keep it up to date.
Regards,
Christian Decker
[1] https://bitcointalk.org/index.php?topic=231
--
Christian Decker
On Thu, Oct 24, 2013 at 9:03 AM, Martin Sustrik <sustrik@250bpm•com> wrote:
> On 23/10/13 23:07, Pieter Wuille wrote:
>
>> In short,
>> consistency is more important than correctness.
>
> That's a nice and concise way to put it and any potential protocol
> documentation should start with a statement like that.
>
>> 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.
>
> One interesting question is whather alternative implementations are more
> likely to get it wrong because the protocol description is wrong or
> because the authors misunderstood the reference implementation source code.
>
> Extensive documentation of the source code, a la Knuth's literate
> programming, may be some kind of a middle ground.
>
>> 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.
>
> Ok. Several people expressed an interest in the topic, so I'll give it a
> try and see how it fares.
>
> Martin
>
>
> ------------------------------------------------------------------------------
> 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
next prev parent reply other threads:[~2013-10-24 11:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 14:30 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
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 [this message]
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=CALxbBHVEdTmo1VWL5zj2ZBV6c-Td4TfpbQSQOWuLGbpxHSDRdA@mail.gmail.com \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=sustrik@250bpm$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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