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
159
160
161
162
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B14281BD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Oct 2015 16:02:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com
[209.85.220.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F6A3170
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Oct 2015 16:02:16 +0000 (UTC)
Received: by pacfv12 with SMTP id fv12so25723214pac.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 07 Oct 2015 09:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:in-reply-to:references:mime-version:content-type
:content-transfer-encoding:subject:from:date:to:cc:message-id;
bh=Tjm32icPMqapIW15TX+VY9CcEe0/HAY+uBP9nngcLc8=;
b=VGWvqlMlp2nQok+UU630OuTUvbNYnJrF1owqL31BP34TWHPaln11mZDNOovPiau10Y
hqz1L6alTqHwX/My+N3kiGP8OAE+xqb3o9KAglTaAdEC6cde35OYd9xhE/oqyznjsDty
Dszsh6j3vZJvbh5QiQ/D8IMg1qEs8FFGpWyW9HGwmT8kxG4FVkKqjiUC5UcYvz/BgFVG
q9GAQhfKAG6mz25ubdLXjnt2CD5/Eo0AOfE85tFfuIg5q8mFXgk3EE7iN1enx9xarcvY
mKJ1zfxvceMz0ic/GnDnVm0L2Y1zw9GGrgc2otIczgyWUzWdy0ppoyuWoyFMSJ/9xaUr
LDtA==
X-Received: by 10.66.121.195 with SMTP id lm3mr1966123pab.84.1444233735787;
Wed, 07 Oct 2015 09:02:15 -0700 (PDT)
Received: from [192.168.1.100] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
cn4sm40223110pbc.94.2015.10.07.09.02.14
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 07 Oct 2015 09:02:14 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <A763EBF7-4FA5-4FE4-9595-01317B264B0A@toom.im>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
<20151007150014.GA21849@navy>
<A763EBF7-4FA5-4FE4-9595-01317B264B0A@toom.im>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----YN5WURKKKCR50AUEBY5UZJ474W6K40"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Wed, 07 Oct 2015 09:02:14 -0700
To: "Jonathan Toomim (Toomim Bros)" <j@toom.im>,
"Jonathan Toomim (Toomim Bros) via bitcoin-dev"
<bitcoin-dev@lists.linuxfoundation.org>, Anthony Towns <aj@erisian.com.au>
Message-ID: <B7359445-2B91-4A12-8222-9730D91572C7@gmail.com>
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] 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: Wed, 07 Oct 2015 16:02:16 -0000
------YN5WURKKKCR50AUEBY5UZJ474W6K40
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
That's why it's important to measure miner adoptance. Note that this isn't a vote - it's an adoption metric for what is presumably a fairly uncontroversial upgrade. If there's contentious controversy amongst miner all bets are off.
Our current mechanisms are imperfect in this regard...as we've seen in the past, miners have deliberately disabled checks despite signaling adoption in their blocks. But a real hashpower supermajority would make such attacks hard to pull off in practice.
- Eric
On October 7, 2015 8:46:08 AM PDT, "Jonathan Toomim (Toomim Bros) via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> *But* a soft fork that only forbids transactions that would
>previously
>> not have been mined anyway should be the best of both worlds, as it
>> automatically reduces the liklihood of old miners building newly
>invalid
>> blocks to a vanishingly small probability; which means that upgraded
>> bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*
>> continuing to work fine during the upgrade.
>
>I agree with pretty much everything you wrote except the above
>paragraph.
>
>An attacker can create a transaction that would be valid if it were an
>OP_NOP, but not valid if it were any more restrictive transaction. For
>example, an attacker might send 1 BTC to an address with . An old node
>would consider that OP_CLTV to be OP_NOP, so no signature is necessary
>for old nodes. Then the attacker buys something from a merchant running
>old node code or an SPV client, and spends the 1 BTC in that address in
>a way that is invalid according to OP_CLTV but valid according to
>OP_NOP, and includes a hefty fee. A miner on the old version includes
>this transaction into a block, thereby making the block invalid
>according to the new rules, and rejected by new-client miners. The
>merchant sees the 1-conf, and maybe even 2-conf, rejoices, and ships.
>The attacker then has until the OP_CLTV matures to double-spend the
>coin with new nodes using a valid signature.
>
>Basically, it's trivial to create transactions that exploit the
>difference in validation rules as long as miners are still on the old
>version to mine them. Transactions can be created that are guaranteed
>to be orphaned and trivially double-spendable. Attackers never have to
>risk actual losses. This can be done as long as miners continue to mine
>old-version blocks, regardless of their frequency.
>
>Those of you who know Script better than me: would this be an example
>of a transaction that would be spendable with a valid sig XOR with (far
>future date OR old code)?
>
>OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIGVERIFY
>OP_PUSHDATA <locktime far in the future> OP_CLTV
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------YN5WURKKKCR50AUEBY5UZJ474W6K40
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii" /></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">That's why it's important to measure miner adoptance. Note that this isn't a vote - it's an adoption metric for what is presumably a fairly uncontroversial upgrade. If there's contentious controversy amongst miner all bets are off.<br>
<br>
Our current mechanisms are imperfect in this regard...as we've seen in the past, miners have deliberately disabled checks despite signaling adoption in their blocks. But a real hashpower supermajority would make such attacks hard to pull off in practice.<br>
<br>
- Eric<br><br><div class="gmail_quote">On October 7, 2015 8:46:08 AM PDT, "Jonathan Toomim (Toomim Bros) via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br /><div><div>On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br class="Apple-interchange-newline" /><blockquote type="cite"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">*But* a soft fork that only forbids transactions that would previously</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" /><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">not have been mined anyway should be the best of both worlds, as it</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" /><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start
;
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">automatically reduces the liklihood of old miners building newly invalid</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" /><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">blocks to a vanishingly small probability; which means t
hat
upgraded</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" /><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" /><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">continuing to work fine during the upgrade.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" /></blockquote></div><br /><div>I agree with pretty much everything you wrote except the above paragraph. </div><div><br /></div><div>An at
tacker
can create a transaction that would be valid if it were an OP_NOP, but not valid if it were any more restrictive transaction. For example, an attacker might send 1 BTC to an address with . An old node would consider that OP_CLTV to be OP_NOP, so no signature is necessary for old nodes. Then the attacker buys something from a merchant running old node code or an SPV client, and spends the 1 BTC in that address in a way that is invalid according to OP_CLTV but valid according to OP_NOP, and includes a hefty fee. A miner on the old version includes this transaction into a block, thereby making the block invalid according to the new rules, and rejected by new-client miners. The merchant sees the 1-conf, and maybe even 2-conf, rejoices, and ships. The attacker then has until the OP_CLTV matures to double-spend the coin with new nodes using a valid signature.</div><div><br /></div><div>Basically, it's trivial to create transactions that exploit the difference in validation ru
les as
long as miners are still on the old version to mine them. Transactions can be created that are guaranteed to be orphaned and trivially double-spendable. Attackers never have to risk actual losses. This can be done as long as miners continue to mine old-version blocks, regardless of their frequency.</div><div><br /></div><div>Those of you who know Script better than me: would this be an example of a transaction that would be spendable with a valid sig XOR with (far future date OR old code)?</div><div><br /></div><div>OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_PUSHDATA <locktime far in the future> OP_CLTV</div><p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br
/></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------YN5WURKKKCR50AUEBY5UZJ474W6K40--
|
