Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 82B641EC3 for ; Wed, 7 Oct 2015 16:25:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D60AD219 for ; Wed, 7 Oct 2015 16:25:53 +0000 (UTC) Received: by padhy16 with SMTP id hy16so25797624pad.1 for ; Wed, 07 Oct 2015 09:25:53 -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:message-id; bh=dA3mwWRLxSihdJ1DwG3fWOGZAj7e6CwDK3rzpWihzBg=; b=T9BgT6bYHXCAUlnhf3b6IEODMfgCwVyRTUZfj9ArsuNHkhhi5lkoc/ryvZeGP4nOVT N/dDgmkaurlIqmvMrQ9WqhAHEl72G3cmumcWSkfJOFbPMRDSuSFO0t6XTckfFhSK97BO 3zUOy8WyQd1b/ffBuhXl/7RI8wzwX5CTXuk6yk3u0+5LRGT9CxHKLZFz+KBehveYDItI pTYNLGazhEN5k5VatId4d7YfmD8L33SUiCOhKXlw0aUGELEm+71lIOHMc2N4v9CdAlFq hWJDSqPXJDoGkUjR0yQvaqszyUj9c4ZFAYiOqe4PidhokBguPahoJhkhx8PW6IuIUCPY 6yyw== X-Received: by 10.68.194.73 with SMTP id hu9mr2088644pbc.146.1444235153558; Wed, 07 Oct 2015 09:25:53 -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 pu5sm40368295pbc.58.2015.10.07.09.25.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2015 09:25:52 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> <20151007150014.GA21849@navy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GZ9I3VXTVGYXC557AB2HAEGWEI17U1" Content-Transfer-Encoding: 8bit From: Eric Lombrozo Date: Wed, 07 Oct 2015 09:25:53 -0700 To: "Jonathan Toomim (Toomim Bros)" , "Jonathan Toomim (Toomim Bros) via bitcoin-dev" , Anthony Towns Message-ID: <4A595469-D2E7-4C6A-9EDC-2DF82B0BD212@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 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 16:25:54 -0000 ------GZ9I3VXTVGYXC557AB2HAEGWEI17U1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 You're right about the potential for 1 bad confirmation even with very low frequency...but with an overwhelming supermajority of hashpower, 2 bad confirmations become quite unlikely, n bad confirmations becomes exponentially unlikely in n. As part of such soft fork deployments, it's true that old nodes might see a bad confirmation on occasion (even assuming overwhelming supermajority hashpower adoptance). So yes, old nodes and SPV clients should probably require more confirmations right around such a transition...or should upgrade. It is entirely possible to make clients warn the user if the block version is unrecognized, which will help to prevent anyone from accepting bad blocks (although SPV security necessarily relies on miners to validate for them). On October 7, 2015 9:02:14 AM PDT, Eric Lombrozo wrote: >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" wrote: >> >>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 >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------GZ9I3VXTVGYXC557AB2HAEGWEI17U1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit You're right about the potential for 1 bad confirmation even with very low frequency...but with an overwhelming supermajority of hashpower, 2 bad confirmations become quite unlikely, n bad confirmations becomes exponentially unlikely in n.

As part of such soft fork deployments, it's true that old nodes might see a bad confirmation on occasion (even assuming overwhelming supermajority hashpower adoptance). So yes, old nodes and SPV clients should probably require more confirmations right around such a transition...or should upgrade. It is entirely possible to make clients warn the user if the block version is unrecognized, which will help to prevent anyone from accepting bad blocks (although SPV security necessarily relies on miners to validate for them).

On October 7, 2015 9:02:14 AM PDT, Eric Lombrozo <elombrozo@gmail.com> wrote:
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 t hat 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 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.

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.

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. ------GZ9I3VXTVGYXC557AB2HAEGWEI17U1--