From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6425CE5A for ; Thu, 17 Dec 2015 10:57:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F4C0194 for ; Thu, 17 Dec 2015 10:57:22 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1a9WFL-0000PQ-Fp for ; Thu, 17 Dec 2015 20:57:20 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 17 Dec 2015 20:57:13 +1000 Date: Thu, 17 Dec 2015 20:57:13 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151217105713.GA16561@sapphire.erisian.com.au> References: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> <9869fe48a4fc53fc355a35cead73fca2@xbt.hk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9869fe48a4fc53fc355a35cead73fca2@xbt.hk> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Thu, 17 Dec 2015 10:57:23 -0000 On Thu, Dec 17, 2015 at 12:32:11AM -0500, jl2012 via bitcoin-dev wrote: > There are at least 2 proposals on the table: > 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately > equals to 2MB actual limit > 2. BIP102: 2MB actual limit I think there's a few variants of (2) -- there's "just 2MB", "2MB now, 4MB in a while, 8MB after that", "1MB for a while longer, then 2MB, then 4MB" (halved from 2/4/8 since segwit gives 1.6x-2x benefit), and variations of those with different dates, whether or not to smooth out the increases to avoid economic shocks, and how to determine activation (flag day? miner consensus? combination?). > Since the actual limits for both proposals are approximately the same, it is > not a determining factor in this discussion That's true on the benefit side (both give about double the number of ordinary transactions per block; though segregated witness has other benefits). On the cost side, the limits are different: * worst case block data size is 2x for BIP102, 4x for segwit (affecting bandwidth, latency and storage costs for nodes) * worst case sigops is 2x for BIP102, but the same as today for segwit (affecting block validation time) * worst case bytes to hash a block is 4x for BIP102 (doubling block size and sigops), but the same as today for segwit (again affecting block validation time) * worst case UTXO bloat is 2x for BIP102, but the same as today for segwit (affecting memory usage, and validation time) In the "expected" case (where people aren't attacking the blockchain) I think they're the same on all these metrics. But increasing the limits could easily make attacks more common, especially if it makes them more effective. I think the main attack vector of these is that increasing block validation time via too many (active) sigops or too many bytes hashed allows a selfish mining attack, but I'm not clear enough on how that would work exactly to estimate where the boundary between acceptable and unacceptable risk is (and how feasible non-consensus-level countermeasures might be). But at 1x sigops, you can already (accidently!) construct blocks that take minutes to verify; and at 4x you can probably already construct a block that takes 10 minutes to verify, which would probably be pretty bad... But I'm not sure this isn't already exploitable, so maybe we're already assuming a certain level of altruism and making things worse doesn't actually make them worse? I think it would be good for BIP102 or similar to include an evaluation of that risk before being deployed [0]. > The major criticism for a hardfork is requiring everyone to upgrade. Is that > really a big problem? Yes. That doesn't mean it's not worth it, though. (The 2-month timeline for the BIP50 accidental hardfork to be accepted on the network seems persuasive to me that it's possible to roll out a deliberate, SPV-compatible, hardfork on today's network in 3-6 months) > My primary proposal: > 1 Jun 2016: the first day a 2MB block may be allowed > > My secondary proposal: > 1 Jun 2016: release SWSF I think it makes sense to just do both of these independently; ie: * release segwit via softfork ASAP (perhaps targetting March or April to get it included in bitcoin, activation a month or three afterwards?), with virtual block size calculated as proposed and capped by MAX_BLOCK_SIZE [1] * increase MAX_BLOCK_SIZE via hardfork to 2MB after block 420,000 (phased in gradually? with future scheduled increases to 4MB or 8MB?) If segwit gets delayed because it's complicated, that's okay; if it comes out earlier, that's okay too. If the hardfork gets delayed because miners aren't ready or because it's better to introduce it in a staggered fashion, or because there's no clear evaluation of the risks, that's okay too. But more importantly, it allows evaluate the pros and cons of each implementation separately and on its own merits, rather than arguing against working on one just because you're in favour of doing the other ASAP. They have benefits if you combine them too; for instance, if the MAX_BLOCK_SIZE increase is phased in rather than done as a step increase (ie block x's limit is 1MB, block x+1's limit is 1.005MB or similar, and block x+2's limit is 1.01MB, etc) having segwit available in parallel could provide a helpful escape valve: if an individual bitcoin user has been dying for more capacity, they can spend the time/effort to update their software for segwit and get it immediately without having to wait as the consensus limits rise. Conversely, having both segwit and a phased increase to MAX_BLOCK_SIZE means that miners generally won't be immediately mining 2MB (or 4MB) blocks halfway through the year, which should avoid both technological shocks (bandwidth just doubled!) or economic shocks (supply has increased so fees have plummeted), which could be good. FWIW, the worst case scenarios are: * block data size: BIP102: 2x (worst/avg) segwit: 4x (worst, ~2x avg) both: 8x (worst, ~4x avg) BIP101: 8x (worst/avg) * sigops per block: BIP102: 2x segwit: 1x both: 2x BIP101: 8x * bytes hashed per block: BIP102: 4x segwit: 1x both: 4x BIP101: 64x * UTXO rate of increase: BIP102: 2x segwit: 1x both: 2x BIP101: 8x Compared to the (expected, eventual, near-term) benefits: * transactions per block: BIP102: 2x segwit: 1.6x-2x both: 3.2x-4x BIP101: 8x * misc: BIP101/2: planned hardforks are possible, bitcoin community governance is demonstrably working, etc segwit: malleability fixes, script improvements, lightning enablement, etc The block data is the only case where the average case is already just about the worst case; for the others, as long as the worst case doesn't inspire new attacks, the future average case should just increase in proportion to the additional transactions. Cheers, aj [0] (and segwit should actually account for sigops in witness data before being deployed...) [1] If segwit warrants a hardfork to clean up data structures, I think that should be deferred until well after the MAX_BLOCK_SIZE hardfork, rather than trying to do it at the same time. As such, doing segwit by soft fork in the short term seems to make sense, since it also helps with transaction malleability and further improvements to script.