Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 321BEC8D for ; Wed, 16 Dec 2015 20:59:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A2D80169 for ; Wed, 16 Dec 2015 20:59:41 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id jw2so6020717igc.1 for ; Wed, 16 Dec 2015 12:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=648wifAd2Pw3wD8WmuUIVRrijxseXk7O1boQ/Cf47xA=; b=VaDbS542reWIqghqBEM4qYCF/B4s4UoAQC5LKekr9+Uu11r1u0u49+c+aqguhh0R1r kHg0mEFMKRBBJZYoh//oGonYMPWD/jV2Il5kbKUhdzzcq8TA/FpjBb7OZzUF4aLYq8Aj 4Nm/mfSdyquFA3JQfSQ6rsHqp6ROjv4zKETnJ0jbbs6YMLpR0SnjG6FI1uv530TN5Uf0 3kblNWECan5zUTY2I3VHtKfX6+zTWDo7Mwt6jxY2WXB4wCNsjzAWqUL/sw2aDuGMrHFL 7+rkEKkmZL9wXCrePJh1GnVU/ZpBdjJO1/ARfbyGvcCsxvn4qCBaPubYoI60rKSjLlff uOWA== MIME-Version: 1.0 X-Received: by 10.50.171.197 with SMTP id aw5mr12841142igc.21.1450299581151; Wed, 16 Dec 2015 12:59:41 -0800 (PST) Received: by 10.36.80.6 with HTTP; Wed, 16 Dec 2015 12:59:41 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 21:59:41 +0100 Message-ID: From: Pieter Wuille To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 development mailing list Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin 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: Wed, 16 Dec 2015 20:59:42 -0000 On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev wrote: > 4.3. Observations on new block economic model > > SW complicates block economics by creating two separate, supply limited > resources. Not correct. I propose defining the virtual_block_size as base_size + witness_size * 0.25, and limiting virtual_block_size to 1M. This creates a single variable to optimize for. If accepted, miners are incentived to maximize fee per virtual_block_size instead of per size. Wallet software can individually choose whether to upgrade or not. Once they upgrade, they get to perform 1.75x as many transactions for the same fee (assuming non-complex transactions), and this is independent of whether anyone else upgrades. > 5.1. Problem: Pace of roll-out will be slow - Whole Ecosystem must be > considered. > > The current apparent proposal is to roll out Segregated Witness as a soft > fork, and keep block size at 1M. > > The roll-out pace cannot simply be judged by soft fork speed - which is > months at best. Analysis must the layers above: Updating bitcoin-core (JS) > and bitcoinj (Java), and then the timelines to roll out those updates to > apps, and then the timeline to update those apps to create extended > transactions. Agree, however everyone can upgrade whenever they want, and get the reduced fees as soon as they do. This is contrary to a hard fork, which forces every full node to upgrade at once (though indeed, light clients are not necessarily forced to upgrade). > 5.2. Problem: Hard fork to bigger block size Just Works(tm) with most > software, unlike SW. > > A simple hard fork such as BIP 102 is automatically compatible with the vast > range of today's ecosystem software. > > SW requires merchants to upgrade almost immediately, requires wallet and > other peripheral software upgrades to make use of. Other updates are opt-in > and occur more slowly. BIP 70 processors need some updates. > > The number of LOC that must change for BIP 102 is very small, and the > problem domain well known, versus SW. It multiplies all current DoS vectors by a factor equal to the capacity increase factor. SW increases capacity while leaving several worst-case effects constant. > 5.4. Problem: More complex economic policy, new game theory, new bidding > structure risks. > > Splitting blocks into two pieces, each with separate and distinct behaviors > and resource values, creates two fee markets. I believe you have misunderstood the proposal in that case. > 5.5. Problem: Current SW mining algorithm needs improvement > > Current SW block template maker does a reasonable job, but makes some naive > assumptions about the fee market across an entire extended block. This is a > mismatch with the economic reality (just described). Again, I think you misunderstood. The proposal includes a single new formula for block size, and optimizes for it. In case the proposal is accepted, the mining code is automatically as optimal as it was before. > 6. Conclusions and recommendations > > A "short term bump" hard fork block size increase addresses economic and > ecosystem risks that SW does not. > > Bump + SW should proceed in parallel, independent tracks, as orthogonal > issues. I agree here. SW is not a replacement for a scale increase. However, I think it can be adopted much more easily, as it doesn't require the massively pervasive consensus that a hardfork requires to perform safely. > 7. Appendix - Other SW comments > > Hard forks provide much stronger validation, and ensure the network operates > at a fully trustless level. > > SW hard fork is preferred, versus soft fork. Soft forking SW places a huge > amount of trust on miners to validate transaction signatures, versus the > rest of the network, as the network slowly upgrades to newer clients. But old clients may not care about the new rules, and they still validate the old ones they chose to enforce. Furthermore, soft forks cannot be prevented: miners can always choose to enforce stronger rules than the network demands from them. -- Pieter