path: root/8e/e9e0193398ffedf8a27a26663c4713a8c238ad

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 21F41AA6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 22:48:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com [74.125.83.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1EEAB183
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 22:48:53 +0000 (UTC)
Received: by mail-pg0-f47.google.com with SMTP id e187so16454366pgc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 15:48:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=FJZvkOF8xk7UwfxXJGnNIdfkISmFuuM/zLSBaj4ZhGw=;
	b=uIhwYpvctNuvfInX3r+mxQuP/GT4X9MjGtPKHu4jpK7sI2ffOfVzN0bPgwMdLM19Ii
	AqUXj4TKRx//DP//7CEw12VQ/2T9iz3J9KNd7F76pBVsJ98ytp9v1P0E/WhpBOdBfkcM
	UO5r+R7gpP9lH30E9GGBGxXY0DNx7bvMGm5qaJnGqRRTMr497rerQc2l0OYtprQf35F6
	xf/n8yLxu7udfHDjG5gj6ToegOGrmOh8bztTvoqVss1PqlNL1nxQA9owOS00gfUOUgwg
	J00j0bHH45KhQzGVthb/PiHvKeaZocqwaaj/ENXqtSPGjstPW2YhD3gK+ZJkILglzygI
	UGkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=FJZvkOF8xk7UwfxXJGnNIdfkISmFuuM/zLSBaj4ZhGw=;
	b=hrr1/hCbCG7HAfl4fNEtvrsQ+ux8D7AWbPCUCsxoOsRJD2rSOwBoD/4i4rVsdvnbaa
	ymZctio3GJY7nNXrGXG1pHub8zk5Ic0mtD0zqcGzk29gEZwZ6vMnufpCQjOR5eb1dL5g
	YW3ixtf8wNEGp2pMb58J4OXWSOoIpqOmVAi/GfjjcY0OWCVIdBPXkIBkW8V2hPL3q0V6
	GTyVXmLizAqmUj0druiSARc3UhqX/2KcEs4M8yiGTXD3yHZPC16++WMC39z088UFbePC
	RZ9ASlIzbgv0iGetLokZxRDhdJ41tsTknn9+wmab7ZyJDStbVJXqe7UsM4Pb2JnyIjeC
	MU2g==
X-Gm-Message-State: AKS2vOxZe2MycpSLHzxyCRpd/eZ1+jccuwgwmhH0J9SqBovTWoTPeLan
	J1mcQnkwRA5rVO4e3pgpcw==
X-Received: by 10.98.18.16 with SMTP id a16mr32039369pfj.91.1497998932408;
	Tue, 20 Jun 2017 15:48:52 -0700 (PDT)
Received: from [192.168.42.15] (173-228-107-141.dsl.static.fusionbroadband.com.
	[173.228.107.141]) by smtp.gmail.com with ESMTPSA id
	r75sm31400685pfl.49.2017.06.20.15.48.39
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 20 Jun 2017 15:48:50 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-1672BB11-C15F-4F67-A1AE-CDB491DE2640
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (14F89)
In-Reply-To: <CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
Date: Tue, 20 Jun 2017 15:48:23 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <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>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE,
	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:48:54 -0000


--Apple-Mail-1672BB11-C15F-4F67-A1AE-CDB491DE2640
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Why do you say activation by August 1st is likely? That would require an ent=
ire difficulty adjustment period with >=3D95% bit1 signaling. That seems a t=
all order to organize in the scant few weeks remaining.=20

> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>=20
> If segwit is activated before Aug 1, as now seems likely, there will be no=
 split that day.  But if activation is via Segwit2x (also likely), and at le=
ast some nodes do & some don't follow through with the HF 3mo later (again, l=
ikely), 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 anyon=
e's guess...
>=20
>=20
>=20
> On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin-dev" <bitcoin-de=
v@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.
>=20
> Well, they're doing some kind of "pre-signaling" in the coinbase at the mo=
ment, because the segwit2x project is still in alpha-phase according to the t=
imeline. They're just showing commitment.
> I'm sure they will begin signaling on version bit 4/BIP91 as well as actua=
lly running a segwit2x node when the time comes.
>=20
>=20
> > 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.
>=20
> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or BI=
P148) node, because they wouldn't have the new consensus rule of requiring a=
ll blocks to signal for segwit.
> I don't believe there would be any long lasting chainsplit though (because=
 of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get unl=
