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
|
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 E583440A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 20:30:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com
[209.85.217.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 273D9155
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 20:30:10 +0000 (UTC)
Received: by lbbqi7 with SMTP id qi7so22030862lbb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 13:30:08 -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=MaY7nfONJVagy31ZyQ5LQVZz5UGzZEzPPJkT12Q8hNc=;
b=ItnpzBUtQsPaaGndzptlNEZuPjzC8KLnG1oxIWjwzBIfn5TnoboAyEdWMMsdhj0o/3
fn2wTtJPk45vJu78/GDlansKBwC1beYSAtMMNXnoJMrd6VOgh76iU/vULajIiLluIfZI
D9UdxOsYWEaVQTdZtrdnVd4FPgoS9F/6t2bX2aBIt+gTfxhxybzqEONImzUh2auFXpFP
uZCMr1P60kGM/KJtCcHL7wTlL5AUbTF71yzUpPphKvITBisjn5n6TLUa96h77+CqturN
oEzj7CE0EocUbsTuvePRZ5i5BmmynRSGcwAUicT+FokBEoJ93aYElIemcny4tyFRLxpe
yVhw==
MIME-Version: 1.0
X-Received: by 10.112.118.210 with SMTP id ko18mr29210617lbb.75.1437424208405;
Mon, 20 Jul 2015 13:30:08 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Mon, 20 Jul 2015 13:30:08 -0700 (PDT)
In-Reply-To: <CAE-z3OVWYaoGc+_=xQN1=CV=LUHdLEtuds6FZCXdktowfCaLYA@mail.gmail.com>
References: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
<CAE-z3OVWYaoGc+_=xQN1=CV=LUHdLEtuds6FZCXdktowfCaLYA@mail.gmail.com>
Date: Mon, 20 Jul 2015 16:30:08 -0400
Message-ID: <CABsx9T0Y7K62-c4ivcgscU4cuXgQEAehZkupL64zmJTXjOnt0w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bae44a0556b6f051b546796
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] For discussion: limit transaction size to
mitigate CVE-2013-2292
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, 20 Jul 2015 20:30:11 -0000
--047d7bae44a0556b6f051b546796
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This could render transactions with a locktime in the future as
> unspendable.
>
> It is pretty low probability that someone has created a >100kB locked
> transaction though.
>
> It violates the principle that no fork should render someone's coins
> unspendable.
>
Mmmm.... you'd have to:
a) Have lost or thrown away the keys to the unspent transaction outputs
b) Have created a locktime'd transaction with a lock time after the
BIP100/101 switchover times
that is more than 100,000 bytes big
c) Have some special relationship with a miner that you trust to still be
around when the transaction
unlocks that would mine the bigger-than-standard transaction for you.
I don't think adding extra complexity to consensus-critical code to support
such an incredibly unlikely
scenario is the right decision here. I think it is more likely that the
extra complexity would trigger a bug
that causes a loss of bitcoin greater than the amount of bitcoin tied up in
locktime'ed transactions
(because I think there are approximately zero BTC tied up in >100K
locktime'ed transactions).
RE: limit size of transaction+parents: Feature creep, belongs in another
BIP in my opinion. This one
is focused on fixing CVE-2013-2292
--
--
Gavin Andresen
--047d7bae44a0556b6f051b546796
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, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div>This could render transactions with a locktime in the future a=
s unspendable.<br><br></div><div>It is pretty low probability that someone =
has created a >100kB locked transaction though.<br><br></div><div>It vio=
lates the principle that no fork should render someone's coins unspenda=
ble.<br></div></blockquote></div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">Mmmm.... you'd have to:</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">a) Have lost or thrown away the=
keys to the unspent transaction outputs</div><div class=3D"gmail_extra">b)=
Have created a locktime'd transaction with a lock time after the BIP10=
0/101 switchover times</div><div class=3D"gmail_extra">that is more than 10=
0,000 bytes big</div><div class=3D"gmail_extra">c) Have some special relati=
onship with a miner that you trust to still be around when the transaction<=
/div><div class=3D"gmail_extra">unlocks that would mine the bigger-than-sta=
ndard transaction for you.</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">I don't think adding extra complexity to consensus=
-critical code to support such an incredibly unlikely</div><div class=3D"gm=
ail_extra">scenario is the right decision here. I think it is more likely t=
hat the extra complexity would trigger a bug</div><div class=3D"gmail_extra=
">that causes a loss of bitcoin greater than the amount of bitcoin tied up =
in locktime'ed transactions</div><div class=3D"gmail_extra">(because I =
think there are approximately zero BTC tied up in >100K locktime'ed =
transactions).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra">RE: limit size of transaction=
+parents: =C2=A0Feature creep, belongs in another BIP in my opinion. This o=
ne</div><div class=3D"gmail_extra">is focused on fixing CVE-2013-2292</div>=
<div class=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra"><div>=
<br></div>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></d=
iv>
</div></div>
--047d7bae44a0556b6f051b546796--
|
