path: root/9a/39266b032debbb23b642abfd3de777eb49ae9d

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 81A9698A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Jun 2017 19:26:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com
	[209.85.216.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3FB8E5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Jun 2017 19:26:37 +0000 (UTC)
Received: by mail-qt0-f177.google.com with SMTP id f92so32955709qtb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Jun 2017 12:26:37 -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=Wlu538f8oZ/2rVlCh9JrNXaGtcONvU6L6DbNgxPFRPg=;
	b=cpkyn9tZGJ/EyBP+Z0myyYE8slnCZf0tW1BclAc4XMP+JqGnA7msCYbKrkxQg7VMUt
	T/hxCJOzHKazdXLbawBKXJHHXuW+O+OpoMjze/vQhHd2iWcjFjRgKTMfooI2uInk27TF
	HH7pedf+cqP11f0OHnU7L/dgA22KLa7jWFhQHimkBh0h9jTzSIzpdGDERvwf1XFO+qIf
	IautgS7pfR2fnt8kHP34kk+4KjpzmBcx2Q/In6Yel2LkshXdVnC1TUubh6/OM21zE3pN
	31033mnFBjSH1uzPVM4VBx3xLVpLdU6cnLn/nA9pJj994QxkhgJpG6YEc666EAcXC6/n
	t66A==
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=Wlu538f8oZ/2rVlCh9JrNXaGtcONvU6L6DbNgxPFRPg=;
	b=gn5RaDMb8jNofmY0mRRHwxLrvdgrsKo7IZqA3DpoaZNW6LMvcE5zLU8AoOx+6rxczd
	MZq51ylN1gFCdp7S+3F834RGrnEPpQZSg9/1fctlrt4j/5UQN/XEEG83Dmt69VPZwT6l
	EUEe1+n+3UXm6t1TiMJNkp/dXEeixk9rJ600ly6srwLWV+isyHfvp3PNXJ/Qbz9swVWS
	G3OzGi2k9kNfImnoUISYMU1VW15ofPkWBS71irvMiQ6VpmCoTQb1TGwyrMVvBepjvTsI
	a/6C46lPHnVuQPDuLI1uUp8IYUCRqlrFcvxjeaiFiSIX4gDM2W4IL14i8FKmX6/c5xgO
	LO2A==
X-Gm-Message-State: AKS2vOwLHLF/mP25ce+o9OE5Jvc0SF1lxZbAnXWvXZklWKPnlugyRN2f
	ppo5s7IuxA1zUysvegM/LeRcb5Xtfw==
X-Received: by 10.200.10.206 with SMTP id g14mr6618131qti.227.1498591596818;
	Tue, 27 Jun 2017 12:26:36 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.54.100 with HTTP; Tue, 27 Jun 2017 12:26:35 -0700 (PDT)
In-Reply-To: <CABm2gDrBOSWnqW_vZ-cibMFe8FqJmVChws-Vt7eMFzpfsx-7mQ@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>
	<CAJowKgJcp7d30LsrDZ5iR6-k9Ncz0N90pxs2GmJkuG1qYDG6GQ@mail.gmail.com>
	<CAOG=w-tPgJ5baaNiZC5rTs_y=eV7AU+F=aGaH+uObqaB-VgL2w@mail.gmail.com>
	<CAAUaCyijF1eHSffUYf9Mrv+KP5H+NLBcy5MEhMUyT6Rxcbx93g@mail.gmail.com>
	<CAKzdR-rvP9RLJ=qGDMVyOT3WVqp7q2tUPpzbaQZ=wStsFSCbWA@mail.gmail.com>
	<CABm2gDrBOSWnqW_vZ-cibMFe8FqJmVChws-Vt7eMFzpfsx-7mQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 27 Jun 2017 15:26:35 -0400
X-Google-Sender-Auth: qKfPnwp5avJBBOt1v8DqlSSD29E
Message-ID: <CAJowKg+6b5JFgNuFXL0hurPUt15AA3+AGwyFawZQBhgeZAOJDg@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary="089e08229304cab78d0552f60b40"
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no 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, 27 Jun 2017 19:36:55 +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, 27 Jun 2017 19:26:39 -0000

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

There's a pull req to core already for part of it:

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




On Tue, Jun 27, 2017 at 12:31 PM, Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> First the implementation, then the technical design (BIP)... will the
> analysis come after that?
> Will there be any kind of simulations of tje proposed size or will thag
> come only after activation on mainnet?
> I assume the very last step will be activation on testnet 3 ?
>
>
> On 27 Jun 2017 8:44 am, "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Currently the only implementation that fulfills the requirements of the
> NYA agreement is the segwit2x/btc1 implementation, which is being finaliz=
ed
> this week.
>
> Segwit2mb does not fulfill the NYA agreement.
>
> I'm asking now the segwit2x development team when a BIP will be ready so
> that Core has the opportunity to evaluate the technical proposal.
>
>
>
>
> On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Well, this Saturday's "Chinese roundtable" statement from a bunch of
>> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
>> coinbase as support for "the New York consensus SegWit2x program btc1 (
>> https://github.com/btc1)", whose code includes the (accelerated
>> 336-block) BIP 91 change.  So, other facts or interpretations could come=
 to
