Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DAC37A1B for ; Tue, 8 Dec 2015 23:59:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 432A7135 for ; Tue, 8 Dec 2015 23:59:34 +0000 (UTC) Received: by igcto18 with SMTP id to18so28744014igc.0 for ; Tue, 08 Dec 2015 15:59:33 -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:content-transfer-encoding; bh=CQngwCW9RjmpsFHCussEcuMYC9ymFhIhNJYahFIFJ9Q=; b=I5YiNdX1xHIqjUcJMbMwe0dEHuaZ90Fx+HDWJHsMuE/rAAlomsjZxfAqg3qU45ATR9 U+EI+l0KZ+Z1dZmpr61lXpZz8s0GGb244oMCw3TulKWn9QL9Jat/qmXIyCieXUwAYdNb FDf3LqfDpCRD7bWQJLbLzkCoxc9k0c7yGjQjs3VRr2LHca4uZQksJg7a/q76RhcP0BSC GjhOwU3J17R4C6gxgEwOBqHw1DFGcwu9r842ZoAROHcdi7fVMwYEHp4UxYOL/5vgdTkF 3j7DrvzpJm37LvibcWOmfVd64CEs7kxXPrne0v1mq0SgeUGYlwDoE5QhSv/mCyNEL7QL UtJw== MIME-Version: 1.0 X-Received: by 10.50.134.2 with SMTP id pg2mr23177311igb.48.1449619173796; Tue, 08 Dec 2015 15:59:33 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.107.192.70 with HTTP; Tue, 8 Dec 2015 15:59:33 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> Date: Tue, 8 Dec 2015 23:59:33 +0000 X-Google-Sender-Auth: aNQ7vDxIdfPrsFbWcZaHQGXudo8 Message-ID: From: Gregory Maxwell To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 08 Dec 2015 23:59:35 -0000 On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev 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.