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 C9C7B17E6 for ; Mon, 28 Sep 2015 14:51:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5977023C for ; Mon, 28 Sep 2015 14:51:23 +0000 (UTC) Received: by igbni9 with SMTP id ni9so51682727igb.0 for ; Mon, 28 Sep 2015 07:51:22 -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=wGCGP4SSFrjRAHRkl6Uhe1o34TRPIlYAbsCifnvaYaA=; b=pihHMCgQbcsszOybd9eSxJ4WLqhyCMVyM2QG98FFsk66MmN2f24gUwAr+KPAZzCSAv kJ0v5C6l98KuDXfUMoYs2ajBN8wxK4FQ7j7WnxopO2buNf9ZCCqHxVdepRU/8RSZsyvr 4AHlc2MvicXJJ1qzxbP0CFGWUZ5Ws/Qx2i028= 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=wGCGP4SSFrjRAHRkl6Uhe1o34TRPIlYAbsCifnvaYaA=; b=GdwitPsfpfeC6re2WRb2bZ2XYKUCd90zziVa6O7sE2lc3HCugGMUr2p1x2mibfQ3aL koNLlBOUTh/VNuOXRBYzJsGorLLBVeBzj1bdfRyNpkwadoElEqAIwGXy3HlnNly3js0D StxfAloCUYLfbj9RBXPSlrrJtImiH7dVLp4be+7WGaNzf9aXLTmOiQU/G3GQdK50FVbD vbafLqhD6VIZ/Z0RLTWwrmQuyUrrEFfo0gJIvZr1HdGrQlHXYjec8/7dxmWW6yz4ImFg bjHpF7L9RO7B3pYU0aR4tSam8DAZBzWPcSdqRZ3eTrOkjaE2MVjaD/rDAoKk3EEQ4tsm Blpg== X-Gm-Message-State: ALoCoQnhtVqJo70iNyns3YAKcdXC3/L+ilRWKHyOOqHz6an2xKFQUmp0Za4kZk+g71s/FZR9vmV1 MIME-Version: 1.0 X-Received: by 10.50.66.146 with SMTP id f18mr16619492igt.83.1443451882742; Mon, 28 Sep 2015 07:51:22 -0700 (PDT) Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 07:51:22 -0700 (PDT) In-Reply-To: <20150928144318.GA28939@savin.petertodd.org> References: <20150927185031.GA20599@savin.petertodd.org> <20150928132127.GA4829@savin.petertodd.org> <20150928142953.GC21815@savin.petertodd.org> <20150928144318.GA28939@savin.petertodd.org> Date: Mon, 28 Sep 2015 16:51:22 +0200 Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=047d7bdc09f6b8d8bd0520cfd4d3 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: Mon, 28 Sep 2015 14:51:23 -0000 --047d7bdc09f6b8d8bd0520cfd4d3 Content-Type: text/plain; charset=UTF-8 > > Ok, so again, if that's your security criteria, what's the issue > with soft-forks? Please read my article as it's all explained there. But to reiterate: the risk is that miners will build invalid blocks on top of the best work chain, instead of an ignored lower work side chain. This opens users to payment fraud. With a hard fork, all the blocks by miners that aren't checking all the rules anymore get neatly collected together on a side chain after the split, and wallets all know how to ignore that chain. Yes, you made OP_NOPs be non-standard. So out of the box, miners won't create invalid blocks, as long as they're running Core past that version. But this makes the IsStandard function very much like a part of the consensus rules, as bypassing it can result in invalid blocks being created. Miners have always understood that they can modify this function, or even bypass it entirely, without affecting the validity of their blocks. And some miners do exactly that. So I'll repeat the question that I posed before - given that there are clear, explicit downsides, what is the purpose of doing things this way? Where is the gain for ordinary Bitcoin users? --047d7bdc09f6b8d8bd0520cfd4d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, so again, if that's your security criter= ia, what's the issue with=C2=A0soft-forks?

<= div>Please read my article as it's all explained there.

<= /div>
But to reiterate: the risk is that miners will build invalid bloc= ks on top of the best work chain, instead of an ignored lower work side cha= in. This opens users to payment fraud. With a hard fork, all the blocks by = miners that aren't checking all the rules anymore get neatly collected = together on a side chain after the split, and wallets all know how to ignor= e that chain.

Yes, you made OP_NOPs be non-standar= d. So out of the box, miners won't create invalid blocks, as long as th= ey're running Core past that version. But this makes the IsStandard fun= ction very much like a part of the consensus rules, as bypassing it can res= ult in invalid blocks being created. Miners have always understood that the= y can modify this function, or even bypass it entirely, without affecting t= he validity of their blocks. And some miners do exactly that.
So I'll repeat the question that I posed before - given tha= t there are clear, explicit downsides, what is the purpose of doing things = this way? Where is the gain for ordinary Bitcoin users?
--047d7bdc09f6b8d8bd0520cfd4d3--