>> light, but until they do we should probably assume that's what the "NYA"
>> (which just broke 80% over the last 24h) means.
>>
>>
>> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark@friedenbach.org=
>
>> wrote:
>>
>>> 80% have set "NYA" in their coinbase string. We have no idea what that
>>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
>>> the time of the New York agreement, and differs from the actual text
>>> of the NYA in substantive ways. The "Segwit2MB" that existed at the
>>> time of the NYA, and which was explicitly referenced by the text is
>>> the proposal by Sergio Demian Lerner that was made to this mailing
>>> list on 31 March. The text of the NYA grants no authority for
>>> upgrading this proposal while remaining compliant with the agreement.
>>> This is without even considering the fact that in the days after the
>>> NYA there was disagreement among those who signed it as to what it
>>> meant.
>>>
>>> I feel it is a very dangerous and unwarranted assumption people are
>>> making that what we are seeing now is either 80% support for BIP-91 or
>>> for the code in the btc1 repo.
>>>
>>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik@q32.com> wrote:
>>> > # 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 whi=
ch
>>> > 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 insta=
ll
>>> > 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 has
>>> >> 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 Au=
g
>>> 1,
>>> >> because they're mined by old BIP141 nodes.  But it seems like very f=
ew
>>> >> 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. Th=
at
>>> seems 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 wil=
l
>>> 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 lat=
er
>>> >>> (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 a=
re
>>> >>> > 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 a=
s
>>> >>> 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 th=
em
>>> >>>> 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 t=
he
>>> >>>> story would be the same there in the near term).
>>> >>>>
>>> >>>> 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.
>>> >>>>
>>> >>>> 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
>>> temporary.
>>> >>>> > 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 rejecte=
d
>>> 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 acceptabl=
e
>>> >>>> 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 g=
o
>>> >>>> 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
>>> >>
>>> >
>>>
>>
>>
>> _______________________________________________
>> 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
>
>

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

<div dir=3D"ltr">There&#39;s a pull req to core already for part of it:<br>=
<br><a href=3D"https://github.com/bitcoin/bitcoin/pull/10444">https://githu=
b.com/bitcoin/bitcoin/pull/10444</a><br><br><br><br></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Tue, Jun 27, 2017 at 12:31 PM, =
Jorge Tim=C3=B3n via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.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>First the implementation, then the technical design (=
BIP)... will the analysis come after that?</div><div dir=3D"auto">Will ther=
e be any kind of simulations of tje proposed size or will thag come only af=
ter activation on mainnet?</div><div dir=3D"auto">I assume the very last st=
ep will be activation on testnet 3 ?<div><div class=3D"h5"><br><div class=
=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On 27 Jun 2017=
 8:44 am, &quot;Sergio Demian Lerner via bitcoin-dev&quot; &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><bloc=
