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 587B81281 for ; Wed, 7 Oct 2015 06:13:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CDDD7102 for ; Wed, 7 Oct 2015 06:13:24 +0000 (UTC) Received: by iofh134 with SMTP id h134so11673470iof.0 for ; Tue, 06 Oct 2015 23:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Ye5Bpkd+TBi++oCMhr09Ime28K5MMUOLfeOM5pzDXY=; b=Kkvyzr7JaCbjKu8sc0t0iryg6peKaFuOBYC4+tH6xOPHlmeDyN9RKMgYbIsCCxYFVL scHOLhZBlyJIEo59hoFru07vea35s/s1h88LagDGG3/ssunpa9MbRIjxOPSQOH5+nufz zDlzPUvq4H9senveuwy8e4boNIm4mMnQO0e+1t4uay/soH/TySzJmeiyrCU3VTNe128k aglcJ9W6JHB9jObWUL+a4SldvhXs9uk2zY90rgHHagRrEmIKUR4bT1REX9jFF7xnlk/9 qtQatnx+BKX2RhlTlK3n829v/8sHdX5+vMx8uMQ0q9/ts1Dq8ZeDgRQIJ4n7G36Jg5hu JI7Q== MIME-Version: 1.0 X-Received: by 10.107.9.222 with SMTP id 91mr43320077ioj.107.1444198404215; Tue, 06 Oct 2015 23:13:24 -0700 (PDT) Received: by 10.79.37.68 with HTTP; Tue, 6 Oct 2015 23:13:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Oct 2015 09:13:23 +0300 Message-ID: From: Micha Bailey To: Mike Hearn Content-Type: multipart/alternative; boundary=001a113eba38de733f05217da4d2 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 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, 07 Oct 2015 06:13:25 -0000 --001a113eba38de733f05217da4d2 Content-Type: text/plain; charset=UTF-8 On Monday, October 5, 2015, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > As Greg explained to you repeatedly, a softfork won't cause a >> non-upgraded full node to start accepting blocks that create more >> subsidy than is valid. >> > > It was an example. Adam Back's extension blocks proposal would, in fact, > allow for a soft forking change that creates more subsidy than is valid (or > does anything else) by hiding one block inside another. > Maybe I'm missing something, but wouldn't this turn into a hard fork the moment you try to spend an output created in one of these extension blocks? So sure, the block that contains the extension would be considered valid, but unupgraded validators will not update the UTXO set accordingly, meaning that those new TXOs can't be spent because, according to their rules, they don't exist. > > --001a113eba38de733f05217da4d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, October 5, 2015, Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
= As Greg explained to you repeatedly, a softfork won't cause a
non-upgraded full node to start accepting blocks that create more
subsidy than is valid.

It was an exampl= e. Adam Back's extension blocks proposal would, in fact, allow for a so= ft forking change that creates more subsidy than is valid (or does anything= else) by hiding one block inside another.

Maybe I'm missing something, but wouldn't t= his turn into a hard fork the moment you try to spend an output created in = one of these extension blocks? So sure, the block that contains the extensi= on would be considered valid, but unupgraded validators will not update the= UTXO set accordingly, meaning that those new TXOs can't be spent becau= se, according to their rules, they don't exist.

--001a113eba38de733f05217da4d2--