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 7B39A1BAA for ; Wed, 30 Sep 2015 21:01:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB1B51C3 for ; Wed, 30 Sep 2015 21:01:10 +0000 (UTC) Received: by igxx6 with SMTP id x6so707611igx.1 for ; Wed, 30 Sep 2015 14:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tmH3lZqfgeXRk3yglITZNwoDhp8oYlgyFB0jyhEjxQ0=; b=bg+rZ5wGFLiLwxeHGHS49iaI2SNLGSkvXp8mgUXrRTOuKjRacggAsL7zHQHX1HGeTz 3RKhcMBnk2WtW6Rz8g4gDeKoKcdBBajCn7/6ws3ce0WY2hJiLfwB4jAZXyeZtGEwiTV6 +kcOm8wBK33K/R5Aol9O19wcNc3hAX+DGeNn8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tmH3lZqfgeXRk3yglITZNwoDhp8oYlgyFB0jyhEjxQ0=; b=Yo/Y/6vu2Xje1leoGq3FOTDuMA3wn5g5DF83oZRtZMZd3nZ31OpDVUZuZ5gprxIVXY KzoFBNr2nHC4adXXacSESkCW9VP4tG3qhlcaFUUOvrOTBqmonqMTYrBVKxujDJ0eZyAs TZA/4POjgEmd3oMUknK8rOIIoTTz6BXVExcfPb/yh+lUfTWUKVFtd4MdzB5m3VetEO1O zD97Eaab5Oslidx4rkVMtFFKm+50HO5AHCF/AOPKAcEKy4x+KPJ1QibaeM6BxafHHQi6 7DkhguRf+mERlkHP5NxM3cxdNsdxMRaeFRqH7Q+9KwyVRSbrQxI1KEVEp7IGuth7v10D mtFQ== X-Gm-Message-State: ALoCoQkQRfVYBkVxHDM5IhMqvrBcPOo1/zg+ciw5sV4oOtUTd0+oXkRxM1IorAsUv1bUieQIPJ5R MIME-Version: 1.0 X-Received: by 10.50.66.146 with SMTP id f18mr32367085igt.83.1443646870198; Wed, 30 Sep 2015 14:01:10 -0700 (PDT) Received: by 10.50.123.166 with HTTP; Wed, 30 Sep 2015 14:01:09 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Wed, 30 Sep 2015 23:01:09 +0200 Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7bdc09f6e14ada0520fd3ae6 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 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, 30 Sep 2015 21:01:12 -0000 --047d7bdc09f6e14ada0520fd3ae6 Content-Type: text/plain; charset=UTF-8 tl;dr Nothing I have read here has changed my mind. There is still no consensus to deploy CLTV in this way. > Yes, your article contained numerous factual and logical inaccuracies > which I corrected > I responded to your response several times. It was not convincing, and I do not think you corrected factual inaccuracies. I mean, you said yourself you once used the correct terminology of forwards compatibility but stopped only because the term "backwards compatibility" is more common. But that's not a good reason to use a term with the opposite meaning and is certainly not a factual correction! > Yes, because what 101 does is not a hard-fork from the perspective of > BitcoinJ clients. Please do not conflate BitcoinJ with all of SPV; I coined the term SPV so I know exactly what it means, and bitcoinj implements it, as does BreadWallet (the other big SPV implementation). Yes, SPV wallets will follow the mining hashpower instead of doing a hard reject for bigger blocks, because they deliberately check a subset of the rules: block size is not and never has been one of them. Indeed it's not even included in the protocol messages. Users have no expectation that SPV wallets would check that, as it's never been claimed they do. On the other hand, full nodes all claim they run scripts. Users expect that and may be relying on it. The unstated assumption here is that the nodes run them correctly. A soft fork breaks this assumption. I'm going to ignore the rest of the stuff you wrote about "design decisions to lack security" or "cheaply avoidable lack of validation". When you have sat down and written an SPV implementation by yourself, then shipped it to a couple of million users, you might have better insight into basic engineering costs. Until then, I find your criticisms of code you think was missing due to "stonewalling" and so on to be seriously lacking real world experience. Yes, a hypothetical full node could fork on the version bits. I would be quite happy with the version number in the header being an enforced consensus rule: it'd make hard forks easier to trigger. But it hasn't been done that way, and wishing away the behaviour of existing software in the field is no good. Luckily, for introducing a new opcode, the same effect can be achieved by using a non-allocated opcode number. > For many changes, including CLTV the actual soft fork change is by far > the most natural way of implementing the change itself. This is subjective. I'd say picking an entirely new opcode number is most natural. The rest of your argument boils down to "people don't have to upgrade if they don't want to", which is addressed in the article I wrote already, and multiple responses on this thread. Yes, they do, otherwise they aren't getting the security level they were before. > Could [P2SH] have been done as a hard-fork? Likely not: you would have > prevented it. What? This is nonsensical. P2SH was added to the full verification code quite quickly, but it didn't matter much because nobody uses bitcoinj for mining. The docs explicitly tell people, in fact, not to mine on top of bitcoinj: https://bitcoinj.github.io/full-verification So no, bitcoinj+P2SH was irrelevant from a fork type perspective. It just had no effect at all. This entire section of your message is completely wrong. The code that did take longer was for wallet support. And the reason it came later was resource prioritisation: there were more important issues to resolve. Like I said - write the amount of code I've written, unpaid in your evenings and weekends, and then you can criticise bitcoinj for lacking features. 75% is a fine activation threshold. By definition if support is at 75% then bigger blocks is "winning", but if support fell, then the SPV wallets would just reorg back onto the 1mb-blocks chain. Re: demonstrated track record. They "work" only if you ignore the actual problems that have resulted. P2SH-invalid blocks were being mined for weeks after the flag day. That's not good no matter how you slice it: even if you didn't hear about any fraud resulting, it is still risk that can be avoided. --047d7bdc09f6e14ada0520fd3ae6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
tl;dr Nothing I have read here has changed my mind. There is still no cons= ensus to deploy CLTV in this way.=C2=A0
=C2=A0
Yes, your article contained numerous factual and logical inaccuracies which I corrected