kquote class=3D"m_-8028952536435113512quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Currently the on=
ly implementation that fulfills the requirements of the NYA agreement is th=
e segwit2x/btc1 implementation, which is being finalized this week.=C2=A0<d=
iv><br></div><div>Segwit2mb does not fulfill the NYA agreement.=C2=A0<div><=
br></div><div>I&#39;m asking now the segwit2x development team when a BIP w=
ill be ready so that Core has the opportunity to evaluate the technical pro=
posal.=C2=A0</div><div><br></div><div><br><div><div><br></div></div></div><=
/div></div><div class=3D"m_-8028952536435113512elided-text"><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 21, 2017 at 1:05 AM,=
 Jacob Eliosoff via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfounda<wbr>tion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">Well, this Saturday&#39;s &quot;Chinese roundtable&quot=
; statement from a bunch of miners=C2=A0(<a href=3D"https://pastebin.com/b3=
St9VCF" target=3D"_blank">https://pastebin.com/b<wbr>3St9VCF</a>) says they=
 intend &quot;NYA&quot; in the coinbase as support for &quot;the New York c=
onsensus SegWit2x program btc1 (<a href=3D"https://github.com/btc1" target=
=3D"_blank">https://github.com/btc1</a>)&quot;, whose code includes the (ac=
celerated 336-block) BIP 91 change.=C2=A0 So, other facts or interpretation=
s could come to light, but until they do we should probably assume that&#39=
;s what the &quot;NYA&quot; (which just broke 80% over the last 24h) means.=
<div><br></div></div><div class=3D"m_-8028952536435113512m_-643690647297027=
7404HOEnZb"><div class=3D"m_-8028952536435113512m_-6436906472970277404h5"><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 20=
17 at 10:11 PM, Mark Friedenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:ma=
rk@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">80% have set &quot;NYA&quot; in the=
ir coinbase string. We have no idea what that<br>
means. People are equating it to BIP 91 -- but BIP 91 did not exist at<br>
the time of the New York agreement, and differs from the actual text<br>
of the NYA in substantive ways. The &quot;Segwit2MB&quot; that existed at t=
he<br>
time of the NYA, and which was explicitly referenced by the text is<br>
the proposal by Sergio Demian Lerner that was made to this mailing<br>
list on 31 March. The text of the NYA grants no authority for<br>
upgrading this proposal while remaining compliant with the agreement.<br>
This is without even considering the fact that in the days after the<br>
NYA there was disagreement among those who signed it as to what it<br>
meant.<br>
<br>
I feel it is a very dangerous and unwarranted assumption people are<br>
making that what we are seeing now is either 80% support for BIP-91 or<br>
for the code in the btc1 repo.<br>
<div class=3D"m_-8028952536435113512m_-6436906472970277404m_736866044118352=
0488HOEnZb"><div class=3D"m_-8028952536435113512m_-6436906472970277404m_736=
8660441183520488h5"><br>
On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty &lt;<a href=3D"mailto:erik@q=
32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<br>
&gt; # Jacob Eliosoff:<br>
&gt;<br>
&gt;&gt;=C2=A0 will start orphaning non-bit-1 blocks before Aug 1, and we a=
void a split.<br>
&gt;<br>
&gt; Correct.=C2=A0 There are 2 short activation periods in BIP91 either of=
 which<br>
&gt; would avoid a split.<br>
&gt;<br>
&gt; # Gregory Maxwell:<br>
&gt;<br>
&gt;&gt; unclear to me _exactly_ what it would need to implement to be cons=
istent.<br>
&gt;<br>
&gt; This is the relevant pull req to core:<br>
&gt;<br>
&gt; <a href=3D"https://github.com/bitcoin/bitcoin/pull/10444" rel=3D"noref=
errer" target=3D"_blank">https://github.com/bitcoin/bit<wbr>coin/pull/10444=
</a><br>
&gt;<br>
&gt; Seems OK.=C2=A0 It&#39;s technically running now on testnet5.=C2=A0 =
=C2=A0I think it (or a<br>
&gt; -bip148 option) should be merged as soon as feasible.<br>
&gt;<br>
&gt;&gt; previously debunked &quot;XT&quot; and &quot;Classic&quot; hysteri=
a.<br>
&gt;<br>
&gt; apples vs oranges, imo.=C2=A0 =C2=A0segwit is not a contentious featur=
e.=C2=A0 =C2=A0the<br>
&gt; &quot;bundling&quot; in segwit2x is, but that&#39;s not the issue here=
.=C2=A0 =C2=A0the issue is we<br>
&gt; are indirectly requiring miners that strongly support segwit to instal=
l<br>
&gt; consensus protocol changes outside of bitcoin&#39;s standard reference=
.=C2=A0 =C2=A080% of<br>
&gt; them have signaled they will do so.=C2=A0 =C2=A0these are uncharted wa=
ters.<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev<br>
&gt; &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;&gt;<br>
&gt;&gt; I could be wrong, but the latest BIP91 implementation (also includ=
ed in<br>
&gt;&gt; Segwit2x) cuts the activation period to 336 blocks (2.33 days).=C2=
=A0 (This has<br>
&gt;&gt; been updated at<br>
&gt;&gt; <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0091.me=
diawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bi=
p<wbr>s/blob/master/bip-0091.mediawi<wbr>ki</a>.)=C2=A0 So if 80%<br>
&gt;&gt; of hashpower is actually running that code and signaling on bit 4 =
by July 25<br>
&gt;&gt; or so, then those 80+% will start orphaning non-bit-1 blocks befor=
e Aug 1,<br>
&gt;&gt; and we avoid a split.<br>
&gt;&gt;<br>
&gt;&gt; There may still be a few non-bit-1 blocks that get orphaned after =
Aug 1,<br>
&gt;&gt; because they&#39;re mined by old BIP141 nodes.=C2=A0 But it seems =
like very few<br>
&gt;&gt; miners won&#39;t be signaling either Segwit2x *or* BIP141 by then.=
..<br>
&gt;&gt;<br>
&gt;&gt; Make sense?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach &lt;<a href=3D"m=
ailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>&gt;<=
br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Why do you say activation by August 1st is likely? That would =
require an<br>
&gt;&gt;&gt; entire difficulty adjustment period with &gt;=3D95% bit1 signa=
ling. That seems a<br>
&gt;&gt;&gt; tall order to organize in the scant few weeks remaining.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev<br=
>
&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If segwit is activated before Aug 1, as now seems likely, ther=
e will be<br>
&gt;&gt;&gt; no split that day.=C2=A0 But if activation is via Segwit2x (al=
so likely), and at<br>
&gt;&gt;&gt; least some nodes do &amp; some don&#39;t follow through with t=
he HF 3mo later<br>
&gt;&gt;&gt; (again, likely), agreed w/ Greg that *then* we&#39;ll see a sp=
lit - probably in<br>
&gt;&gt;&gt; Sep/Oct.=C2=A0 How those two chains will match up and how the =
split will play out<br>
&gt;&gt;&gt; is anyone&#39;s guess...<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Jun 20, 2017 6:16 PM, &quot;Hampus Sj=C3=B6berg via bitcoin=
-dev&quot;<br>
&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; Ironically, it looks like most of the segwit2x signaling =
miners are<br>
&gt;&gt;&gt; &gt; faking it (because they&#39;re not signaling segwit which=
 it requires).<br>
&gt;&gt;&gt; &gt; It&#39;ll be unfortunate if some aren&#39;t faking it and=
 start orphaning<br>
&gt;&gt;&gt; &gt; their own blocks because they are failing to signal segwi=
t.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Well, they&#39;re doing some kind of &quot;pre-signaling&quot;=
 in the coinbase at the<br>
&gt;&gt;&gt; moment, because the segwit2x project is still in alpha-phase a=
ccording to<br>
&gt;&gt;&gt; the timeline. They&#39;re just showing commitment.<br>
&gt;&gt;&gt; I&#39;m sure they will begin signaling on version bit 4/BIP91 =
as well as<br>
&gt;&gt;&gt; actually running a segwit2x node when the time comes.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; As far as prevent a chain split goes, all those things<br=
>
&gt;&gt;&gt; &gt; (148/91/segwit2x(per today)) effectively guarantee a chai=
nsplit-- so I<br>
&gt;&gt;&gt; &gt; don&#39;t think that holds.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Segwit2x/BIP91/BIP148 will orphan miners that do not run a Seg=
wit2x (or<br>
&gt;&gt;&gt; BIP148) node, because they wouldn&#39;t have the new consensus=
 rule of requiring<br>
&gt;&gt;&gt; all blocks to signal for segwit.<br>
&gt;&gt;&gt; I don&#39;t believe there would be any long lasting chainsplit=
 though<br>
&gt;&gt;&gt; (because of the ~80% hashrate support on segwit2x), perhaps 2-=
3 blocks if we<br>
&gt;&gt;&gt; get unlucky.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hampus<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev<br>
&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin=
-dev<br>
&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wro=
te:<br>
&gt;&gt;&gt;&gt; &gt; Because a large percentage of miners are indifferent,=
 right now miners<br>
&gt;&gt;&gt;&gt; &gt; have<br>
&gt;&gt;&gt;&gt; &gt; to choose between BIP148 and Segwit2x if they want to=
 activate Segwit.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Miners can simply continuing signaling segwit, which will =
leave them<br>
&gt;&gt;&gt;&gt; at least soft-fork compatible with BIP148 and BIP91 (and g=
od knows<br>
&gt;&gt;&gt;&gt; what &quot;segwit2x&quot; is since they keep changing the =
actual definition and<br>
&gt;&gt;&gt;&gt; do not have a specification; but last I saw the near-term =
behavior the<br>
&gt;&gt;&gt;&gt; same as BIP91 but with a radically reduced activation wind=
ow, so the<br>
&gt;&gt;&gt;&gt; story would be the same there in the near term).<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Ironically, it looks like most of the segwit2x signaling m=
iners are<br>
&gt;&gt;&gt;&gt; faking it (because they&#39;re not signaling segwit which =
it requires).<br>
&gt;&gt;&gt;&gt; It&#39;ll be unfortunate if some aren&#39;t faking it and =
start orphaning<br>
&gt;&gt;&gt;&gt; their own blocks because they are failing to signal segwit=
.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I don&#39;t think the rejection of segwit2x from Bitcoin&#=
39;s developers<br>
&gt;&gt;&gt;&gt; could be any more resolute than what we&#39;ve already see=
n:<br>
&gt;&gt;&gt;&gt; <a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=
=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/Seg<wbr>wit_su=
pport</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitc=
oin-dev<br>
&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wro=
te:<br>
&gt;&gt;&gt;&gt; &gt; I think it is very na=C3=AFve to assume that any shif=
t would be temporary.<br>
&gt;&gt;&gt;&gt; &gt; We have a hard enough time getting miners to proactiv=
ely upgrade to<br>
&gt;&gt;&gt;&gt; &gt; recent versions of the reference bitcoin daemon. If m=
iners interpret<br>
&gt;&gt;&gt;&gt; &gt; the situation as being forced to run non-reference so=
ftware in order<br>
&gt;&gt;&gt;&gt; &gt; to prevent a chain split because a lack of support fr=
om Bitcoin Core,<br>
&gt;&gt;&gt;&gt; &gt; that could be a one-way street.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I think this is somewhat naive and sounds a lot like the r=
epeat of the<br>
&gt;&gt;&gt;&gt; previously debunked &quot;XT&quot; and &quot;Classic&quot;=
 hysteria.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; There is a reason that segwit2x is pretty much unanimously=
 rejected by<br>
&gt;&gt;&gt;&gt; the technical community.=C2=A0 And just like with XT/Class=
ic/Unlimited<br>
&gt;&gt;&gt;&gt; you&#39;ll continue to see a strong correlation with peopl=
e who are<br>
&gt;&gt;&gt;&gt; unwilling and unable to keep updating the software at an a=
cceptable<br>
&gt;&gt;&gt;&gt; level of quality-- esp. because the very founding on their=
 fork is<br>
&gt;&gt;&gt;&gt; predicated on discarding those properties.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; If miners want to go off and create an altcoin-- welp, tha=
ts something<br>
&gt;&gt;&gt;&gt; they can always do,=C2=A0 and nothing about that will forc=
e anyone to go<br>
&gt;&gt;&gt;&gt; along with it.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; As far as prevent a chain split goes, all those things<br>
&gt;&gt;&gt;&gt; (148/91/segwit2x(per today)) effectively guarantee a chain=
split-- so I<br>
&gt;&gt;&gt;&gt; don&#39;t think that holds.<br>
&gt;&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>
</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><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></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>

--089e08229304cab78d0552f60b40--