MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 7 Jul 2017 23:22:38 +0000
Message-ID: <CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
Precedence: list

On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.

I'm happy to see that someone has begun writing a specification. But I
am appalled to see one just being written now for change it's authors
expect to be irreversibly applied to the network in less than 30 days.

The timeline of this proposal is recklessly short to such an extreme
level that we have never, to the best of my knowledge, seen a prior
proposal so hasty.  Nowhere does this specification provide
justification or assurance that this is at all safe.  The time line of
it violates the most minimal of responsible engineering practices, by
being shorter than even a fast development and release candidate
timeframe.   This proposal carries an extreme risk for parties to lose
money due to transaction reversals at two distinct points in time and
provides no proposed countermeasures to avoid these losses.

The proposal adds another gratuitous limit to the system: A maximum
transaction size where none existed before, yet this limit is almost
certainly too small to prevent actual DOS attacks while it is also
technically larger than any transaction that can be included today
(the largest possible transaction today is 1mb minus the block
overheads).  The maximum resource usage for maliciously crafted 1MB
transaction is enormous and permitting two of them greatly exacerbates
the existing vulnerability.

> Assuming the current transaction pattern is replicated in a 2 MB plain-sized block that is 100% filled with transactions, then the witness-serialized block would occupy 3.6 MB

But in a worst case the result would be 8MB, which this document fails
to mention.

> This is considered safe by many users, companies, miners and academics [2].

The claim that the document's [2] says that these increases are "safe"
is incorrect and is a matter which has been previously corrected by
the authors of the document:
https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/
.

The cited paper does an approximate best case analysis considering
only a couple of risk factors (in particular, block relay time, but
ignoring durability to dos attacks, robustness against state
intervention, and initial synchronization time) and concluded that 4MB
was the largest they could argue was safe. The paper goes on to then
argue that even if you crank Bitcoin's parameters to the maximum in
those dimensions that it doesn't result in a truly meaningful increase
in scalablity-- in effect, it's a weak argument against your proposal
and ones like it.

> Deploy a modified BIP91 to activate Segwit. The only modification is that the signal "segsignal" is replaced by "segwit2x".

This means that BIP-91 and your proposal are indistinguishable on the
network, because the string "segsignal" is merely a variable name used
in the software.

> If segwit2x (BIP91 signal) activates at block N,

The proposal is unable to distinguish itself from BIP-91. Does this
mean if segwit2x or BIP91 activates ?

> This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption

Considering that we just spent the whole weekend with the mempool
having ~1 block or less worth of transactions most of the time, it
seems highly likely that just activating segwit will substantially
disrupt the fee market; to say nothing for the further doubling that
isn't even tempered by new wallet adoptions.  There seems to be no
consideration given to avoiding this disruption and preventing further
emergency events when the new capacity is eventually used and software
is again left unprepared for having to pay market fees.

> and buy time for more comprehensive solutions to be developed and tested

In effect, the document admits that it isn't a solution that
meaningfully improves the scale or scalablity but rather it's just a
bailout to temporarily lower/negate transaction fees.  It doesn't seem
to make any argument (or even acknowledge) that the risks and
disruption are worth its benefit, and it exacerbates those risks by
being the product of a closed process and having a timeline shorter
than basically any software update for production software (much less
the timeframe for any consensus update previously). Kudos for being
frank here, but it's not exactly selling itself.

It seems to me that the document doesn't really even make an effort to
justify the bailout at all and don't explain how it will result in
anything except an endless series of additional fee bailouts.

Moreover, it doesn't discuss any remediation against the replay
exposure that the proposed hardfork is sure to create. ( I can
guarantee to you, I will not adopt this hardfork; especially given
that is has been made completely clear that the terms of it were set
in its closed door meetings and the input of non-supporters was not
welcome. )