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 DA38F259 for ; Mon, 22 May 2017 12:29:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF02216F for ; Mon, 22 May 2017 12:29:33 +0000 (UTC) Received: by mail-ua0-f178.google.com with SMTP id y4so51658819uay.2 for ; Mon, 22 May 2017 05:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uomk1VHxmHxIcF7Z6/TGIVfl0TyzaFKkAKa5RABeiNA=; b=dOasTtYWYPTCjTCWxOXhAgTbV7or929tjTt1ODqS3yyu//ZGPhNvtarbeJo4UEhMEv 4VIZRWaBqTr/owCDoWlqsIZbwUA8dNXxsIHbygrtRFabpnPwjJvVvxufaDeMenoRiENi GP/nmN52d7AoTzufy0ZRgoYmiHqt1xw7ymXfgvpm1dDJ/L8Ep4wiHWPfx0p0sByiWD5d m5ePVHzdqfxHqlfOH+aMNDSLSd0e/9bgCENPekuICZYjqaIbbKcF274W1hgUCexT9cMW XS6x4jQ3hAjxkB9oA0Hd6mdXZYcsoWMygQP3xSbVY578lVtCiYj5tTNxdoBLPp1u6TGu K+2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uomk1VHxmHxIcF7Z6/TGIVfl0TyzaFKkAKa5RABeiNA=; b=RjpJVrWEfFDiCGEnm59whfIzgZhgu9e+PuZz8BX9bDnRdUanQEgHxDmgqI9XsdUYL3 p5RK9/0Vc8CIeu2Zf9/hrAcNxRYoprGS1IJFeQWxwItY1L4sbFRgBWrVSNe7ylbw5/Dh wG5hDi8rXOh6F6d16ncHsZichX1lEbW9xHpSE8D33AkMbkICeRpQhmaG4ay4eqYjzC/N 5zjgV/I0QY9g/zNjxQB2dt4y/5/dPjvswIXTZT1ZwMgBPb0U3ml40hSVUBULCgmxZCB7 jKgdxOGJi9TTSGiBUS8IHkSF1n1LSoKq5Ny5mhh5DKblmtMcHiciOW/sMitBjU1BU9Du uI5g== X-Gm-Message-State: AODbwcA7udAy489DAM6NS5ku1jCWy+nZvTosnMUZlw5MdVp7FgmET7w8 lGXJ1fc/Bj9VXKAczggoUXtSwlgMUhvJNoU= X-Received: by 10.176.92.103 with SMTP id a39mr12840601uag.130.1495456172560; Mon, 22 May 2017 05:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.131.16 with HTTP; Mon, 22 May 2017 05:29:12 -0700 (PDT) From: Daniele Pinna Date: Mon, 22 May 2017 14:29:12 +0200 Message-ID: To: hampus.sjoberg@gmail.com, Bitcoin Dev Content-Type: multipart/alternative; boundary="f403043eebd0f18c5405501c05cc" 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 12:46:18 +0000 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 12:29:35 -0000 --f403043eebd0f18c5405501c05cc Content-Type: text/plain; charset="UTF-8" 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 > To: shaolinfry > Cc: Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement > Message-ID: > 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 > > > > > --f403043eebd0f18c5405501c05cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I couldn't agree more. It would require however f= or the Devs to throw their weight behind this with a lot of momentum. Spoon= net has been under development for quite some time now. Counter offering Se= gWit plus Spoonnet 12-24 months later would be a very progressive stance th= at 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@p= rotonmail.ch>
Cc: Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAFMkqK_8CfaPmZgwMqGWpRujmm= yGKXhZyxK_tQ6f1OMHKdEMJA@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

I'm really happy to see people trying to cooperate to get SegWit activa= ted.
But I'm really unsure about the technicalities about Silbert's prop= osal.

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 ins= ane.
You cannot expect a 100% of all nodes in P2P network to upgrade in 4 months<= /span>.

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<= br> 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 fo= rged
> between a select number of participants https://pastebin.com/VuCYt= eJh
>
> Participants agree to immediately activate Segwit, however, under a > different activation proposal. Since I have spent the last few months<= br> > researching various activation strategies of the current BIP141 deploy= ment,
> as well as redeployment, I feel I am quite well placed to comment on t= he
> 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 th= e
> BIP141 deployment. I'm not sure how that can be considered "i= mmediate"
> activation. Surely immediate activation would just be for miners to st= art
> signalling and segwit would be activated in 4-5 weeks. The proposal se= ems
> 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 BIP14= 8
> 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<= br> > BIP148 miner triggered (MASF) with a lower threshold, above 50%. I cod= ed
> this up a few weeks ago https://github.com/bitcoin/
> bitcoin/compare/master...shaolinfry:segsignal but didnt get aroun= d 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 o= f
> two chains, and gives an improved chance to get segwit activated quick= ly
> (assuming a majority of miners wish to go this route). But hash a prim= ary
> disadvantage of still leaving the activation in the hands of miners. I= f 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/bi= tcoin/compare/master...
> shaolinfry:segsignal
> BIP148: https://github.com/bitcoi= n/bips/blob/master/bip-0148.mediawiki
> BIP149: https://github.com/bitcoi= n/bips/blob/master/bip-0149.mediawiki
>
> I think the Barry Silbert agreement is very ill considered, and clearl= y
> lacking peer review from the technical community. Suggestions of a HF = in 4
> months are completely unrealistic and without technical merits. But mo= re
> importantly, closed door agreements between selected participants is n= ot
> how to garner consensus to change a $30bn decentralized system. The pu= rpose
> of my email is to try and assist in the "immediate activation of = segwit"
> which only requires hashrate to participate; and to provide some techi= ncal
> 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 b= e
> expecting miners to cooperate in lowering their own fee income with a<= br> > 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@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--f403043eebd0f18c5405501c05cc--