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.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to