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

[Jacob Eliosoff <jacob.eliosoff@gmail.com>]

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

(That is: "...because they're mined by old non-Segwit2x nodes that *aren't
signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit)


On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff <jacob.eliosoff@gmail.com>
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
>>
>>
>

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