path: root/c7/c8576c0a0b9041f6407366c0c791fb6fce98b4

Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 21B9940A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 09:23:23 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id k91so77455393ioi.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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?= <hampus.sjoberg@gmail.com>
Date: Mon, 22 May 2017 11:23:22 +0200
Message-ID: <CAFMkqK_8CfaPmZgwMqGWpRujmmyGKXhZyxK_tQ6f1OMHKdEMJA@mail.gmail.com>
To: shaolinfry <shaolinfry@protonmail.ch>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 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

<div dir=3D"ltr"><div>I&#39;m really happy to see people trying to cooperat=
e to get SegWit activated.<br></div><div>But I&#39;m really unsure about th=
e technicalities about Silbert&#39;s proposal.<br><br></div><div>If we&#39;=
re going to do a hardfork, it makes most sense to assist Johnson in his spo=
onnet/forcenet proposals.<br></div><div>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.<br></div><div>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.<br></di=
v><div><br></div><div>I think it&#39;s much better to activate BIP141 ASAP,=
 and then hardfork to 2MB September 2018, or 2019 (together with forcenet/s=
poonnet).<br></div><div>And if not, BIP148 is gaining momentum once again s=
o that sounds much more interesting.<br><br></div><div>Hampus<br></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-05-22 8:12=
 GMT+02:00 shaolinfry via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt;</span>:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv>Someone sent me a copy of the Barry Silbert agreement, an agreement forg=
ed between a select number of participants <a href=3D"https://pastebin.com/=
VuCYteJh" target=3D"_blank">https://pastebin.com/VuCYteJh</a><br></div><div=
><br></div><div>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.<br></div><div><br></div><div>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&#39;m not su=
re how that can be considered &quot;immediate&quot; 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.<br></div><div><br></div><div>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).<br></d=
iv><div><br></div><div>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 <a href=3D"https://github.com/bitco=
in/bitcoin/compare/master...shaolinfry:segsignal" target=3D"_blank">https:/=
/github.com/bitcoin/<wbr>bitcoin/compare/master...<wbr>shaolinfry:segsignal=
</a> 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.<br></div><div><br></div><div>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&#39;t work out, then BIP149=
 can then be used as proposed, but it&#39;ll be even safer because we&#39;l=
l have futher guaged support.<br></div><div><br></div><div>References:<br><=
/div><div><br></div><div>SEGSIGNAL: <a href=3D"https://github.com/bitcoin/b=
itcoin/compare/master...shaolinfry:segsignal" target=3D"_blank">https://git=
hub.com/bitcoin/<wbr>bitcoin/compare/master...<wbr>shaolinfry:segsignal</a>=
<br></div><div>BIP148: <a href=3D"https://github.com/bitcoin/bips/blob/mast=
er/bip-0148.mediawiki" target=3D"_blank">https://github.com/bitcoin/<wbr>bi=
ps/blob/master/bip-0148.<wbr>mediawiki</a><br></div><div>BIP149: <a href=3D=
"https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki" target=3D"=
_blank">https://github.com/bitcoin/<wbr>bips/blob/master/bip-0149.<wbr>medi=
awiki</a><br></div><div><br></div><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&quot; 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.<br></div><div><br></div><div=
>Given the history we&#39;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.<br></div><br>___=
___________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c0887382a4dbb0550196c23--