From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 021621908 for ; 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 ; 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)" In-Reply-To: <20151007150014.GA21849@navy> Date: Wed, 7 Oct 2015 08:46:08 -0700 Message-Id: References: <20150927185031.GA20599@savin.petertodd.org> <20151007150014.GA21849@navy> To: Anthony Towns 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 OP_EQUALVERIFY OP_CHECKSIGVERIFY = OP_PUSHDATA OP_CLTV --Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 7, 2015, at 8:00 AM, Anthony = Towns via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.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-- --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--