summaryrefslogtreecommitdiff
path: root/54/d8be48fb071468dc37f2b6f0a3a623b99de15d
blob: f2029d9f4ac71f439e5394d399147a85ab4fedea (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1VZ5eG-0000bv-Tg
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Oct 2013 21:07:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.181 as permitted sender)
	client-ip=209.85.223.181; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ie0-f181.google.com; 
Received: from mail-ie0-f181.google.com ([209.85.223.181])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VZ5eG-00081b-55
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Oct 2013 21:07:24 +0000
Received: by mail-ie0-f181.google.com with SMTP id ar20so2398100iec.12
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Oct 2013 14:07:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.11.69 with SMTP id pd5mr258939icb.62.1382562438682; Wed,
	23 Oct 2013 14:07:18 -0700 (PDT)
Received: by 10.50.141.136 with HTTP; Wed, 23 Oct 2013 14:07:18 -0700 (PDT)
In-Reply-To: <20131023202731.GA31783@petertodd.org>
References: <791a727f-2188-4848-bd77-ea733c8c5c2c@me.com>
	<201310211947.59640.luke@dashjr.org> <52661DB7.7040805@250bpm.com>
	<FAE2A544-9295-4087-96DE-D4602D109CBD@me.com>
	<CAAS2fgS2f=gYRSr1n2DzK7CUH3xG3J2JMnDreCKBoCcJcpGLxg@mail.gmail.com>
	<52662AA1.5050509@250bpm.com>
	<CAJHLa0NDus+Ou5go8b_OHvjYW8f7oxXbpxnHTG3dcvxGR49nxA@mail.gmail.com>
	<52677CF7.9070609@250bpm.com>
	<20131023194039.GB31497@petertodd.org> <52682C24.30700@250bpm.com>
	<20131023202731.GA31783@petertodd.org>
Date: Wed, 23 Oct 2013 23:07:18 +0200
Message-ID: <CAPg+sBjv5We415atZocrZniKexFnKmUXB+bMC-tSG4ehQK9rwQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pieter.wuille[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: petertodd.org]
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VZ5eG-00081b-55
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 21:07:25 -0000

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