path: root/fe/ad6adaf3a70ccab5c8817e1f19eb3c3714e2a6

Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CE7449E8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 22:57:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com
	[209.85.215.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4EC38147
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 22:57:37 +0000 (UTC)
Received: by mail-lf0-f54.google.com with SMTP id l13so23793872lfl.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 15:57:37 -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=r9Uuzujgb2TmqMICv4PGGkWNTu4T5SLkCjTaK3OFTRg=;
	b=e8xSk8LTFXyDAcPd92UBYmG/ZeLF8/orEjXk1LzLxoyU+cgDgHDTfgAHIhTfR8BHRK
	moNEQT+inoWhbnu18u+167zlpI5WPz0lIWFjaNIb3fjB/sVRIkv3uDy60/bprCCZVGMi
	HgWlid6LaRtv6NUrnqz2yt5ZveNExrWfE34iDmwWYxAGIbKpYV3++UoVXx+bpWcqH0RD
	uBSZ26TKi0XlqteIcolwPTj8jzEsNSIA0SpbY9oHk64WiR2DIkkXeWC0mHGFjThuzI8h
	oCzMb+7DQLCkz4s8JT9/yWfbrV+H7n38VE2ehU2KAp3gS927KhGOEBLVUq0mkyUSzWq9
	D7lQ==
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=r9Uuzujgb2TmqMICv4PGGkWNTu4T5SLkCjTaK3OFTRg=;
	b=JGXZ8BL9WgF71zNzHgcyQ32dFQOys+l/OO5le5bUgYRi+6ucqZkQ3Dk52LSkwKl7kF
	JDWlvKIdgO5MhuwAscBsjEkqMPGAazc8k1oIoiJMjQiqijVKFYjIz0rR28QLvHLKCmD3
	wJ9cr5Zbg3rcs11+QDOzLRkWg1IIjMiOvlvCyq78jL8/bXwWZfasrWPwY/dT+/NYeLHU
	zqB6XyBbQ2zOsLd/2e47x6J8tOJyQulc19LEI6/xkbGEWWRXcgftk1sO/PLrSsCf31Sa
	JSeRfZBYCIxFribhAELE6HVGUAXW5GroGhBUT7yjsMD3WSBDZb1DftCcBmDNfge/eROj
	ogdA==
X-Gm-Message-State: AKS2vOy+GdN7gd+EyE5m171FVs9ZW1UOgOTJk21iT6uRrTrSVCdGXdDM
	cUeJpcT6lSYQG+VoMSKSrog/c/+2gaq7sGM=
X-Received: by 10.25.115.155 with SMTP id h27mr2050586lfk.163.1497999455720;
	Tue, 20 Jun 2017 15:57:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 15:57:34 -0700 (PDT)
In-Reply-To: <BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org>
References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
	<CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
	<CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
	<CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
	<BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Tue, 20 Jun 2017 18:57:34 -0400
Message-ID: <CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="001a113bdc2a6ea26e05526c2d5c"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 21 Jun 2017 01:18:51 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to
 get segwit activated
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: Tue, 20 Jun 2017 22:57:38 -0000

--001a113bdc2a6ea26e05526c2d5c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I could be wrong, but the latest BIP91 implementation (also included in
Segwit2x) cuts the activation period to 336 blocks (2.33 days).  (This has
been updated at
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.)  So if 80%
of hashpower is actually running that code and signaling on bit 4 by July
25 or so, then those 80+% will start orphaning non-bit-1 blocks before Aug
1, and we avoid a split.

There may still be a few non-bit-1 blocks that get orphaned after Aug 1,
because they're mined by old BIP141 nodes.  But it seems like very few
miners won't be signaling either Segwit2x *or* BIP141 by then...

Make sense?


On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> Why do you say activation by August 1st is likely? That would require an
> entire difficulty adjustment period with >=3D95% bit1 signaling. That see=
ms a
> tall order to organize in the scant few weeks remaining.
>
> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> If segwit is activated before Aug 1, as now seems likely, there will be n=
o
> split that day.  But if activation is via Segwit2x (also likely), and at
> least some nodes do & some don't follow through with the HF 3mo later
> (again, likely), agreed w/ Greg that *then* we'll see a split - probably =
in
> Sep/Oct.  How those two chains will match up and how the split will play
> out is anyone's guess...
>
>
>
> On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Ironically, it looks like most of the segwit2x signaling miners are
> > faking it (because they're not signaling segwit which it requires).
> > It'll be unfortunate if some aren't faking it and start orphaning
> > their own blocks because they are failing to signal segwit.
>
> Well, they're doing some kind of "pre-signaling" in the coinbase at the
> moment, because the segwit2x project is still in alpha-phase according to
> the timeline. They're just showing commitment.
> I'm sure they will begin signaling on version bit 4/BIP91 as well as
> actually running a segwit2x node when the time comes.
>
>
> > As far as prevent a chain split goes, all those things
> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> > don't think that holds.
>
> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
> BIP148) node, because they wouldn't have the new consensus rule of
> requiring all blocks to signal for segwit.
> I don't believe there would be any long lasting chainsplit though (becaus=
e
> of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get
> unlucky.
>
> Hampus
>
> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Because a large percentage of miners are indifferent, right now miners
>> have
>> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>
>> Miners can simply continuing signaling segwit, which will leave them
>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>> what "segwit2x" is since they keep changing the actual definition and
>> do not have a specification; but last I saw the near-term behavior the
>> same as BIP91 but with a radically reduced activation window, so the
>> story would be the same there in the near term).
>>
>> Ironically, it looks like most of the segwit2x signaling miners are
>> faking it (because they're not signaling segwit which it requires).
>> It'll be unfortunate if some aren't faking it and start orphaning
>> their own blocks because they are failing to signal segwit.
>>
>> I don't think the rejection of segwit2x from Bitcoin's developers
>> could be any more resolute than what we've already seen:
>> https://en.bitcoin.it/wiki/Segwit_support
>>
>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > I think it is very na=C3=AFve to assume that any shift would be tempor=
ary.
>> > We have a hard enough time getting miners to proactively upgrade to
>> > recent versions of the reference bitcoin daemon. If miners interpret
>> > the situation as being forced to run non-reference software in order
>> > to prevent a chain split because a lack of support from Bitcoin Core,
>> > that could be a one-way street.
>>
>> I think this is somewhat naive and sounds a lot like the repeat of the
>> previously debunked "XT" and "Classic" hysteria.
>>
>> There is a reason that segwit2x is pretty much unanimously rejected by
>> the technical community.  And just like with XT/Classic/Unlimited
>> you'll continue to see a strong correlation with people who are
>> unwilling and unable to keep updating the software at an acceptable
>> level of quality-- esp. because the very founding on their fork is
>> predicated on discarding those properties.
>>
>> If miners want to go off and create an altcoin-- welp, thats something
>> they can always do,  and nothing about that will force anyone to go
>> along with it.
>>
>> As far as prevent a chain split goes, all those things
>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>> don't think that holds.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">I could be wrong, but the latest BIP91 implementation (als=
o included in Segwit2x) cuts the activation period to 336 blocks (2.33 days=
). =C2=A0(This has been updated at <a href=3D"https://github.com/bitcoin/bi=
ps/blob/master/bip-0091.mediawiki">https://github.com/bitcoin/bips/blob/mas=
ter/bip-0091.mediawiki</a>.) =C2=A0So if 80% of hashpower is actually runni=
ng that code and signaling on bit 4 by July 25 or so, then those 80+% will =
start orphaning non-bit-1 blocks before Aug 1, and we avoid a split.<div><b=
r></div><div>There may still be a few non-bit-1 blocks that get orphaned af=
ter Aug 1, because they&#39;re mined by old BIP141 nodes.=C2=A0 But it seem=
s like very few miners won&#39;t be signaling either Segwit2x *or* BIP141 b=
y then...</div><div><br></div><div>Make sense?</div><div><br></div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 201=
7 at 6:48 PM, Mark Friedenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark=
@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Why do you say=
 activation by August 1st is likely? That would require an entire difficult=
