MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAOG=w-sN5Kc5_W07iSKvZqSz_cNu50rkoQ65cP3_bWeFNcyizA@mail.gmail.com>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<20151208110752.GA31180@amethyst.visucore.com>
	<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
	<CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
	<CAAS2fgTGYSiAJHZq80rD4UieV8XetS=W0b45b5onWAS9gF-F7g@mail.gmail.com>
	<CABsx9T1i50Gvxj18W=n2mYGNpsMrSkDT26CdA3aQqT5FFN86yw@mail.gmail.com>
	<CAAS2fgSxpSat3VOje3-C4zgaRUVJVx-eRJbSYJqhvfR5SvCDwA@mail.gmail.com>
	<CAF_2MyUJMdJyh7FKq6UYCtwJZQ59i-pnWT_tFEK5EQx65iwHDQ@mail.gmail.com>
	<CAAS2fgS-jjEVeHf_LErppTadtAaSeBum+KiGHpoo=Jz5BZArsQ@mail.gmail.com>
	<CAOG=w-sN5Kc5_W07iSKvZqSz_cNu50rkoQ65cP3_bWeFNcyizA@mail.gmail.com>
Date: Wed, 9 Dec 2015 07:17:08 +0000
Message-ID: <CAAS2fgTpWCEQxx2PGY4wj085iBG-vNzAx33bZ1ZqgORcdX0S0g@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

On Wed, Dec 9, 2015 at 6:59 AM, Mark Friedenbach <mark@friedenbach.org> 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.