MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@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>
Date: Tue, 8 Dec 2015 23:59:33 +0000
Message-ID: <CAAS2fgTGYSiAJHZq80rD4UieV8XetS=W0b45b5onWAS9gF-F7g@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
> coinbase is messy and will just complicate consensus-critical code (as
> opposed to making the right side of the merkle tree in block.version=3D5
> blocks the segwitness data).

It's nearly complexity-costless to put it in the coinbase transaction.
Exploring the costs is one of the reasons why this was implemented
first.

We already have consensus critical enforcement there, the height,
which has almost never been problematic. (A popular block explorer
recently misimplemented the var-int decode and suffered an outage).

And most but not all prior commitment proposals have suggested the
same or similar.  The exact location is not that critical, however,
and we do have several soft-fork compatible options.

> It will also make any segwitness fraud proofs significantly larger (merkl=
e
> path versus  merkle path to coinbase transactions, plus ENTIRE coinbase
> transaction, which might be quite large, plus merkle path up to root).

Yes, it will make them larger by log2() the number of transaction in a
block which is-- say-- 448 bytes.

With the coinbase transaction thats another couple kilobytes, I think
this is negligible.

From a risk reduction perspective, I think it is much preferable to
perform the primary change in a backwards compatible manner, and pick
up the data reorganization in a hardfork if anyone even cares.

I think thats generally a nice cadence to split up risks that way; and
avoid controversy.

> We also need to fix the O(n^2) sighash problem as an additional BIP for A=
NY
> blocksize increase.

The witness data is never an input to sighash, so no, I don't agree
that this holds for "any" increase.

> Segwitness will make the current bottleneck (block propagation) a little
> worse in the short term, because of the extra fraud-proof data.  Benefits
> well worth the costs.

The fraud proof data is deterministic, full nodes could skip sending
it between each other, if anyone cared; but the overhead is pretty
tiny in any case.

> I think a barrier to quickly getting consensus might be a fundamental
> difference of opinion on this:
>    "Even without them I believe we=E2=80=99ll be in an acceptable positio=
n with
> respect to capacity in the near term"
>
> The heaviest users of the Bitcoin network (businesses who generate tens o=
f
> thousands of transactions per day on behalf of their customers) would
> strongly disgree; the current state of affairs is NOT acceptable to them.

My message lays out a plan for several different complementary
capacity advances; it's not referring to the current situation--
though the current capacity situation is no emergency.

I believe it already reflects the emerging consensus in the Bitcoin
Core project; in terms of the overall approach and philosophy, if not
every specific technical detail. It's not a forever plan, but a
pragmatic one that understand that the future is uncertain no matter
what we do; one that trusts that we'll respond to whatever
contingencies surprise us on the road to success.