Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated

From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: Jacob Eliosoff <jacob.eliosoff@gmail•com>
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
Date: Tue, 27 Jun 2017 12:42:53 -0300	[thread overview]
Message-ID: <CAKzdR-rvP9RLJ=qGDMVyOT3WVqp7q2tUPpzbaQZ=wStsFSCbWA@mail.gmail.com> (raw)
In-Reply-To: <CAAUaCyijF1eHSffUYf9Mrv+KP5H+NLBcy5MEhMUyT6Rxcbx93g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 10528 bytes --]

Currently the only implementation that fulfills the requirements of the NYA
agreement is the segwit2x/btc1 implementation, which is being finalized
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 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
>> 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 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 >=95% bit1 signaling. That
>> 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 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öberg 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ïve 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 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
>> >>
>> >
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 15238 bytes --]