Re: [bitcoin-dev] Barry Silbert segwit agreement

From: Daniele Pinna <daniele.pinna@gmail•com>
To: hampus.sjoberg@gmail•com,
	 Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
Date: Mon, 22 May 2017 14:29:12 +0200	[thread overview]
Message-ID: <CAEgR2PFGaTn8tqC8fMG9-9E31LauX2erUirx_6vURNrXSgYzLw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 5699 bytes --]

I couldn't agree more. It would require however for the Devs to throw their
weight behind this with a lot of momentum. Spoonnet has been under
development for quite some time now. Counter offering SegWit plus Spoonnet
12-24 months later would be a very progressive stance that I think would
catch the interest of large swaths of the community. I'd be curious to hear
Johnson's opinion on this. How much more testing would his proposal require?

Daniele

----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 May 2017 11:23:22 +0200
> From: Hampus Sj?berg <hampus.sjoberg@gmail•com>
> To: shaolinfry <shaolinfry@protonmail•ch>
> Cc: Bitcoin Protocol Discussion
>         <bitcoin-dev@lists•linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
> Message-ID:
>         <CAFMkqK_8CfaPmZgwMqGWpRujmmyGKXhZyxK_
> tQ6f1OMHKdEMJA@mail•gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I'm really happy to see people trying to cooperate to get SegWit activated.
> But I'm really unsure about the technicalities about Silbert's proposal.
>
> If we're going to do a hardfork, it makes most sense to assist Johnson in
> his spoonnet/forcenet proposals.
> Just doing a simple 2MB without fixing anything else is very uninteresting,
> and a hardfork without addressing replay protection seems really
> unprofessional to me.
> And proposing a hardfork in 4 months in the future, is completely insane.
> You cannot expect a 100% of all nodes in P2P network to upgrade in 4
> months.
>
> I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB
> September 2018, or 2019 (together with forcenet/spoonnet).
> And if not, BIP148 is gaining momentum once again so that sounds much more
> interesting.
>
> Hampus
>
> 2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org>:
>
> > Someone sent me a copy of the Barry Silbert agreement, an agreement
> forged
> > between a select number of participants https://pastebin.com/VuCYteJh
> >
> > Participants agree to immediately activate Segwit, however, under a
> > different activation proposal. Since I have spent the last few months
> > researching various activation strategies of the current BIP141
> deployment,
> > as well as redeployment, I feel I am quite well placed to comment on the
> > technicalities.
> >
> > To be clear, the proposal as far as I can see does not activate BIP141,
> > but is a completely new deployment which would be incompatible with the
> > BIP141 deployment. I'm not sure how that can be considered "immediate"
> > activation. Surely immediate activation would just be for miners to start
> > signalling and segwit would be activated in 4-5 weeks. The proposal seems
> > to require a lower 80% threshold, I assume because they were unable to
> > convince 95% of the hashpower to go trigger activation.
> >
> > There are a few options to activating segwit now, the first being for 95%
> > of hashrate to signal. The second is for the community to deploy BIP148
> > UASF which will force miners to signal segwit. Being a UASF it is date
> > triggered. The third option is a redeployment of segwit on a new bit, but
> > requires waiting for the existing deployment to time out, because all the
> > p2p messages and service bits related to segwit must be replaced too
> (which
> > is what BIP149 does).
> >
> > A fourth option, first suggested to me by James Hilliard, was to make
> > BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded
> > this up a few weeks ago https://github.com/bitcoin/
> > bitcoin/compare/master...shaolinfry:segsignal but didnt get around to
> > posting to the ML yet. This effectively lowers the threshold from 95% to
> > 65% as coded, or could be upped to 80% or whatever was preferable.
> >
> > I think this removes the primary risk of BIP148 causing the creation of
> > two chains, and gives an improved chance to get segwit activated quickly
> > (assuming a majority of miners wish to go this route). But hash a primary
> > disadvantage of still leaving the activation in the hands of miners. If
> it
> > doesn't work out, then BIP149 can then be used as proposed, but it'll be
> > even safer because we'll have futher guaged support.
> >
> > References:
> >
> > SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...
> > shaolinfry:segsignal
> > BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> > BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
> >
> > I think the Barry Silbert agreement is very ill considered, and clearly
> > lacking peer review from the technical community. Suggestions of a HF in
> 4
> > months are completely unrealistic and without technical merits. But more
> > importantly, closed door agreements between selected participants is not
> > how to garner consensus to change a $30bn decentralized system. The
> purpose
> > of my email is to try and assist in the "immediate activation of segwit"
> > which only requires hashrate to participate; and to provide some
> techincal
> > input since I have done a great deal of research and development into the
> > topic.
> >
> > Given the history we've already passed the point where we should be
> > expecting miners to cooperate in lowering their own fee income with a
> > capacity increase; but we should be open to all reasonable options in the
> > interest in moving things forward in a safe and collaborative way.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 7769 bytes --]