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
153
154
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B7A28EE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 17:38:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6DF813D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 17:38:36 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id f206so182332455wmf.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 08 Jan 2016 09:38:36 -0800 (PST)
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=WRoFz3lyilqXb2nWzDj814BFZrnctuazmPGO7yx3KUU=;
b=drfVK8CJ5rQ5Ij1PY/o41lCDIaxKL6qsdyGF15QHJq/8Qs8wlZcSih7Yep34H8kOhU
WuJh5PcC1cBLt0O7ZMCNDxNjvY6ybZf+6hHPTRPPuGHxiDja2ISdBMGtHeYqbHDZ32OT
zk/yYkNSrRIZ8Y4HbOhz68aYRGTGIV8bs+s2xL1l98aGKxcHlqaUrYsi+oi52HryMN2i
QTicW1v7LjFZ4uIt8ea/cAOJ86swmPjgtplQX9zhQ9E89cyfYLbkYnAibn86YvOk9dOs
ox1V6FxSsken1lcFUI2v23ZKYVtbHdex+mor0CgNsnBEC+DPcFlz8kRi4MvhPa3Yyw3I
hyrg==
MIME-Version: 1.0
X-Received: by 10.194.243.227 with SMTP id xb3mr129472035wjc.96.1452274715556;
Fri, 08 Jan 2016 09:38:35 -0800 (PST)
Received: by 10.194.104.135 with HTTP; Fri, 8 Jan 2016 09:38:34 -0800 (PST)
Received: by 10.194.104.135 with HTTP; Fri, 8 Jan 2016 09:38:34 -0800 (PST)
In-Reply-To: <CABsx9T2CM2iVBbzBs-jQA6S-sHCdtEEWNwn=DgN_D+biKVErkA@mail.gmail.com>
References: <CABsx9T3aTme2EQATamGGzeqNqJkUcPGa=0LVidJSRYNznM-myQ@mail.gmail.com>
<CALqxMTHjvFT2aCBYDEiG-6F5qvsXK57_LR6ttpPb3xUG2i443w@mail.gmail.com>
<CAGLBAhczEceqDp6XPSVLJ0FuTcmZgYkVnUE4rspb3JdeHnZJUg@mail.gmail.com>
<CABsx9T0JX41bOQxjPg7QFUKGEwgFaCGFzR3ySbaqFwy4i28Hbg@mail.gmail.com>
<CAEM=y+VAmT5wRsDhUufPCDPB=U+h-MQ1+xY5uJqAAO8Xt6SaxA@mail.gmail.com>
<CABsx9T2+Q9+4mNUH3OnbnfFSn6NJ3LRCObTtU8WQqupEvhi_hA@mail.gmail.com>
<568F103E.1050909@mattcorallo.com>
<CABsx9T2CM2iVBbzBs-jQA6S-sHCdtEEWNwn=DgN_D+biKVErkA@mail.gmail.com>
Date: Fri, 8 Jan 2016 18:38:34 +0100
Message-ID: <CAPg+sBiOPpJb8kPYqMSZdGvN7Tb96sgyw_h4yPdhbsLWNcVFRQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e0141a1628985770528d60e8c
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] Time to worry about 80-bit collision attacks or
not?
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: Fri, 08 Jan 2016 17:38:37 -0000
--089e0141a1628985770528d60e8c
Content-Type: text/plain; charset=UTF-8
On Fri, Jan 8, 2016 at 2:54 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm saying we can eliminate one somewhat unlikely attack (that there is a
> bug in the code or test cases, today or some future version, that has to
> decide what to do with "version 0" versus "version 1" witness programs) by
> accepting the risk of another insanely, extremely unlikely attack.
Ok, just having one witness program version now is a somewhat different
proposal. It would be simpler for sure. The reasoning was that you'd need
this to not add significant overhead to small scripts, but that may not be
the case anymore. I wouldn't mind seeing numbers.
> My proposal would be to just do a version 0 witness program now, that is
> RIPEMD160(SHA256(script)).
I don't think that is wise. Bitcoin has a 128-bit security target for
everything else. We did not know that P2SH and similar constructs were
vulnerable to a collision attack at the time, but now we do, so the obvious
choice is to pick a size that is sufficiently large to maintain the 128-bit
security target. This is a no brainer to me; we're not proposing switching
to a 160-bit EC curve either, right?
> I'm really disappointed with the "Here's the spec, take it or leave it"
> attitude. What's the point of having a BIP process if the discussion just
> comes down to "We think more is better. We don't care what you think."
It is a proposal and we are discussing it. You first brought up some
criticisms in private, and I agreed with several things you said.
But it remains the proposal of a few people including me, and I do not
agree with the specific suggestion of reducing the security target for
witness scripts to 80 bits.
We are not deciding what the system will be. We're making a proposal, and
hope that due to its technical merit, the ecosystem will adopt it. You're
free to participate in that discussion.
--
Pieter
--089e0141a1628985770528d60e8c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Fri, Jan 8, 2016 at 2:54 AM, Gavin Andresen via bitcoin-d=
ev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>> wrote:<br>
> I'm saying we can eliminate one somewhat unlikely attack (that the=
re is a<br>
> bug in the code or test cases, today or some future version, that has =
to<br>
> decide what to do with "version 0" versus "version 1&qu=
ot; witness programs) by<br>
> accepting the risk of another insanely, extremely unlikely attack.</p>
<p dir=3D"ltr">Ok, just having one witness program version now is a somewha=
t different proposal. It would be simpler for sure. The reasoning was that =
you'd need this to not add significant overhead to small scripts, but t=
hat may not be the case anymore. I wouldn't mind seeing numbers.</p>
<p dir=3D"ltr">> My proposal would be to just do a version 0 witness pro=
gram now, that is<br>
> RIPEMD160(SHA256(script)).</p>
<p dir=3D"ltr">I don't think that is wise. Bitcoin has a 128-bit securi=
ty target for everything else. We did not know that P2SH and similar constr=
ucts were vulnerable to a collision attack at the time, but now we do, so t=
he obvious choice is to pick a size that is sufficiently large to maintain =
the 128-bit security target. This is a no brainer to me; we're not prop=
osing switching to a 160-bit EC curve either, right?</p>
<p dir=3D"ltr">> I'm really disappointed with the "Here's t=
he spec, take it or leave it"<br>
> attitude. What's the point of having a BIP process if the discussi=
on just<br>
> comes down to "We think more is better. We don't care what yo=
u think."</p>
<p dir=3D"ltr">It is a proposal and we are discussing it. You first brought=
up some criticisms in private, and I agreed with several things you said. =
</p>
<p dir=3D"ltr">But it remains the proposal of a few people including me, an=
d I do not agree with the specific suggestion of reducing the security targ=
et for witness scripts to 80 bits.</p>
<p dir=3D"ltr">We are not deciding what the system will be. We're makin=
g a proposal, and hope that due to its technical merit, the ecosystem will =
adopt it. You're free to participate in that discussion.</p>
<p dir=3D"ltr">-- <br>
Pieter</p>
--089e0141a1628985770528d60e8c--
|
