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
|
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 CA2B217E6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 13:43:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com
[209.85.215.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C96C21A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 13:43:44 +0000 (UTC)
Received: by laclj5 with SMTP id lj5so66579809lac.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 06:43:42 -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=AOAIPwMm4vXnM2jrvxU1QAZQN0rPQ4AW1HzjoVJPsjM=;
b=IQLASUv/oYQCUITagRITpbe5DZZe9f5fQHzV6Btzuak3mO+NCAePB/li871RTP7ym7
GgFL5lLITGN+s4BlVd/0J6hHN1RdZragVI3HDzxBU4A7Q91f6x7calRPoh56a0aOYvnc
rS0JwjVwbxHTAtvLwOgUZuYrPDTA20+HYXCsvtK8USg6tzngJf7EJTJDyVs3jc7h6JGq
Kc+10qd9hT7GsENDQ2XfPWax2SBVXQrOSsSbgBEOqAs6Br5jQ8NcEi8F0oioTOvxzXVM
FoUiJ9lmcBXQ8qt1cr6AbF3ra4wYFWiIm2HnEtZrulBmMX0cosZ7U08MOl0cmD7VQHfe
TDHg==
MIME-Version: 1.0
X-Received: by 10.152.23.170 with SMTP id n10mr3702595laf.32.1443447822405;
Mon, 28 Sep 2015 06:43:42 -0700 (PDT)
Received: by 10.25.200.214 with HTTP; Mon, 28 Sep 2015 06:43:42 -0700 (PDT)
In-Reply-To: <20150928132814.GB4829@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CABsx9T0XW_jGYhNw6t29AZXz1TxjuHjfEvsbdF5Ji7LUkFo4Ow@mail.gmail.com>
<20150928132814.GB4829@savin.petertodd.org>
Date: Mon, 28 Sep 2015 09:43:42 -0400
Message-ID: <CABsx9T1qUcdFjvJfM-hOHh5pUeoA76uW2qOC6kRiM-+Qrfop7w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0158c94cb4db390520cee2fe
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:43:44 -0000
--089e0158c94cb4db390520cee2fe
Content-Type: text/plain; charset=UTF-8
On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd <pete@petertodd.org> wrote:
> > 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?
>
> Do you have such a document for your BIP101? That would save me a lot of
> time, and the need for that kind of document is significantly higher
> with BIP101 anyway.
>
Hmmm? When I asked YOU for that kind of security analysis document, you
said you'd see if any of your clients would be willing to let you publish
one you'd done in the past. Then I never heard back from you.
So, no, I don't have one for BIP 101, but unless you were lying and just
trying to add Yet Another Hoop for BIP 101 to jump through, you should
already have something to start from.
RE: mempool only: yes, pull-req 5000 satisfies (and that's what I was
thinking of). There should be a nice, readable blog post explaining to
other full node implementors and wallet implementors why that was done for
Core and what they should do to follow 'best practices to be soft-fork
ready.'
--
--
Gavin Andresen
--089e0158c94cb4db390520cee2fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Sep 28, 2015 at 9:28 AM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">> 2) Mr. Tod=
d (or somebody) needs to write up a risk/benefit security<br>
> tradeoff analysis doo-hickey document and publish it. I'm reasonab=
ly<br>
> confident that the risks to SPV nodes can be mitigated (e.g. by deploy=
ing<br>
> mempool-only first, before the soft fork rolls out), but as somebody w=
ho<br>
> has only been moderately paying attention, BETTER COMMUNICATION is nee=
ded.<br>
> What should SPV wallet authors be doing right now, if anything? Once t=
he<br>
> soft fork starts to roll out or activates, what do miners need to be a=
ware<br>
> of? SPV wallet authors?<br>
<br>
</span>Do you have such a document for your BIP101? That would save me a lo=
t of<br>
time, and the need for that kind of document is significantly higher<br>
with BIP101 anyway.<br></blockquote></div><div class=3D"gmail_extra"><br></=
div>Hmmm?=C2=A0 When I asked YOU for that kind of security analysis documen=
t, you said you'd see if any of your clients would be willing to let yo=
u publish one you'd done in the past. Then I never heard back from you.=
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So, n=
o, I don't have one for BIP 101, but unless you were lying and just try=
ing to add Yet Another Hoop for BIP 101 to jump through, you should already=
have something to start from.<br><br>RE: mempool only: yes, pull-req 5000 =
satisfies (and that's what I was thinking of). There should be a nice, =
readable blog post explaining to other full node implementors and wallet im=
plementors why that was done for Core and what they should do to follow =
9;best practices to be soft-fork ready.'<div><br></div>-- <br><div clas=
s=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--089e0158c94cb4db390520cee2fe--
|
