📅 Original date posted:2017-06-20
📝 Original message:(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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org>:
>>
>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>>> <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170620/ee28dc3b/attachment.html>;
Jacob Eliosoff [ARCHIVE] /
npub1ml…4yf8d
2023-06-07 18:03:28
in reply to nevent1q…wumg
Author Public Key
npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8dPublished at
2023-06-07 18:03:28Event JSON
{
"id": "1f46578cd5b0c88eacffbdc451e904182cfa3d0ae7ab8c21c9e6e4de2cc22b56",
"pubkey": "dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b",
"created_at": 1686161008,
"kind": 1,
"tags": [
[
"e",
"f10d3c1837e5518719736f82b51f13e32ba605e8e3996b8db87dad10332b09a3",
"",
"root"
],
[
"e",
"548da324d41fcdcc18ac3d77668fd8a147daae69beacc759ea40539fa1100729",
"",
"reply"
],
[
"p",
"dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b"
]
],
"content": "📅 Original date posted:2017-06-20\n📝 Original message:(That is: \"...because they're mined by old non-Segwit2x nodes that *aren't\nsignaling bit 1 support*\", ie, that support neither Segwit2x nor old segwit)\n\n\nOn Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff \u003cjacob.eliosoff at gmail.com\u003e\nwrote:\n\n\u003e I could be wrong, but the latest BIP91 implementation (also included in\n\u003e Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This has\n\u003e been updated at https://github.com/bitcoin/bips/blob/master/bip-0091.\n\u003e mediawiki.) So if 80% of hashpower is actually running that code and\n\u003e signaling on bit 4 by July 25 or so, then those 80+% will start orphaning\n\u003e non-bit-1 blocks before Aug 1, and we avoid a split.\n\u003e\n\u003e There may still be a few non-bit-1 blocks that get orphaned after Aug 1,\n\u003e because they're mined by old BIP141 nodes. But it seems like very few\n\u003e miners won't be signaling either Segwit2x *or* BIP141 by then...\n\u003e\n\u003e Make sense?\n\u003e\n\u003e\n\u003e On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Why do you say activation by August 1st is likely? That would require an\n\u003e\u003e entire difficulty adjustment period with \u003e=95% bit1 signaling. That seems a\n\u003e\u003e tall order to organize in the scant few weeks remaining.\n\u003e\u003e\n\u003e\u003e On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e If segwit is activated before Aug 1, as now seems likely, there will be\n\u003e\u003e no split that day. But if activation is via Segwit2x (also likely), and at\n\u003e\u003e least some nodes do \u0026 some don't follow through with the HF 3mo later\n\u003e\u003e (again, likely), agreed w/ Greg that *then* we'll see a split - probably in\n\u003e\u003e Sep/Oct. How those two chains will match up and how the split will play\n\u003e\u003e out is anyone's guess...\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Jun 20, 2017 6:16 PM, \"Hampus Sjöberg via bitcoin-dev\" \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e \u003e Ironically, it looks like most of the segwit2x signaling miners are\n\u003e\u003e \u003e faking it (because they're not signaling segwit which it requires).\n\u003e\u003e \u003e It'll be unfortunate if some aren't faking it and start orphaning\n\u003e\u003e \u003e their own blocks because they are failing to signal segwit.\n\u003e\u003e\n\u003e\u003e Well, they're doing some kind of \"pre-signaling\" in the coinbase at the\n\u003e\u003e moment, because the segwit2x project is still in alpha-phase according to\n\u003e\u003e the timeline. They're just showing commitment.\n\u003e\u003e I'm sure they will begin signaling on version bit 4/BIP91 as well as\n\u003e\u003e actually running a segwit2x node when the time comes.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e As far as prevent a chain split goes, all those things\n\u003e\u003e \u003e (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I\n\u003e\u003e \u003e don't think that holds.\n\u003e\u003e\n\u003e\u003e Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or\n\u003e\u003e BIP148) node, because they wouldn't have the new consensus rule of\n\u003e\u003e requiring all blocks to signal for segwit.\n\u003e\u003e I don't believe there would be any long lasting chainsplit though\n\u003e\u003e (because of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if\n\u003e\u003e we get unlucky.\n\u003e\u003e\n\u003e\u003e Hampus\n\u003e\u003e\n\u003e\u003e 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\u003e\n\u003e\u003e\u003e On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e Because a large percentage of miners are indifferent, right now miners\n\u003e\u003e\u003e have\n\u003e\u003e\u003e \u003e to choose between BIP148 and Segwit2x if they want to activate Segwit.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Miners can simply continuing signaling segwit, which will leave them\n\u003e\u003e\u003e at least soft-fork compatible with BIP148 and BIP91 (and god knows\n\u003e\u003e\u003e what \"segwit2x\" is since they keep changing the actual definition and\n\u003e\u003e\u003e do not have a specification; but last I saw the near-term behavior the\n\u003e\u003e\u003e same as BIP91 but with a radically reduced activation window, so the\n\u003e\u003e\u003e story would be the same there in the near term).\n\u003e\u003e\u003e\n\u003e\u003e\u003e Ironically, it looks like most of the segwit2x signaling miners are\n\u003e\u003e\u003e faking it (because they're not signaling segwit which it requires).\n\u003e\u003e\u003e It'll be unfortunate if some aren't faking it and start orphaning\n\u003e\u003e\u003e their own blocks because they are failing to signal segwit.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I don't think the rejection of segwit2x from Bitcoin's developers\n\u003e\u003e\u003e could be any more resolute than what we've already seen:\n\u003e\u003e\u003e https://en.bitcoin.it/wiki/Segwit_support\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e I think it is very naïve to assume that any shift would be temporary.\n\u003e\u003e\u003e \u003e We have a hard enough time getting miners to proactively upgrade to\n\u003e\u003e\u003e \u003e recent versions of the reference bitcoin daemon. If miners interpret\n\u003e\u003e\u003e \u003e the situation as being forced to run non-reference software in order\n\u003e\u003e\u003e \u003e to prevent a chain split because a lack of support from Bitcoin Core,\n\u003e\u003e\u003e \u003e that could be a one-way street.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think this is somewhat naive and sounds a lot like the repeat of the\n\u003e\u003e\u003e previously debunked \"XT\" and \"Classic\" hysteria.\n\u003e\u003e\u003e\n\u003e\u003e\u003e There is a reason that segwit2x is pretty much unanimously rejected by\n\u003e\u003e\u003e the technical community. And just like with XT/Classic/Unlimited\n\u003e\u003e\u003e you'll continue to see a strong correlation with people who are\n\u003e\u003e\u003e unwilling and unable to keep updating the software at an acceptable\n\u003e\u003e\u003e level of quality-- esp. because the very founding on their fork is\n\u003e\u003e\u003e predicated on discarding those properties.\n\u003e\u003e\u003e\n\u003e\u003e\u003e If miners want to go off and create an altcoin-- welp, thats something\n\u003e\u003e\u003e they can always do, and nothing about that will force anyone to go\n\u003e\u003e\u003e along with it.\n\u003e\u003e\u003e\n\u003e\u003e\u003e As far as prevent a chain split goes, all those things\n\u003e\u003e\u003e (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I\n\u003e\u003e\u003e don't think that holds.\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170620/ee28dc3b/attachment.html\u003e",
"sig": "7418e5bb801a8f7f109c198e373816a4e1ec5288723898a4c025b0ab953d0d967cd7315e9ed3c85d5a8bb8ab75ad84806a8adc7158f8c19c59c8989b09632418"
}