path: root/09/7fb7fd12ce023bfbe52dba7ba52fa81f06d9f0

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F661891
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 21 Jun 2017 01:36:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
	[209.85.220.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 73A8410A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 21 Jun 2017 01:36:51 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id g83so71530120qkb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 18:36:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=+ljytzOU/NIaxHN6HXqBOElj+xTpAtRms+Hhhe9BjEE=;
	b=QYOY7s4SQi1wPIPj08oNXduWAC40hi//hL0nHhmxElguE1r3xzjjW2xn2c/qXRbuF4
	NEsgL7hIdOLdUsFe0aoLy8lKE+WhCLt6ixxh9JpcFSLH1JSxuYKgZnZDGAlEj0y9RXaf
	xR6sMWCsvuX/5ht3XH85zsYUnH4rn2WZ5Vjg8ycBPKm5qevajyTEZSAegsCxlorOfeNT
	KMhkea5cF2OQFGg2YOKIakJHXP2nqaQ5c6OcBd5fRrljcr+Ix/80X28YOnpXwoXIMC+R
	o3/HirE2Jw5mNaB13l615CsIl+TGwgDiYhTzR/UaOOQXgJomNxWI9krKT/O1Dfh2JzHN
	Tsmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=+ljytzOU/NIaxHN6HXqBOElj+xTpAtRms+Hhhe9BjEE=;
	b=NuI1j7Kn9FzR5b2kKVeeKX4eLGYbNYJviKifYf48bqc9kx2yf0vABrXNyIz5KENXgx
	4h8WiQbcFMidCgJAZPkBT4CrpAKSpuWdAM5+uoV9PwWtaHDWsS2wT6vPew8hLFO2cTal
	Y7t5mU1m4JqivaetsOhRoNUvZEqtYrGakqH5I1u+EiG9MptG12ThsF/mCq827MkEhuCj
	5ri9x/rC/ggdzsRJWCqhy2MFfO9CF7FELSWcR0U+RoFXCdEFYDbSlsPx7rawoQQISrXe
	Hg9kTLi13JJKvuFoMtKScajeGIydkD/TOMPi1B2VzIvXtldD3mSEtLjqePYr0/0XcoNJ
	Y8Ng==
X-Gm-Message-State: AKS2vOxLaFP5rCQAPG4v8E/I62k5mP4abRCvBfXNyxK5F4pEnQb8fN+9
	xUIeZd2dAOJm5OhXGkfYCuuL+tWFdA==
X-Received: by 10.55.75.71 with SMTP id y68mr730772qka.247.1498009010545; Tue,
	20 Jun 2017 18:36:50 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.54.100 with HTTP; Tue, 20 Jun 2017 18:36:49 -0700 (PDT)
In-Reply-To: <CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@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>
	<CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
	<BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org>
	<CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 20 Jun 2017 21:36:49 -0400
X-Google-Sender-Auth: jDTKXuISHz_NHzrj1BMvrUCUWnU
Message-ID: <CAJowKgJcp7d30LsrDZ5iR6-k9Ncz0N90pxs2GmJkuG1qYDG6GQ@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Content-Type: multipart/alternative; boundary="001a114a9c74f1adb805526e6601"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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:39:39 +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: Wed, 21 Jun 2017 01:36:53 -0000

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

# Jacob Eliosoff:

>  will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
split.

Correct.  There are 2 short activation periods in BIP91 either of which
would avoid a split.

# Gregory Maxwell:

> unclear to me _exactly_ what it would need to implement to be consistent.

This is the relevant pull req to core:

https://github.com/bitcoin/bitcoin/pull/10444

Seems OK.  It's technically running now on testnet5.   I think it (or a
-bip148 option) should be merged as soon as feasible.

> previously debunked "XT" and "Classic" hysteria.

apples vs oranges, imo.   segwit is not a contentious feature.   the
"bundling" in segwit2x is, but that's not the issue here.   the issue is we
are indirectly requiring miners that strongly support segwit to install
consensus protocol changes outside of bitcoin's standard reference.   80%
of them have signaled they will do so.   these are uncharted waters.


