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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1UFqOX-0000Ac-PO
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 18:27:21 +0000
Received: from mail-wi0-f182.google.com ([209.85.212.182])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFqOV-0004oD-Pt
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 18:27:21 +0000
Received: by mail-wi0-f182.google.com with SMTP id hi18so1068552wib.15
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 11:27:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-received:x-originating-ip:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=mc8CpQ9vbft6gS1it+w3WF6c9ynxh1FSA7F4XZlBSEA=;
b=Xc7dlJP7QwmmqBgN+g6CLkzLRAjiPcfc7VR6Og82AbUu9vRmtudexWCIKr3Jp9PUxg
JvpFt/E1id23WE4I1RE29rAWH4DC+Lmgsy+cKotGfTj/neFWbjYYwDJcVvUmbAjoiGjJ
PGKfte+uVXJSeny1u8xzP80D64Fix1Jvze4A+9vZGC2UIxSKyM2lQjHKBwEmjDvctv84
LF6oqTrqH8t7aVoDRx8yL0S2CIt7rYDa0joeaSqyAkGWLHYHlzixCoTXCq51cJMhlzQB
vBr/4iH1vKBVn/VaU8lcUMA2sEnNllZfg+udqf6VRASyQfn7zsh/mTqpHftLgBvV8ty5
AAmw==
MIME-Version: 1.0
X-Received: by 10.180.37.146 with SMTP id y18mr8330284wij.10.1363199233246;
Wed, 13 Mar 2013 11:27:13 -0700 (PDT)
Received: by 10.194.30.38 with HTTP; Wed, 13 Mar 2013 11:27:13 -0700 (PDT)
X-Originating-IP: [128.102.238.116]
In-Reply-To: <20130313175825.GA21242@vps7135.xlshosting.net>
References: <201303131256.30144.luke@dashjr.org>
<CACh7GpE09hqCPL6rtdC6EZzohM5QHb+0SdFoD8MzPSqf7=6hOA@mail.gmail.com>
<20130313175825.GA21242@vps7135.xlshosting.net>
Date: Wed, 13 Mar 2013 11:27:13 -0700
Message-ID: <CACh7GpG_4uLUUiwJyZO0FtV2_UHMN-HnJsZZXWpC2jQvzb-jMQ@mail.gmail.com>
From: Mark Friedenbach <mark@monetize.io>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f64663f0e598204d7d28eea
X-Gm-Message-State: ALoCoQmwR8NAGAa45VgeSQa3z+ms8wv79UApbCJEszcab2QIEzZMDsVzCxYVUlinVI5N8E7ePWGq
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1UFqOV-0004oD-Pt
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0.8.1 ideas
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, 13 Mar 2013 18:27:21 -0000
--e89a8f64663f0e598204d7d28eea
Content-Type: text/plain; charset=UTF-8
This may be a semantic issue. I meant that it's not a hard-fork of the
bitcoin protocol, which I'm taking to mean the way in which we all
*expected* every version of the Satoshi client to behave: the rules which
we have documented informally on the wiki, this mailing list, and in code
comments, etc. I'm just trying to prevent protocol-creep.
Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules
which all verifying implementations must adhere to. I'm suggesting that we
instead change the old codebase to do what we expected it to do all along
(what 0.8 does and what every other verifying implementation does), and
through miner collusion buy ourselves enough time for people to update
their own installations.
I know there's people here who will jump in saying that the bitcoin
protocol is the behavior of the Satoshi client, period. But which Satoshi
client? 0.7 or 0.8? How do you resolve that without being arbitrary? And
regardless, we are moving very quickly towards a multi-client future. This
problem is very clearly a *bug* in the old codebase. So let's be forward
thinking and do what we would do in any other situation: fix the bug,
responsibly notify people and give them time to react, then move on. Let's
not codify the bug in the protocol.
Mark
On Wed, Mar 13, 2013 at 10:58 AM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> On Wed, Mar 13, 2013 at 10:41:29AM -0700, Mark Friedenbach wrote:
> > 4) At some point in the future once we've crossed an acceptable adoption
> > threshold, the miners remove the above patch in a coordinated way.
> >
> > Does that not get us past this crisis without a hard-fork?
>
> This is a hardfork: it means some nodes will have to accept blocks they
> formerly considered invalid.
>
> --
> Pieter
>
--e89a8f64663f0e598204d7d28eea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This may be a semantic issue. I meant that it's n=
ot a hard-fork of the bitcoin protocol, which I'm taking to mean the wa=
y in which we all *expected* every version of the Satoshi client to behave:=
the rules which we have documented informally on the wiki, this mailing li=
st, and in code comments, etc. I'm just trying to prevent protocol-cree=
p.<br>
<br>Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules =
which all verifying implementations must adhere to. I'm suggesting that=
we instead change the old codebase to do what we expected it to do all alo=
ng (what 0.8 does and what every other verifying implementation does), and =
through miner collusion buy ourselves enough time for people to update thei=
r own installations.<br>
<br>I know there's people here who will jump in saying that the bitcoin=
protocol is the behavior of the Satoshi client, period. But which Satoshi =
client? 0.7 or 0.8? How do you resolve that without being arbitrary? And re=
gardless, we are moving very quickly towards a multi-client future. This pr=
oblem is very clearly a *bug* in the old codebase. So let's be forward =
thinking and do what we would do in any other situation: fix the bug, respo=
nsibly notify people and give them time to react, then move on. Let's n=
ot codify the bug in the protocol.<br>
<br></div>Mark<br><div><br></div></div><div class=3D"gmail_extra"><br><br><=
div class=3D"gmail_quote">On Wed, Mar 13, 2013 at 10:58 AM, Pieter Wuille <=
span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_=
blank">pieter.wuille@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, Mar 13, 2013 at 10=
:41:29AM -0700, Mark Friedenbach wrote:<br>
> 4) At some point in the future once we've crossed an acceptable ad=
option<br>
> threshold, the miners remove the above patch in a coordinated way.<br>
><br>
> Does that not get us past this crisis without a hard-fork?<br>
<br>
</div>This is a hardfork: it means some nodes will have to accept blocks th=
ey formerly considered invalid.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Pieter<br>
</font></span></blockquote></div><br></div>
--e89a8f64663f0e598204d7d28eea--
|