y adjustment period with &gt;=3D95% bit1 signaling. That seems a tall order=
 to organize in the scant few weeks remaining.=C2=A0<br></div><div><div cla=
ss=3D"h5"><div><br>On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-=
dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br><br></=
div><blockquote type=3D"cite"><div><div dir=3D"auto"><div>If segwit is acti=
vated before Aug 1, as now seems likely, there will be no split that day.=
=C2=A0 But if activation is via Segwit2x (also likely), and at least some n=
odes do &amp; some don&#39;t follow through with the HF 3mo later (again, l=
ikely), agreed w/ Greg that *then* we&#39;ll see a split - probably in Sep/=
Oct.=C2=A0 How those two chains will match up and how the split will play o=
ut is anyone&#39;s guess...<div dir=3D"auto"><br></div><br><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Jun 20, 2017 6:16 PM, &quot;Ha=
mpus Sj=C3=B6berg via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfou=
ndation.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"m_6=
51225331209638612quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div class=3D"m_651225=
331209638612quoted-text"><div>&gt; Ironically, it looks like most of the se=
gwit2x signaling miners are<br>&gt; faking it (because they&#39;re not sign=
aling segwit which it requires).<br>
&gt; It&#39;ll be unfortunate if some aren&#39;t faking it and start orphan=
ing<br>
&gt; their own blocks because they are failing to signal segwit.<br><br></d=
iv></div>Well, they&#39;re doing some kind of &quot;pre-signaling&quot; in =
the coinbase at the moment, because the segwit2x project is still in alpha-=
phase according to the timeline. They&#39;re just showing commitment.<br>I&=
#39;m sure they will begin signaling on version bit 4/BIP91 as well as actu=
ally running a segwit2x node when the time comes.<div class=3D"m_6512253312=
09638612quoted-text"><br><br>&gt; As far as prevent a chain split goes, all=
 those things<br>&gt; (148/91/segwit2x(per today)) effectively guarantee a =
