MIME-Version: 1.0
In-Reply-To: <CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
	<CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Wed, 21 Jun 2017 00:15:59 +0200
Message-ID: <CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="94eb2c12526abbaf1605526b98a5"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to
 get segwit activated
Precedence: list

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

> 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
>

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

<div dir=3D"ltr"><div><div><div><div>&gt; Ironically, it looks like most of=
 the segwit2x signaling miners are<br>&gt; faking it (because they&#39;re n=
ot 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>Well, they&#39;re doing some kind of &quot;pre-signaling&quot; in the co=
inbase 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 actually r=
unning a segwit2x node when the time comes.<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> Segwit2x/BIP91/BIP148 will orphan miners that do not run a S=
egwit2x (or BIP148) node, because they wouldn&#39;t have the new consensus =
rule of requiring all blocks to signal for segwit.<br></div>I don&#39;t bel=
ieve there would be any long lasting chainsplit though (because of the ~80%=
 hashrate support on segwit2x), perhaps 2-3 blocks if we get unlucky.<br><b=
r></div>Hampus<br></div><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.linuxfoundation.org</a>&gt;</span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><span class=3D"">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">bitcoin-dev@li=
sts.<wbr>linuxfoundation.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/<wbr>Segwit_support</a><br>
<br>
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev<br>
<span class=3D"">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.<wbr>linuxfoundation.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"HOEnZb"><div class=3D"h5">______________________________<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>
</div></div></blockquote></div><br></div>

--94eb2c12526abbaf1605526b98a5--