+Return-Path: <gmaxwell@gmail.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 3981C504

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 7 Jul 2017 23:22:40 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com

+ [209.85.213.51])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C8C7193

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 7 Jul 2017 23:22:39 +0000 (UTC)

+Received: by mail-vk0-f51.google.com with SMTP id r125so25374701vkf.1

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 07 Jul 2017 16:22:39 -0700 (PDT)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;

+ h=mime-version:sender:in-reply-to:references:from:date:message-id

+ :subject:to:cc;

+ bh=tp22mJ8G2dKcRd9WZO1lGQzBPJvNDZwwmRNRotFdfKM=;

+ b=G7anE+FNinIyBdCiSqvMUCUVIl2OANtWmzNRTKalLOejNrV40PJgXTAsITCz8A3CUQ

+ Id93r7y0xRBBgNpby03CFJ/CqJEaJh2VRWOTnkH0Z9eqcXx6f4W/+g7hBKVCbjip/rBx

+ 62L98CBhC7ZImKDNteEXIOdcI+kT34fg/bbF1ZiZ+u2h2JeHmaERvECRIhrXe0wHHa7w

+ RMu1xADsEn1SKkS8Ulj04L2gsXAUsz3T8sgDAaavepdK7644/MvOigD4NxlgaNr42t+r

+ AHHm1M034lLOVyNVO63/rrOMF8fRuJVF0/KwTRHlF9Zfc5hgStfMJCOdM7a5r6WEU+Wh

+ t1zg==

+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

+ d=1e100.net; s=20161025;

+ h=x-gm-message-state:mime-version:sender:in-reply-to:references:from

+ :date:message-id:subject:to:cc;

+ bh=tp22mJ8G2dKcRd9WZO1lGQzBPJvNDZwwmRNRotFdfKM=;

+ b=LK+LvFLuI7OR4KC+pnvRLZnC9qnH5UlONH5uIkq+LL7Z8RWDaXgyOZ6XEVS7wRF7kI

+ IYl+iW8462fiCeiN2m6S3EoaPqoyvAlZ3gLDPZkX/LJGUH4bjpPQQ+5HpyABUIV5tStn

+ atR0gStGXh0dqisUKv1L3KaiU4Mb6PxnkcDl4j9TkLu3xUpBCMi0M1NaWpO3mVpQ27AR

+ k52wEXp+Ool/+5GFE0mshyiG1H6MriQRIbx8CYPa4fQ2ME2UWjBlWBHyKg9kvRr2ocNv

+ vYsbgAicUTksetv1u73lXxJp+xC74Z85/tR1YkfaMokuGhm1+ZbflZiGpIZ8JB2fK5iZ

+ P6rg==

+X-Gm-Message-State: AIVw110v1PKgDteRxRhSo/d/zmK1a7hdAJU1yWnLpf7/nul0PQ0aL4Lt

+ P95lNaELngp9DzAQH1UstyxGGDWj8w==

+X-Received: by 10.31.158.77 with SMTP id h74mr1802264vke.84.1499469758521;

+ Fri, 07 Jul 2017 16:22:38 -0700 (PDT)

+MIME-Version: 1.0

+Sender: gmaxwell@gmail.com

+Received: by 10.103.40.2 with HTTP; Fri, 7 Jul 2017 16:22:38 -0700 (PDT)

+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

+X-Google-Sender-Auth: _qMbH2AXy9eOdjC8yR88XQAjVNI

+Message-ID: <CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>

+To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>

+Content-Type: text/plain; charset="UTF-8"

+X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,

+ DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,

+ RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1

+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on

+ smtp1.linux-foundation.org

+Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>

+Subject: Re: [bitcoin-dev] A Segwit2x BIP

+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org

+X-Mailman-Version: 2.1.12

+Precedence: list

+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>

+X-List-Received-Date: Fri, 07 Jul 2017 23:22:40 -0000

+

+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. )

+