ucky.
>=20
> Hampus
>=20
> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <bitcoin-dev@li=
sts.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 h=
ave
>> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> 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
>>=20
>> 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 tempora=
ry.
>> > 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.
>>=20
>> I think this is somewhat naive and sounds a lot like the repeat of the
>> previously debunked "XT" and "Classic" hysteria.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-1672BB11-C15F-4F67-A1AE-CDB491DE2640
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Why do you say activation by August 1s=
t is likely? That would require an entire difficulty adjustment period with &=
gt;=3D95% bit1 signaling. That seems a tall order to organize in the scant f=
ew weeks remaining.&nbsp;<br></div><div><br>On Jun 20, 2017, at 3:29 PM, Jac=
ob Eliosoff via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></d=
iv><blockquote type=3D"cite"><div><div dir=3D"auto"><div>If segwit is activa=
ted before Aug 1, as now seems likely, there will be no split that day.&nbsp=
; But if activation is via Segwit2x (also likely), and at least some nodes d=
o &amp; some don't follow through with the HF 3mo later (again, likely), agr=
eed w/ Greg that *then* we'll see a split - probably in Sep/Oct.&nbsp; How t=
hose two chains will match up and how the split will play out is anyone's gu=
ess...<div dir=3D"auto"><br></div><br><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoi=
n-dev" &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blockq=
uote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div><div><div class=3D"quoted-text">=
<div>&gt; Ironically, it looks like most of the segwit2x signaling miners ar=
e<br>&gt; faking it (because they're not signaling segwit which it requires)=
.<br>
&gt; It'll be unfortunate if some aren't faking it and start orphaning<br>
&gt; their own blocks because they are failing to signal segwit.<br><br></di=
v></div>Well, they're doing some kind of "pre-signaling" in the coinbase at t=
he moment, because the segwit2x project is still in alpha-phase according to=
 the timeline. They're just showing commitment.<br>I'm sure they will begin s=
ignaling on version bit 4/BIP91 as well as actually running a segwit2x node w=
hen the time comes.<div class=3D"quoted-text"><br><br>&gt; As far as prevent=
 a chain split goes, all those things<br>&gt; (148/91/segwit2x(per today)) e=
ffectively guarantee a chainsplit-- so I<br>&gt; don't think that holds.<br>=
<br></div></div> Segwit2x/BIP91/BIP148 will orphan miners that do not run a S=
egwit2x (or BIP148) node, because they wouldn't have the new consensus rule o=
f requiring all blocks to signal for segwit.<br></div>I don't believe there w=
ould be any long lasting chainsplit though (because of the ~80% hashrate sup=
port on segwit2x), perhaps 2-3 blocks if we get unlucky.<br><br></div>Hampus=
<br></div><div class=3D"elided-text"><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-de=
v <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</s=
pan>:<br><blockquote class=3D"gmail_quote" style=3D"margin: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"_blan=
k">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt; Because a large percentage of miners are indifferent, right now miners h=
ave<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 "segwit2x" 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're not signaling segwit which it requires).<br>
It'll be unfortunate if some aren't faking it and start orphaning<br>
their own blocks because they are failing to signal segwit.<br>
<br>
I don't think the rejection of segwit2x from Bitcoin's developers<br>
could be any more resolute than what we've already seen:<br>
<a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=3D"noreferrer" tar=
get=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 tempora=
ry.<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<br=
>
&gt; the situation as being forced to run non-reference software in order<br=
>
&gt; to prevent a chain split because a lack of support from Bitcoin Core,<b=
r>
&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 th=
e<br>
previously debunked "XT" and "Classic" hysteria.<br>
<br>
There is a reason that segwit2x is pretty much unanimously rejected by<br>
the technical community.&nbsp; And just like with XT/Classic/Unlimited<br>
you'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,&nbsp; 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't think that holds.<br>
<div class=3D"m_-187074116781290509HOEnZb"><div class=3D"m_-1870741167812905=
09h5">______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/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">bitcoin-dev@lists.<=
wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-1672BB11-C15F-4F67-A1AE-CDB491DE2640--