summaryrefslogtreecommitdiff
path: root/81/3c7700a7f28e3e8ba1921a8837c9c9da3773db
blob: 03e933ae12be230c7ce0d17e57dee817e6137f66 (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
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
155
156
157
158
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 26134DD0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Jan 2016 01:54:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
	[209.85.217.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C015C14C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Jan 2016 01:54:02 +0000 (UTC)
Received: by mail-lb0-f172.google.com with SMTP id oh2so217483913lbb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 07 Jan 2016 17:54:02 -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=u0igcesifE6eqQw6GhnV7TrWsxiAfplR0cjETJffEqQ=;
	b=tl5+Rtp7VLUmwCj3sFlZdhlWgiUjoYDlEOF+DpsMHo6KkYIUXjMVqIgOFU6CKGAG4K
	YFQC0e1k5Ahah7TGrNdWTz0zAmns8cTXphATw8+UILOlWHrer5Mmcwb2mewiGmjz8fLe
	b09YAuk2sbrlzkf4RUHRe1mmip2+F5t3+eSr5w3qJfAl4z17XoHPsRJxjTvC1ehZQO4+
	YZn3jwKyMAJcsf72A4JG4oJFbT/FTE8SU/32XlKZ1exD+AbBw/oKZiSv0D+HOpdE+RqH
	HEggvkX5i/oXyYNbo2EC2M/N48S61DjQb03ECtXS3O5FuXCyBAtELdettcidYx/L4JHC
	S6qA==
MIME-Version: 1.0
X-Received: by 10.112.219.101 with SMTP id pn5mr10768816lbc.123.1452218041056; 
	Thu, 07 Jan 2016 17:54:01 -0800 (PST)
Received: by 10.25.25.78 with HTTP; Thu, 7 Jan 2016 17:54:00 -0800 (PST)
In-Reply-To: <568F103E.1050909@mattcorallo.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>
Date: Thu, 7 Jan 2016 20:54:00 -0500
Message-ID: <CABsx9T2CM2iVBbzBs-jQA6S-sHCdtEEWNwn=DgN_D+biKVErkA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=001a11c3c26c79496d0528c8dc5b
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
X-Mailman-Approved-At: Fri, 08 Jan 2016 02:37:31 +0000
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 01:54:04 -0000

--001a11c3c26c79496d0528c8dc5b
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 7, 2016 at 8:26 PM, Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> So just because other attacks are possible we should weaken the crypto
> we use? You may feel comfortable weakening crypto used to protect a few
> billion dollars of other peoples' money, but I dont.
>

No...

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.

Reference for those who are lost:

https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki#witness-program

My proposal would be to just do a version 0 witness program now, that is
RIPEMD160(SHA256(script)).

And ten or twenty years from now, if there is a plausible attack on
RIPEMD160 and/or SHA256, revisit and do a version 11 (or whatever).

It will simplify the BIP, means half as many test cases have to be written,
means a little more scalability, and is as secure as the P2SH and P2PKH
everybody is using to secure their bitcoin today.

Tell you what:  I'll change my mind if anybody can describe a plausible
attack if we were using MD5(SHA256), given what we know about how MD5 is
broken.


---

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."

-- 
--
Gavin Andresen

--001a11c3c26c79496d0528c8dc5b
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 T=
hu, Jan 7, 2016 at 8:26 PM, Matt Corallo <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:lf-lists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><div id=3D":2il" class=3D"" style=
=3D"overflow:hidden">So just because other attacks are possible we should w=
eaken the crypto<br>
we use? You may feel comfortable weakening crypto used to protect a few<br>
billion dollars of other peoples&#39; money, but I dont.<br></div></blockqu=
ote></div><br></div><div class=3D"gmail_extra">No...</div><div class=3D"gma=
il_extra"><br></div><div class=3D"gmail_extra">I&#39;m saying we can elimin=
ate one somewhat unlikely attack (that there is a bug in the code or test c=
ases, today or some future version, that has to decide what to do with &quo=
t;version 0&quot; versus &quot;version 1&quot; witness programs) by accepti=
ng the risk of another insanely, extremely unlikely attack.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Reference for those w=
ho are lost:</div><div class=3D"gmail_extra">=C2=A0=C2=A0<a href=3D"https:/=
/github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawik=
i#witness-program">https://github.com/CodeShark/bips/blob/segwit/bip-codesh=
ark-jl2012-segwit.mediawiki#witness-program</a></div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">My proposal would be to just do a=
 version 0 witness program now, that is RIPEMD160(SHA256(script)).</div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">And ten or twe=
nty years from now, if there is a plausible attack on RIPEMD160 and/or SHA2=
56, revisit and do a version 11 (or whatever).</div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">It will simplify the BIP, means ha=
lf as many test cases have to be written, means a little more scalability, =
and is as secure as the P2SH and P2PKH everybody is using to secure their b=
itcoin today.</div><div class=3D"gmail_extra"><div><br></div><div>Tell you =
what: =C2=A0I&#39;ll change my mind if anybody can describe a plausible att=
ack if we were using MD5(SHA256), given what we know about how MD5 is broke=
n.</div><div><br></div><div><br></div><div>---</div><div><br></div><div>I&#=
39;m really disappointed with the &quot;Here&#39;s the spec, take it or lea=
ve it&quot; attitude. What&#39;s the point of having a BIP process if the d=
iscussion just comes down to &quot;We think more is better. We don&#39;t ca=
re what you think.&quot;</div><div><br></div>-- <br><div class=3D"gmail_sig=
nature">--<br>Gavin Andresen<br></div><div class=3D"gmail_signature"><br></=
div>
</div></div>

--001a11c3c26c79496d0528c8dc5b--