Date: Mon, 21 Dec 2015 18:07:47 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151221080747.GA24839@sapphire.erisian.com.au>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<20151208110752.GA31180@amethyst.visucore.com>
	<CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
	<CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
	<CAPg+sBhQN2HDvH8dfq2VsQ0dTA9V=HgQsCJdP6B72fj1SDA4yw@mail.gmail.com>
	<CADJgMzuk9Q09AnmR5=77p0HfkeUWOTRSNCSkAAQN0zDq4Hsbqw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADJgMzuk9Q09AnmR5=77p0HfkeUWOTRSNCSkAAQN0zDq4Hsbqw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

On Mon, Dec 21, 2015 at 05:21:55AM +0000, Btc Drak via bitcoin-dev wrote:
> On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <
> > So I'd like to ask the community that we work towards this plan, as it
> > allows to make progress without being forced to make a possibly divisive
> > choice for one hardfork or another yet.
> Thank you for saying this. I also think the plan is solid and delivers
> multiple benefits without being contentious. The number of wins are so
> numerous, it's frankly a no-brainer.

+1's are off-topic, but... +1. My impression is that each of libsecp256k1,
versionbits, segregated witness, IBLT, weak blocks, and OP_CSV have
been demonstrated to be significant improvements that are implementable,
and don't introduce any new attacks or risks [0]. There's some freaking
awesome engineering that's gone into all of those.

> I guess the next step for segwit is a BIP and deployment on a testnet?

I think the following proposed features are as yet missing from Pieter's
segwit branch, and I'm guessing patches for them would be appreciated:

 - enforcing the proposed base+witness/4 < 1MB calculation
 - applying limits to sigops seen in witness signatures

I guess there might be other things that still need to be implemented
as well (and presumably bugs of course)?

I think I'm convinced that the proposed plan is the best approach (as
opposed to separate base<1MB, witness<3MB limits, or done as a hard fork,
or without committing to a merkle head for the witnesses, eg), though.

jl2012 already pointed to a draft segwit BIP in another thread, repeated
here though:

 https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki

Cheers,
aj (hoping that was enough content after the +1 to not get modded ;)

[0] I'm still not persuaded that even a small increase in blocksize
    doesn't introduce unacceptable risks (frankly, I'm not entirely
    persuaded the *current* limits don't have unacceptable risk) and that
    frustrates me no end. But I guess (even after six months of reading
    arguments about it!) I'm equally unpersuaded that there's actually
    more to the intense desire for more blocksize is anything other than
    fear/uncertainty/doubt mixed with a desire for transactions to be
    effectively free, rather than costing even a few cents each... So,
    personally, since the above doesn't really resolve that quandry
    for me, it doesn't really resolve the blocksize debate for me
    either. YMMV.