I responded to your r= esponse several times. It was not convincing, and I do not think you correc= ted factual inaccuracies. I mean, you said yourself you once used the corre= ct terminology of forwards compatibility but stopped only because the term = "backwards compatibility" is more common. But that's not a go= od reason to use a term with the opposite meaning and is certainly not a fa= ctual correction!
=C2=A0
Yes, because w= hat 101 does is not a hard-fork from the perspective of
BitcoinJ clients. Please do not conflate BitcoinJ with all of SPV;

I coined the term SPV so I know exactly what it mea= ns, and bitcoinj implements it, as does BreadWallet (the other big SPV impl= ementation).

Yes, SPV wallets will follow the mini= ng hashpower instead of doing a hard reject for bigger blocks, because they= deliberately check a subset of the rules: block size is not and never has = been one of them. Indeed it's not even included in the protocol message= s. Users have no expectation that SPV wallets would check that, as it's= never been claimed they do.

On the other hand, fu= ll nodes all claim they run scripts. Users expect that and may be relying o= n it. The unstated assumption here is that the nodes run them correctly. A = soft fork breaks this assumption.

I'm going to= ignore the rest of the stuff you wrote about "design decisions to lac= k security" or "cheaply avoidable lack of validation". When = you have sat down and written an SPV implementation by yourself, then shipp= ed it to a couple of million users, you might have better insight into basi= c engineering costs. Until then, I find your criticisms of code you think w= as missing due to "stonewalling" and so on to be seriously lackin= g real world experience.

Yes, a hypothetical full = node could fork on the version bits. I would be quite happy with the versio= n number in the header being an enforced consensus rule: it'd make hard= forks easier to trigger. But it hasn't been done that way, and wishing= away the behaviour of existing software in the field is no good. Luckily, = for introducing a new opcode, the same effect can be achieved by using a no= n-allocated opcode number.
=C2=A0
For many = changes, including CLTV the actual soft fork change is by far
the most natural way of implementing the change itself.
<= br>
This is subjective. I'd say picking an entirely new opcod= e number is most natural.

The rest of your argumen= t boils down to "people don't have to upgrade if they don't wa= nt to", which is addressed in the article I wrote already, and multipl= e responses on this thread. Yes, they do, otherwise they aren't getting= the security level they were before.=C2=A0
=C2=A0
Could [P2SH] have been done as a hard-fork?=C2=A0 Likely not: you= =C2=A0would have prevented it.

What? This = is nonsensical. P2SH was added to the full verification code quite quickly,= but it didn't matter much because nobody uses bitcoinj for mining. The= docs explicitly tell people, in fact, not to mine on top of bitcoinj:


So no, bitcoinj+P2SH was irrelevant from a fork type perspective. It= just had no effect at all. This entire section of your message is complete= ly wrong.

The code that did take longer was = for wallet support. And the reason it came later was resource prioritisatio= n: there were more important issues to resolve. Like I said - write the amo= unt of code I've written, unpaid in your evenings and weekends, and the= n you can criticise bitcoinj for lacking features.

75% is a fine activation threshold. By definition if support is at 75% the= n bigger blocks is "winning", but if support fell, then the SPV w= allets would just reorg back onto the 1mb-blocks chain.

Re: demonstrated track record. They "work" only if you igno= re the actual problems that have resulted. P2SH-invalid blocks were being m= ined for weeks after the flag day. That's not good no matter how you sl= ice it: even if you didn't hear about any fraud resulting, it is still = risk that can be avoided.
--047d7bdc09f6e14ada0520fd3ae6--