Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 021621908
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Oct 2015 15:46:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 74C8B16F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Oct 2015 15:46:12 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
	(may be forged)) (authenticated bits=0)
	by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t97Fk4IY006127
	(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
	Wed, 7 Oct 2015 08:46:04 -0700
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: "Jonathan Toomim (Toomim Bros)" <j@toom.im>
In-Reply-To: <20151007150014.GA21849@navy>
Date: Wed, 7 Oct 2015 08:46:08 -0700
Message-Id: <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>
To: Anthony Towns <aj@erisian.com.au>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVaBqEdbeWz+GANRkuSTCttkkTIyMNK461uP9bH3QLNChXfjZjCVk0fMd3PSODmza3Rw5icbkjzNsooQ9QJyEnK3
X-Sonic-ID: C;2vY8hApt5RGKHuK7sH9FTg== M;Khe9hApt5RGKHuK7sH9FTg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 15:46:13 -0000


--Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E"


--Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


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

--Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Oct 7, 2015, at 8:00 AM, Anthony =
Towns via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
style=3D"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=3D"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=3D"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=3D"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=3D"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=3D"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=3D"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 that =
upgraded</span><br style=3D"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=3D"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=3D"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=3D"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=3D"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.&nbsp;</div><div><br></div><div>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 &nbsp;. 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 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.</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 &lt;pubkeyhash&gt; =
OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_PUSHDATA &lt;locktime far in the =
future&gt; OP_CLTV</div></body></html>=

--Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E--

--Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJWFT5BAAoJEIEuMk4MG0P1PlkIAMlcg9QOFu92Ud6AIp4Z2+YO
Mrx2Pr3Dd+duFyg4T1bttxe+u4MT0FKx3zor6rRBh22Qy7f21q938CSdfis4gftC
NLLQUWK47TNFYRlBWK6UPlb/5vEajCiWoHoTxKqVq2nrjPxbV3VKDPe15I4MlGf1
yJmrOFTdmU5H4HGZLhJpr7qwe3r3RTC/sZbqeHe1EFJr5Efur1H3Yr5KA8qX8CrZ
GWzBtQEbn6ki8SLEqLu+aa+0NwRZmpmx4VQWPqrwq7Hr6TC5UrKK93/ucGtFyYCV
iXidPHMcRoWUNMb0VRUq6cXChaeJakBtW7iN4bJUCXa/+F2yb5OTA5wuE/5M7Hs=
=uIZA
-----END PGP SIGNATURE-----

--Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D--