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

[Erik Aronesty <erik@q32.com>]

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

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ón 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 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
>>
>>
>
> _______________________________________________
> 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: 17716 bytes --]