Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F3059C9E for ; Wed, 9 Dec 2015 07:17:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2ED7212D for ; Wed, 9 Dec 2015 07:17:09 +0000 (UTC) Received: by ioir85 with SMTP id r85so50172931ioi.1 for ; Tue, 08 Dec 2015 23:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w9lwPuJ0fTxZgX7+azVpdL4PfnBVcZjaBwU0uwFM/U4=; b=AnGAo68L95YHwGRIbdig5M4C4q2GbI6yWW9NLIsLveZFH0nzTUtujnU1U4xM+ma40R OEpWapPVV3ckHsRkHGCHJ/M5UKOAHDikFvq9bbYFGUXiqPQr1cM0BWlqYAhHwm6DqDZh dOfKXeVCIJu1bvHsfEpM8MatvbJmBmAadS16Nbg8K+1Ph2sqAKwk0PQJxAGDxim27SS7 MRDrjawOTfFiMND6u18++bPc3iVOTE15d3E60bgQMpf96CgaIHdCEf/osYlb/WxpNR6g 4JKbUJq3U6eyDcL6JNNwC+DQ20q/OnazN8Eghs5lusNtzaE6XIMYxQLTxxU1oDks4IvU Gqhg== MIME-Version: 1.0 X-Received: by 10.107.152.7 with SMTP id a7mr3984497ioe.134.1449645428683; Tue, 08 Dec 2015 23:17:08 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.107.192.70 with HTTP; Tue, 8 Dec 2015 23:17:08 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> Date: Wed, 9 Dec 2015 07:17:08 +0000 X-Google-Sender-Auth: 2dUbKeM-7rc1VOg-Iejs9T3iRO4 Message-ID: From: Gregory Maxwell To: Mark Friedenbach Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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] Capacity increases for the Bitcoin system. 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, 09 Dec 2015 07:17:10 -0000 On Wed, Dec 9, 2015 at 6:59 AM, Mark Friedenbach wrote: > Greg, if you have actual data showing that putting the commitment in the > last transaction would be disruptive, and how disruptive, that would be > appreciated. Of the mining hardware I have looked at, none of it cared at > all what transactions other than the coinbase are. You need to provide a > path to the coinbase for extranonce rolling, but the witness commitment > wouldn't need to be updated. > > I'm sorry but it's not clear how this would be an incompatible upgrade, > disruptive to anything other than the transaction selection code. Maybe I'm > missing something? I'm not familiar with all the hardware or pooling setups > out there. I didn't comment on the transaction output. I have commented on coinbase outputs and on a hard-fork. Using an output in the last transaction would break the assumption that you can truncate a block and still have a valid block. This is used by some mining setups currently, because GBT does not generate the coinbase transaction and so cannot know its size; and you may have to drop the last transaction(s) to make room for it. That a block can be truncated and still result in a valid block also seems like a useful property to me. If the input for that transaction is supposed to be generated from a coinbase output some blocks earlier, then this may again run into hardware output constraints in coinbase transactions. (But it may be better since it wouldn't matter which output created it.). This could likely be escaped by creating a zero value output only once and just rolling it forward.