path: root/35/fa1a839bece998d57e709c9a4a86da93c017df

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 8FCE1891
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 22:29:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com
	[209.85.215.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1CC3323D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 22:29:30 +0000 (UTC)
Received: by mail-lf0-f50.google.com with SMTP id h22so3682895lfk.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 15:29:29 -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=8BKo8rNroDPEQFno6LI+2/QWiL6QIE6g9fI0QBSWFdA=;
	b=Y/7M6LJhDyz4eiuInFBYwExSZzpFG6fAb9hBwgQ7R1hUwzO9/MOBWCqEnucBvjN1IX
	gVGghwwUUhYM/eYtHWEVkpUFg8cftwoB+8mca7iqEPpjbRxG7ke0mWbSZzVmO4Qknlq5
	MFmmiS3MHB1HNAzzwk7tG4L13h2O/RhIpqOItFy0hl/dsotZA++KNjKGdoL6LiU37DWL
	QVbJVpNjOmurhyKeaPrLJUnRs+Xh7aiBH1AL2ZV6f9+k7n20RAfgIuuUG62z4KHtpdBq
	h7FP1arqfdWZ+RcSs9DQDAohe9OS1xJo7FYeMN0BVYjayb01pFCKtNzbrk6q0wvfubqF
	EnBA==
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=8BKo8rNroDPEQFno6LI+2/QWiL6QIE6g9fI0QBSWFdA=;
	b=evEg3kSFHE1ZoUJXFew8XBUZjMQBYP+GkgGXfTgc9k4YAWwWIYQEHXiVbhKJ0LjJZ2
	+eJs+o4bXjm8D7LY3xukAhhmFW0XI9kRriOeF44Jza0S9XKdif9U0p07JQPbXSME7K0L
	i4zPnjvslLOCx+RyqXYxRHPoT4Om5kFdcs/jyfiJ8bOCxZtJ6Iamqcv2dBX9ZouOdkOS
	9f/uUEY+575twZGea2CodVuDowRFnDmGOPd1aOqOtq1zfSYnF1xrZgwZabd/ib6Cpg/r
	IEpaoNyF/KeLBLusvNpb0pLWwCqronneBamKDOUZOnpDezqMRCCoRZxqFlEu78jVyNd8
	3uNQ==
X-Gm-Message-State: AKS2vOyJojfP7uY4P3nn3zghpiKi5ZGw/IlqgdMwnmmi+9UotKKJhFUz
	838AQuP4mztSW28A4qbnLzmGm9mz6w==
X-Received: by 10.25.67.21 with SMTP id q21mr9116139lfa.125.1497997768490;
	Tue, 20 Jun 2017 15:29:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 15:29:27 -0700 (PDT)
Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 15:29:27 -0700 (PDT)
In-Reply-To: <CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
	<CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
	<CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Tue, 20 Jun 2017 18:29:27 -0400
Message-ID: <CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
To: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Content-Type: multipart/alternative; boundary="f403045e9de2dd852905526bc8e3"
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: Tue, 20 Jun 2017 22:31:28 +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:29:31 -0000

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

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
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 (because
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 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.
>
> 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

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

<div dir=3D"auto"><div>If segwit is activated before Aug 1, as now seems li=
kely, there will be no split that day.=C2=A0 But if activation is via Segwi=
t2x (also likely), and at least some nodes do &amp; some don&#39;t follow t=
hrough with the HF 3mo later (again, likely), 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 out is anyone&#39;s guess...<div dir=
=3D"auto"><br></div><br><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Jun 20, 2017 6:16 PM, &quot;Hampus Sj=C3=B6berg via bitcoin-dev&q=
uot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@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;=
padding-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=
 are<br>&gt; faking it (because they&#39;re not signaling segwit which it r=
equires).<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"quoted-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> Segwit2x/BIP91/BIP148=
 will orphan miners that do not run a Segwit2x (or BIP148) node, because th=
ey wouldn&#39;t have the new consensus rule of requiring all blocks to sign=
al for segwit.<br></div>I don&#39;t believe there would be any long lasting=
 chainsplit though (because of the ~80% hashrate support on segwit2x), perh=
aps 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 class=3D"gmail_quote">=
2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span>:<br><blockq=
uote 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 Aronest=
y 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_-187074116781290509HOEnZb"><div class=3D"m_-187074116781290=
509h5">______________________________<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">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></div></div>

--f403045e9de2dd852905526bc8e3--