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
|
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 EF5D1B12
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 15:59:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com
[209.85.215.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4254317A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 15:59:23 +0000 (UTC)
Received: by mail-lf0-f41.google.com with SMTP id i124so10005336lfe.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 08 Jan 2016 07:59:23 -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
:content-type; bh=A8L55NaunIsTWrQKjW72EX7PH985jOGwsfxrwmJgL78=;
b=WfIAVW2DHlrrAA1HJfUS3QFiueHUMUbZihIfAaiN8IBytldfVGCuFhJMCeglRCZgds
t+fW8aigrNPEJkeJhOJPxfi2aMCiU1SzhXzY0jEAqhp2PzdXYVvvFxHeHKFwX9gg5rVQ
f7amHm+NPpgGaULf+zXcP9br8rHWtIrMZ4T5aHaoi2GeczSv+f/IymVLPdYVW+tWe62p
57hoTETzHGCUc/Wtctnges3UqvZ3/SQTbTKT9Yk2bMjAgVPJw2EbwF5eTHYcmscR0ISC
IQfnltB1Bmmtz5ENnNFairzFmt0V3qAcABsHTaK3woChDo8eFfTNAfKNX598BGowyo8k
z0Ew==
MIME-Version: 1.0
X-Received: by 10.25.213.134 with SMTP id m128mr37286860lfg.87.1452268761795;
Fri, 08 Jan 2016 07:59:21 -0800 (PST)
Received: by 10.25.25.78 with HTTP; Fri, 8 Jan 2016 07:59:21 -0800 (PST)
In-Reply-To: <CABsx9T0WRXz54LZnyU7Fr=_ZgwF5armj0Z8uwYcFy2x+BWooxg@mail.gmail.com>
References: <CABsx9T3aTme2EQATamGGzeqNqJkUcPGa=0LVidJSRYNznM-myQ@mail.gmail.com>
<CAPg+sBhH0MODjjp8Avx+Fy_UGqzMjUq_jn3vT3oH=u3711tsSA@mail.gmail.com>
<8760z4rbng.fsf@rustcorp.com.au>
<C4B5B9F1-9C53-45BC-9B30-F572C78096E3@mattcorallo.com>
<8737u8qnye.fsf@rustcorp.com.au>
<CABsx9T1gmz=sr_sEEuy8BQU6SXdmi58O30rzRWNW=0Ej98fi4A@mail.gmail.com>
<20160108153329.GA15731@sapphire.erisian.com.au>
<CABsx9T3MfndREm9icE-TUF58zsRZ5YsBMvUAMy4E-MmYWxWV=A@mail.gmail.com>
<CABsx9T0WRXz54LZnyU7Fr=_ZgwF5armj0Z8uwYcFy2x+BWooxg@mail.gmail.com>
Date: Fri, 8 Jan 2016 10:59:21 -0500
Message-ID: <CABsx9T34htMaC-uoE0Tk3tb1KEct7hk=s=eyY-94+CLCcN2_EQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11420fbaaa59250528d4ab0f
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 17:40:50 +0000
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 15:59:24 -0000
--001a11420fbaaa59250528d4ab0f
Content-Type: text/plain; charset=UTF-8
On Fri, Jan 8, 2016 at 10:50 AM, Gavin Andresen <gavinandresen@gmail.com>
wrote:
> But as I said earlier in the thread, there is a tradeoff here between
> crypto strength and code complexity, and "the strength of the crypto is all
> that matters" is NOT security first.
I should be more explicit about code complexity:
The big picture is "segwitness will help scale in the very short term."
So the spec gives two ways of stuffing the segwitness hash into the
scriptPubKey -- one way that uses a 32-bit hash, but if used would actually
make scalability a bit worse as coins moved into segwitness-locked
transactions (DUP HASH160 EQUALVERIFY pay-to-script-hash scriptpubkeys are
just 24 bytes).
And another way that add just one byte to the scriptpubkey.
THAT is the code complexity I'm talking about. Better to always move the
script into the witness data, in my opinion, on the keep the design as
simple as possible principle.
It could be a 32-byte hash... but then the short-term scalability goal is
compromised.
Maybe I'm being dense, but I still think it is a no-brainer....
--
--
Gavin Andresen
--001a11420fbaaa59250528d4ab0f
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 F=
ri, Jan 8, 2016 at 10:50 AM, Gavin Andresen <span dir=3D"ltr"><<a href=
=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But as I said ea=
rlier in the thread, there is a tradeoff here between crypto strength and c=
ode complexity, and "the strength of the crypto is all that matters&qu=
ot; is NOT security first.</blockquote></div><br>I should be more explicit =
about code complexity:</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">The big picture is "segwitness will help scale in the=
very short term."</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">So the spec gives two ways of stuffing the segwitness has=
h into the scriptPubKey -- one way that uses a 32-bit hash, but if used wou=
ld actually make scalability a bit worse as coins moved into segwitness-loc=
ked transactions (DUP HASH160 EQUALVERIFY pay-to-script-hash scriptpubkeys =
are just 24 bytes).</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">And another way that add just one byte to the scriptpubkey.</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">THAT is=
the code complexity I'm talking about.=C2=A0 Better to always move the=
script into the witness data, in my opinion, on the keep the design as sim=
ple as possible principle.</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">It could be a 32-byte hash... but then the short-term =
scalability goal is compromised.<br><br>Maybe I'm being dense, but I st=
ill think it is a no-brainer....<br clear=3D"all"><div><br></div>-- <br><di=
v class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--001a11420fbaaa59250528d4ab0f--
|