chainsplit-- so I<br>&gt; don&#39;t think that holds.<br><br></div></div> S=
egwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or BIP1=
48) node, because they wouldn&#39;t have the new consensus rule of requirin=
g all blocks to signal for segwit.<br></div>I don&#39;t believe there would=
 be any long lasting chainsplit though (because of the ~80% hashrate suppor=
t on segwit2x), perhaps 2-3 blocks if we get unlucky.<br><br></div>Hampus<b=
r></div><div class=3D"m_651225331209638612elided-text"><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">2017-06-20 23:49 GMT+02:00 Gregory Ma=
xwell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<w=
br>tion.org</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue,=
 Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt; Because a large percentage of miners are indifferent, right now miners=
 have<br>
&gt; to choose between BIP148 and Segwit2x if they want to activate Segwit.=
<br>
<br>
</span>Miners can simply continuing signaling segwit, which will leave them=
<br>
at least soft-fork compatible with BIP148 and BIP91 (and god knows<br>
what &quot;segwit2x&quot; is since they keep changing the actual definition=
 and<br>
do not have a specification; but last I saw the near-term behavior the<br>
same as BIP91 but with a radically reduced activation window, so the<br>
story would be the same there in the near term).<br>
<br>
Ironically, it looks like most of the segwit2x signaling miners are<br>
faking it (because they&#39;re not signaling segwit which it requires).<br>
It&#39;ll be unfortunate if some aren&#39;t faking it and start orphaning<b=
r>
their own blocks because they are failing to signal segwit.<br>
<br>
I don&#39;t think the rejection of segwit2x from Bitcoin&#39;s developers<b=
r>
could be any more resolute than what we&#39;ve already seen:<br>
<a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=3D"noreferrer" ta=
rget=3D"_blank">https://en.bitcoin.it/wiki/Seg<wbr>wit_support</a><br>
<br>
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev<br>
<span>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt; I think it is very na=C3=AFve to assume that any shift would be tempor=
ary.<br>
&gt; We have a hard enough time getting miners to proactively upgrade to<br=
>
&gt; recent versions of the reference bitcoin daemon. If miners interpret<b=
r>
&gt; the situation as being forced to run non-reference software in order<b=
r>
&gt; to prevent a chain split because a lack of support from Bitcoin Core,<=
br>
&gt; that could be a one-way street.<br>
<br>
</span>I think this is somewhat naive and sounds a lot like the repeat of t=
he<br>
previously debunked &quot;XT&quot; and &quot;Classic&quot; hysteria.<br>
<br>
There is a reason that segwit2x is pretty much unanimously rejected by<br>
the technical community.=C2=A0 And just like with XT/Classic/Unlimited<br>
you&#39;ll continue to see a strong correlation with people who are<br>
unwilling and unable to keep updating the software at an acceptable<br>
level of quality-- esp. because the very founding on their fork is<br>
predicated on discarding those properties.<br>
<br>
If miners want to go off and create an altcoin-- welp, thats something<br>
they can always do,=C2=A0 and nothing about that will force anyone to go<br=
>
along with it.<br>
<br>
As far as prevent a chain split goes, all those things<br>
(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I<br>
don&#39;t think that holds.<br>
<div class=3D"m_651225331209638612m_-187074116781290509HOEnZb"><div class=
=3D"m_651225331209638612m_-187074116781290509h5">__________________________=
____<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
<br></blockquote></div><br></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>___________________=
___________<wbr>_________________</span><br><span>bitcoin-dev mailing list<=
/span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a></span><br><s=
pan><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/mailman/listin=
fo/bitcoin-<wbr>dev</a></span><br></div></blockquote></div></div></div></bl=
ockquote></div><br></div>

--001a113bdc2a6ea26e05526c2d5c--