On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I could be wrong, but the latest BIP91 implementation (also included in
> Segwit2x) cuts the activation period to 336 blocks (2.33 days).  (This ha=
s
> 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 se=
ems 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
>> 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 t=
o
>> 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 i=
f
>> 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 miner=
s
>>> 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 tempo=
rary.
>>> > 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
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><span style=3D"font-size:12.8px">#=C2=A0</span>Jacob Elios=
off:<br><br><div>&gt; =C2=A0<span style=3D"font-size:12.8px">will start orp=
haning non-bit-1 blocks before=C2=A0</span><span class=3D"gmail-aBn" tabind=
ex=3D"0" style=3D"font-size:12.8px"><span class=3D"gmail-aQJ">Aug 1</span><=
/span><span style=3D"font-size:12.8px">, and we avoid a split. =C2=A0<br><b=
r>Correct.=C2=A0 There are 2 short activation periods in BIP91 either of wh=
ich would avoid a split.<br><br># Gregory Maxwell:</span><div><span style=
=3D"font-size:12.8px"><br></span><div><span style=3D"font-size:12.8px">&gt;=
 unclear to me=C2=A0</span><span style=3D"font-size:12.8px">_exactly_ what =
it would need to implement to be consistent.</span><div><span style=3D"font=
-size:12.8px"></span><span style=3D"font-size:12.8px"><br>This is the relev=
ant pull req to core:</span><br><br><a href=3D"https://github.com/bitcoin/b=
itcoin/pull/10444">https://github.com/bitcoin/bitcoin/pull/10444</a><br><br=
>Seems OK.=C2=A0 It&#39;s technically running now on testnet5. =C2=A0 I thi=
nk it (or a -bip148 option) should be merged as soon as feasible.</div><div=
><br><span style=3D"font-size:12.8px">&gt; previously debunked &quot;XT&quo=
t; and &quot;Classic&quot; hysteria.</span><br><br>apples vs oranges, imo. =
=C2=A0 segwit is not a contentious feature. =C2=A0 the &quot;bundling&quot;=
 in segwit2x is, but that&#39;s not the issue here. =C2=A0 the issue is we =
are indirectly requiring miners that strongly support segwit to install con=
sensus protocol changes outside of bitcoin&#39;s standard reference. =C2=A0=
 80% of them have signaled they will do so. =C2=A0 these are uncharted wate=
rs.<div><div><br></div></div></div></div></div></div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 2017 at 6:57 PM, =
Jacob Eliosoff via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">I could be wrong, but the latest BIP91 implementation (also i=
ncluded 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/bips/=
blob/master/bip-0091.mediawiki" target=3D"_blank">https://github.com/bitcoi=
n/<wbr>bips/blob/master/bip-0091.<wbr>mediawiki</a>.) =C2=A0So if 80% of ha=
shpower 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.<div><br></div><div>There may still be a few non-bit-1 bl=
ocks that get orphaned after Aug 1, because they&#39;re mined by old BIP141=
 nodes.=C2=A0 But it seems like very few miners won&#39;t be signaling eith=
er Segwit2x *or* BIP141 by then...</div><div><br></div><div>Make sense?</di=
v><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 2017 at 6:4=
8 PM, Mark Friedenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@frieden=
bach.org" target=3D"_blank">mark@friedenbach.org</a>&gt;</span> wrote:<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 activat=
ion by August 1st is likely? That would require an entire difficulty adjust=
ment period with &gt;=3D95% bit1 signaling. That seems a tall order to orga=
nize in the scant few weeks remaining.=C2=A0<br></div><div><div class=3D"m_=
-8199073833958022840h5"><div><br>On Jun 20, 2017, at 3:29 PM, Jacob Eliosof=
f via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wr=
ote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"auto"><div>If =
segwit is activated before Aug 1, as now seems likely, there will be no spl=
it that day.=C2=A0 But if activation is via Segwit2x (also likely), and at =
least some nodes do &amp; some don&#39;t follow through with the HF 3mo lat=
er (again, likely), agreed w/ Greg that *then* we&#39;ll see a split - prob=
ably 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&quot; &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfounda<wbr>tion.org</a>&gt; wrote:<br type=3D"attribution"><blockquote =
class=3D"m_-8199073833958022840m_651225331209638612quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div><div><div class=3D"m_-8199073833958022840m_651225331209638612quoted-=
text"><div>&gt; Ironically, it looks like most of the segwit2x signaling mi=
ners are<br>&gt; faking it (because they&#39;re not signaling 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_-819907383=
3958022840m_651225331209638612quoted-text"><br><br>&gt; As far as prevent a=
 chain split goes, all those things<br>&gt; (148/91/segwit2x(per today)) ef=
fectively 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 r=
un a Segwit2x (or BIP148) node, because they wouldn&#39;t have the new cons=
ensus rule of requiring all blocks to signal for segwit.<br></div>I don&#39=
;t believe there would be any long lasting chainsplit though (because of th=
e ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get unlucky.=
<br><br></div>Hampus<br></div><div class=3D"m_-8199073833958022840m_6512253=
31209638612elided-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" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span>:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #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_-8199073833958022840m_651225331209638612m_-1870741167812905=
09HOEnZb"><div class=3D"m_-8199073833958022840m_651225331209638612m_-187074=
116781290509h5">______________________________<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.linuxfoundat<wbr>ion.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-d<wbr>ev</a></span><br></div></blockquote></div></div></div></bl=
ockquote></div><br></div>
</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>

--001a114a9c74f1adb805526e6601--