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 5CB1D71 for ; Fri, 5 Aug 2016 19:54:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149082.authsmtp.co.uk (outmail149082.authsmtp.co.uk [62.13.149.82]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B6666153 for ; Fri, 5 Aug 2016 19:54:24 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u75JsM2o043895 for ; Fri, 5 Aug 2016 20:54:22 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u75JsKiV089124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Aug 2016 20:54:21 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id EB4FE4011D for ; Fri, 5 Aug 2016 19:51:26 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id BEE31205A7; Fri, 5 Aug 2016 12:54:16 -0700 (PDT) Date: Fri, 5 Aug 2016 12:54:16 -0700 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20160805195416.GA1015@fedora-21-dvm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 674fa015-5b46-11e6-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktdZ1U/GlJ1 UkhIREJQFA9tBRYD BFAbUAd3aQROfWBx Z0Z9XHVEXQo/ckMH ATUNc20ObGZibC4e VkBddU1SdwccLx9E b016BncLfGQGM3x9 FQQ/MnVpZWwCcXsL SQhUfAIEeVwMESQx XAtKOjNnPUQfSys0 NR9uEkQbBEEKO0Ep eXUmXVYfLB4UBUVi H0wFOyJWOFgdDwAv CghZRk8MHV8VYCFX GBAhORIg X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, 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 Subject: [bitcoin-dev] Progress On Hardfork Proposals Following The Segwit Blocksize Increase X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 19:54:27 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Repost by request from my blog, apologies for the somewhat screwy formattin= g! --- layout: post title: "Progress On Hardfork Proposals Following The Segwit Blocksize Incr= ease" date: 2016-08-05 tags: - bitcoin - hardfork - segwit --- With segwit getting close to its initial testnet release in Bitcoin Core v0.13.0 - expected to be followed soon by a mainnet release in Bitcoin Core v0.13.1 - I thought it'd be a good idea to go over work being done on a potential hard-fork to follow it, should the Bitcoin community decide to ac= cept the segwit proposal. First of all, to recap, in addition to many other improvements such as fixi= ng transaction malleability, fixing the large transaction signature verificati= on DoS attack, providing a better way to upgrade the scripting system in the future, etc. segwit increases the maximum blocksize to 4MB. However, because it's a soft-fork - a backwards compatible change to the protocol - only wit= ness (signature) data can take advantage of this blocksize increase; non-witness data is still limited to 1MB total per block. With current transaction patt= erns it's expected that blocks post-segwit won't use all 4MB of serialized data allowed by the post-segwit maximum blocksize limit. Secondly, there's two potential upgrades to the Bitcoin protocol that will further reduce the amount of witness data most transactions need: [Schnorr signatures](https://bitcoinmagazine.com/articles/the-power-of-schnorr-the-s= ignature-algorithm-to-increase-bitcoin-s-scale-and-privacy-1460642496) and = [BLS aggregate signatures](http://diyhpl.us/wiki/transcripts/2016-july-bitc= oin-developers-miners-meeting/dan-boneh/). Basically, both these improvements allow multiple signatures to be combined, the former on a per-transaction level, and the latter on a per-block level. [Last February](https://medium.com/@bitcoinroundtable/bitcoin-roundtable-co= nsensus-266d475a61ff) some of the mining community and some of the developer community got togeth= er to discuss potential hard-forks, with the aim of coming up with a reasonable proposal to take to= the wider community for further discussion and consensus building. Let's look at where that effort has lead. ## Ethereum: Lessons to be learned But first, Ethereum. Or as some have quipped, the Etherea:

The Battle for Etherea. https://t.= co/2ATQRQRXnH

— Samson Mow (@Excellion) July 31, 2016