path: root/b4/f96c754e5f17f8e077162903a7a8992161da1b

Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DA38F259
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 12:29:33 +0000 (UTC)
Received: by mail-ua0-f178.google.com with SMTP id y4so51658819uay.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <daniele.pinna@gmail.com>
Date: Mon, 22 May 2017 14:29:12 +0200
Message-ID: <CAEgR2PFGaTn8tqC8fMG9-9E31LauX2erUirx_6vURNrXSgYzLw@mail.gmail.com>
To: hampus.sjoberg@gmail.com, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
> >
> >
>

--f403043eebd0f18c5405501c05cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I couldn&#39;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&#39=
;d be curious to hear Johnson&#39;s opinion on this. How much more testing =
would his proposal require?<br><br></div>Daniele<br><div><div><br><br clear=
=3D"all"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div>------------------------------<w=
br>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Mon, 22 May 2017 11:23:22 +0200<br>
From: Hampus Sj?berg &lt;<a href=3D"mailto:hampus.sjoberg@gmail.com">hampus=
.sjoberg@gmail.com</a>&gt;<br>
To: shaolinfry &lt;<a href=3D"mailto:shaolinfry@protonmail.ch">shaolinfry@p=
rotonmail.ch</a>&gt;<br>
Cc: Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CAFMkqK_8CfaPmZgwMqGWpRuj=
mmyGKXhZyxK_tQ6f1OMHKdEMJA@mail.gmail.com">CAFMkqK_<wbr>8CfaPmZgwMqGWpRujmm=
yGKXhZyxK_<wbr>tQ6f1OMHKdEMJA@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
I&#39;m really happy to see people trying to cooperate to get SegWit activa=
ted.<br>
But I&#39;m really unsure about the technicalities about Silbert&#39;s prop=
osal.<br>
<br>
If we&#39;re going to do a hardfork, it makes most sense to assist Johnson =
in<br>
his spoonnet/forcenet proposals.<br>
Just doing a simple 2MB without fixing anything else is very uninteresting,=
<br>
and a hardfork without addressing replay protection seems really<br>
unprofessional to me.<br>
And proposing a hardfork <span class=3D"gmail-aBn" tabindex=3D"0"><span cla=
ss=3D"gmail-aQJ">in 4 months</span></span> in the future, is completely ins=
ane.<br>
You cannot expect a 100% of all nodes in P2P network to upgrade <span class=
=3D"gmail-aBn" tabindex=3D"0"><span class=3D"gmail-aQJ">in 4 months</span><=
/span>.<br>
<br>
I think it&#39;s much better to activate BIP141 ASAP, and then hardfork to =
2MB<br>
September 2018, or 2019 (together with forcenet/spoonnet).<br>
And if not, BIP148 is gaining momentum once again so that sounds much more<=
br>
interesting.<br>
<br>
Hampus<br>
<br>
2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev &lt;<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a>&gt;:<br>
<br>
&gt; Someone sent me a copy of the Barry Silbert agreement, an agreement fo=
rged<br>
&gt; between a select number of participants <a href=3D"https://pastebin.co=
m/VuCYteJh" rel=3D"noreferrer" target=3D"_blank">https://pastebin.com/VuCYt=
eJh</a><br>
&gt;<br>
&gt; Participants agree to immediately activate Segwit, however, under a<br=
>
&gt; different activation proposal. Since I have spent the last few months<=
br>
&gt; researching various activation strategies of the current BIP141 deploy=
ment,<br>
&gt; as well as redeployment, I feel I am quite well placed to comment on t=
he<br>
&gt; technicalities.<br>
&gt;<br>
&gt; To be clear, the proposal as far as I can see does not activate BIP141=
,<br>
&gt; but is a completely new deployment which would be incompatible with th=
e<br>
&gt; BIP141 deployment. I&#39;m not sure how that can be considered &quot;i=
mmediate&quot;<br>
&gt; activation. Surely immediate activation would just be for miners to st=
art<br>
&gt; signalling and segwit would be activated in 4-5 weeks. The proposal se=
ems<br>
&gt; to require a lower 80% threshold, I assume because they were unable to=
<br>
&gt; convince 95% of the hashpower to go trigger activation.<br>
&gt;<br>
&gt; There are a few options to activating segwit now, the first being for =
95%<br>
&gt; of hashrate to signal. The second is for the community to deploy BIP14=
8<br>
&gt; UASF which will force miners to signal segwit. Being a UASF it is date=
<br>
&gt; triggered. The third option is a redeployment of segwit on a new bit, =
but<br>
&gt; requires waiting for the existing deployment to time out, because all =
the<br>
&gt; p2p messages and service bits related to segwit must be replaced too (=
which<br>
&gt; is what BIP149 does).<br>
&gt;<br>
&gt; A fourth option, first suggested to me by James Hilliard, was to make<=
br>
&gt; BIP148 miner triggered (MASF) with a lower threshold, above 50%. I cod=
ed<br>
&gt; this up a few weeks ago <a href=3D"https://github.com/bitcoin/" rel=3D=
"noreferrer" target=3D"_blank">https://github.com/bitcoin/</a><br>
&gt; bitcoin/compare/master...<wbr>shaolinfry:segsignal but didnt get aroun=
d to<br>
&gt; posting to the ML yet. This effectively lowers the threshold from 95% =
to<br>
&gt; 65% as coded, or could be upped to 80% or whatever was preferable.<br>
&gt;<br>
&gt; I think this removes the primary risk of BIP148 causing the creation o=
f<br>
&gt; two chains, and gives an improved chance to get segwit activated quick=
ly<br>
&gt; (assuming a majority of miners wish to go this route). But hash a prim=
ary<br>
&gt; disadvantage of still leaving the activation in the hands of miners. I=
f it<br>
&gt; doesn&#39;t work out, then BIP149 can then be used as proposed, but it=
&#39;ll be<br>
&gt; even safer because we&#39;ll have futher guaged support.<br>
&gt;<br>
&gt; References:<br>
&gt;<br>
&gt; SEGSIGNAL: <a href=3D"https://github.com/bitcoin/bitcoin/compare/maste=
r." rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/<wbr>bi=
tcoin/compare/master.</a>..<br>
&gt; shaolinfry:segsignal<br>
&gt; BIP148: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-014=
8.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoi=
n/<wbr>bips/blob/master/bip-0148.<wbr>mediawiki</a><br>
&gt; BIP149: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-014=
9.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoi=
n/<wbr>bips/blob/master/bip-0149.<wbr>mediawiki</a><br>
&gt;<br>
&gt; I think the Barry Silbert agreement is very ill considered, and clearl=
y<br>
&gt; lacking peer review from the technical community. Suggestions of a HF =
in 4<br>
&gt; months are completely unrealistic and without technical merits. But mo=
re<br>
&gt; importantly, closed door agreements between selected participants is n=
ot<br>
&gt; how to garner consensus to change a $30bn decentralized system. The pu=
rpose<br>
&gt; of my email is to try and assist in the &quot;immediate activation of =
segwit&quot;<br>
&gt; which only requires hashrate to participate; and to provide some techi=
ncal<br>
&gt; input since I have done a great deal of research and development into =
the<br>
&gt; topic.<br>
&gt;<br>
&gt; Given the history we&#39;ve already passed the point where we should b=
e<br>
&gt; expecting miners to cooperate in lowering their own fee income with a<=
br>
&gt; capacity increase; but we should be open to all reasonable options in =
the<br>
&gt; interest in moving things forward in a safe and collaborative way.<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
&gt;</div></div></div></div></blockquote>
</div></div></div>

--f403043eebd0f18c5405501c05cc--