Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 21F41AA6 for ; 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 ; Tue, 20 Jun 2017 22:48:53 +0000 (UTC) Received: by mail-pg0-f47.google.com with SMTP id e187so16454366pgc.1 for ; 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 X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 20 Jun 2017 15:48:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Jacob Eliosoff 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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" 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 : >> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev >> 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 >> 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
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. 

On Jun 20, 2017, at 3:29 PM, Jac= ob Eliosoff via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

If segwit is activa= ted 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 d= o & 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.  How t= hose two chains will match up and how the split will play out is anyone's gu= ess...



On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoi= n-dev" <bitcoin-= dev@lists.linuxfoundation.org> wrote:
=
> Ironically, it looks like most of the segwit2x signaling miners ar= e
> 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 t= he 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 s= ignaling on version bit 4/BIP91 as well as actually running a segwit2x node w= hen the time comes.


> As far as prevent= a chain split goes, all those things
> (148/91/segwit2x(per today)) e= ffectively guarantee a chainsplit-- so I
> don't think that holds.
=
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.
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.

Hampus=

2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-de= v <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 h= ave
> to choose between BIP148 and Segwit2x if they want to activate Segwit.<= br>
Miners can simply continuing signaling segwit, which will leave them<= br> 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 th= e
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
b= itcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev


____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-1672BB11-C15F-4F67-A1AE-CDB491DE2640--