Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 21B9940A for ; Mon, 22 May 2017 09:23:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46084164 for ; Mon, 22 May 2017 09:23:23 +0000 (UTC) Received: by mail-io0-f174.google.com with SMTP id k91so77455393ioi.1 for ; Mon, 22 May 2017 02:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ak3195kmOt33imwA9yys3KllYmzO1IuPQRfecYlPTfA=; b=uDCNffAZcQTMxZ/Uxuna1XNhi5ajUOAfPg8ylA1tMKoARDczfkO6LwuYyuQ285zNmJ F/bGRdKtAuzdn60xyDXbs9n/TC08kyauuJGfbvur7+/C9J/7J0C/2TK+mpdaKmojb8tu 4UfxwqwWIAy2A8z4LNwvN9NG7YdByIIP76h7jFhHln9b1K5xSbDY4vkQM7Gar2I0tXGD SU7H2MM0DqXxpUIPjOY+aChy6ZhWMDULlIJPLYZMEBfgZJCxs4Qvl10UItPaXfgLmFGE DvPasRS7DkSUlBdoRAbpwSMH2fICrJ/u/tPOnzkYUv7zBlrQQiH7hJUFfHxq7niLyxtk SElA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ak3195kmOt33imwA9yys3KllYmzO1IuPQRfecYlPTfA=; b=b6iugHB0msAvGX5wuBFweCrXio/Dfz+HvPQdE1GMrnZb7AUMQfS2PYWMet5B2vC/3E gbodb0h65xRyBg0kqHFIR7TTieO6sZ8fNsv+saJD7cLyMu2ppLj+G7iEjcp+1HuMYo5h zkBii0HHQxp35gnbSiRFRz4KzYQmILjXm/FNlvz+GYOcMVD+NZESQZPgfMU6VhLnqbHl hheeu/Xtm810G7K5vjJoKrZCSoqgwSQDBxZde/SRAFj9I8oQOaZFoISxnaHrWKhnsj75 OtWUVKuXmXsklk54whSyqMnq5oHe6g/B1/7tBKqeIXku3FkhauqfWP5pkME6icIduwan kMdA== X-Gm-Message-State: AODbwcDe7mQ739okzEAwqgNVQCrIIS7NLgy6Z5SaZeWBrxpt1DDO7A6h QfLrCENgGrxeKg4xNjDeGrz0YvRb0oDZ X-Received: by 10.107.140.194 with SMTP id o185mr24479338iod.139.1495445002667; Mon, 22 May 2017 02:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.3.205 with HTTP; Mon, 22 May 2017 02:23:22 -0700 (PDT) In-Reply-To: <2zSehquWdVTgHhfHfQpAHZTGAyzv-XFias7rRsns0j6TpJryz6Fyvst3N0v_2_Q3KsYiyRn9qd9Gb1QLUxh5F11RAlVmvezYN8d4m8q5F-A=@protonmail.ch> References: <2zSehquWdVTgHhfHfQpAHZTGAyzv-XFias7rRsns0j6TpJryz6Fyvst3N0v_2_Q3KsYiyRn9qd9Gb1QLUxh5F11RAlVmvezYN8d4m8q5F-A=@protonmail.ch> From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Mon, 22 May 2017 11:23:22 +0200 Message-ID: To: shaolinfry Content-Type: multipart/alternative; boundary="94eb2c0887382a4dbb0550196c23" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 22 May 2017 10:43:58 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement 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: Mon, 22 May 2017 09:23:24 -0000 --94eb2c0887382a4dbb0550196c23 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 > > --94eb2c0887382a4dbb0550196c23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm really happy to see people trying to cooperat= e to get SegWit activated.
But I'm really unsure about th= e technicalities about Silbert's proposal.

If we'= re going to do a hardfork, it makes most sense to assist Johnson in his spo= onnet/forcenet proposals.
Just doing a simple 2MB without fix= ing anything else is very uninteresting, and a hardfork without addressing = replay protection seems really unprofessional to me.
And prop= osing a hardfork in 4 months in the future, is completely insane. You canno= t 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/s= poonnet).
And if not, BIP148 is gaining momentum once again s= o that sounds much more interesting.

Hampus

2017-05-22 8:12= GMT+02:00 shaolinfry via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org>:
Someone sent me a copy of the Barry Silbert agreement, an agreement forg= ed 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 mon= ths researching various activation strategies of the current BIP141 deploym= ent, as well as redeployment, I feel I am quite well placed to comment on t= he technicalities.

To be clear, the proposal a= s far as I can see does not activate BIP141, but is a completely new deploy= ment which would be incompatible with the BIP141 deployment. I'm not su= re how that can be considered "immediate" activation. Surely imme= diate activation would just be for miners to start signalling and segwit wo= uld be activated in 4-5 weeks. The proposal seems to require a lower 80% th= reshold, I assume because they were unable to convince 95% of the hashpower= to go trigger activation.

There are a few opt= ions to activating segwit now, the first being for 95% of hashrate to signa= l. The second is for the community to deploy BIP148 UASF which will force m= iners 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 exi= sting 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 Hill= iard, was to make BIP148 miner triggered (MASF) with a lower threshold, abo= ve 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 whatev= er was preferable.

I think this removes the pr= imary risk of BIP148 causing the creation of two chains, and gives an impro= ved chance to get segwit activated quickly (assuming a majority of miners w= ish 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'l= l have futher guaged support.

References:
<= /div>


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 w= ithout technical merits. But more importantly, closed door agreements betwe= en selected participants is not how to garner consensus to change a $30bn d= ecentralized system. The purpose of my email is to try and assist in the &q= uot;immediate activation of segwit" which only requires hashrate to pa= rticipate; and to provide some techincal input since I have done a great de= al of research and development into the topic.

Given the history we've already passed the point where we should be ex= pecting miners to cooperate in lowering their own fee income with a capacit= y 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


--94eb2c0887382a4dbb0550196c23--