diff options
| author | Jonathan Toomim (Toomim Bros) <j@toom.im> | 2015-10-07 08:46:08 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-07 15:46:13 +0000 |
| commit | 9182047d9af8bbcbc6744c02b5580e32cec60454 (patch) | |
| tree | 26b0cac3608a9dc00177134e3c2b4d14e3f746d2 /d2/ab98788a7c98136b78b7215c296522a9423b44 | |
| parent | b82dc80a989d48e73bda642f043d04fb4499a90d (diff) | |
| download | pi-bitcoindev-9182047d9af8bbcbc6744c02b5580e32cec60454.tar.gz pi-bitcoindev-9182047d9af8bbcbc6744c02b5580e32cec60454.zip | |
Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Diffstat (limited to 'd2/ab98788a7c98136b78b7215c296522a9423b44')
| -rw-r--r-- | d2/ab98788a7c98136b78b7215c296522a9423b44 | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/d2/ab98788a7c98136b78b7215c296522a9423b44 b/d2/ab98788a7c98136b78b7215c296522a9423b44 new file mode 100644 index 000000000..1e895af52 --- /dev/null +++ b/d2/ab98788a7c98136b78b7215c296522a9423b44 @@ -0,0 +1,237 @@ +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 <<a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li= +nuxfoundation.org</a>> 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. </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 . 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 <pubkeyhash> = +OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_PUSHDATA <locktime far in the = +future> 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-- + |