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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8298B14A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 13:01:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com
[209.85.215.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC53D1F3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 13:01:04 +0000 (UTC)
Received: by laer8 with SMTP id r8so29952700lae.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 06:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=2qGP0O6y8vnsfLXUBOcizevOTFmO4AkYlaBcejZOv+A=;
b=pt1MPorCyMMSetR673ovdTVS7IhcXGMx9piSnmj0ZkVqBhSJbiKDL3yL8dVJJ0g4QJ
hIggj/db6N4RtIPSQL/lT5dW7bwriKTyXXw2yOlluOpeSfHIulx2qMwnaoAK3jeGERv1
reWXYQ/Qi4DyTb25NLeGQOqeYGGMa6dlMrmPCvlHC+uPZv0obaKVm9xEyP1LihhKBVGg
6Hr6KhfUSxXQE6DD2IecwDmRGFlTc1mxFTTDsy8NzWvhUzjhe+u4p7vgXcKoBA+Aw+co
tSRqNP33wFAWaAi+4U17zQqJv1yBDU44nPbB4WErwtTAetr9BuhFdSpxz7rphOT+KC7w
V3pA==
MIME-Version: 1.0
X-Received: by 10.152.45.41 with SMTP id j9mr3686383lam.4.1443445262911; Mon,
28 Sep 2015 06:01:02 -0700 (PDT)
Received: by 10.25.200.214 with HTTP; Mon, 28 Sep 2015 06:01:02 -0700 (PDT)
In-Reply-To: <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
Date: Mon, 28 Sep 2015 09:01:02 -0400
Message-ID: <CABsx9T0XW_jGYhNw6t29AZXz1TxjuHjfEvsbdF5Ji7LUkFo4Ow@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a11c29bca2610da0520ce4aa1
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 13:01:05 -0000
--001a11c29bca2610da0520ce4aa1
Content-Type: text/plain; charset=UTF-8
I think three things need to happen:
1) Stop pretending that "everyone must agree to make consensus rule
changes." "Rough consensus" is what we've always gone with, and is good
enough.
2) Mr. Todd (or somebody) needs to write up a risk/benefit security
tradeoff analysis doo-hickey document and publish it. I'm reasonably
confident that the risks to SPV nodes can be mitigated (e.g. by deploying
mempool-only first, before the soft fork rolls out), but as somebody who
has only been moderately paying attention, BETTER COMMUNICATION is needed.
What should SPV wallet authors be doing right now, if anything? Once the
soft fork starts to roll out or activates, what do miners need to be aware
of? SPV wallet authors?
3) I agree CLTV is ready to roll out, that there is rough consensus a soft
fork is a reasonable way to do it, and that it should happen ASAP.
On Mon, Sep 28, 2015 at 6:48 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is *no* consensus on using a soft fork to deploy this feature. It
> will result in the same problems as all the other soft forks - SPV wallets
> will become less reliable during the rollout period. I am against that, as
> it's entirely avoidable.
>
> Make it a hard fork and my objection will be dropped.
>
> Until then, as there is no consensus, you need to do one of two things:
>
> 1) Drop the "everyone must agree to make changes" idea that people here
> like to peddle, and do it loudly, so everyone in the community is correctly
> informed
>
> 2) Do nothing
>
>
--
--
Gavin Andresen
--001a11c29bca2610da0520ce4aa1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think three things need to happen:<div><br></div><div>1)=
Stop pretending that "everyone must agree to make consensus rule chan=
ges." "Rough consensus" is what we've always gone with, =
and is good enough.</div><div><br></div><div>2) Mr. Todd (or somebody) need=
s to write up a risk/benefit security tradeoff analysis doo-hickey document=
and publish it. I'm reasonably confident that the risks to SPV nodes c=
an be mitigated (e.g. by deploying mempool-only first, before the soft fork=
rolls out), but as somebody who has only been moderately paying attention,=
BETTER COMMUNICATION is needed. What should SPV wallet authors be doing ri=
ght now, if anything? Once the soft fork starts to roll out or activates, w=
hat do miners need to be aware of? SPV wallet authors?</div><div><br></div>=
<div>3) I agree CLTV is ready to roll out, that there is rough consensus a =
soft fork is a reasonable way to do it, and that it should happen ASAP.</di=
v><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Se=
p 28, 2015 at 6:48 AM, Mike Hearn via bitcoin-dev <span dir=3D"ltr"><<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">There is <b>no<=
/b> consensus on using a soft fork to deploy this feature. It will result i=
n the same problems as all the other soft forks - SPV wallets will become l=
ess reliable during the rollout period. I am against that, as it's enti=
rely avoidable.</div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">Make it a hard fork and my objection will be dropped.</div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Until then, as th=
ere is no consensus, you need to do one of two things:</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">1) Drop the "everyone=
must agree to make changes" idea that people here like to peddle, and=
do it loudly, so everyone in the community is correctly informed</div><div=
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) Do nothing</=
div><div class=3D"gmail_extra"><br></div></div></blockquote></div><div><br>=
</div>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div></div>
--001a11c29bca2610da0520ce4aa1--
|
