📅 Original date posted:2017-06-27
📝 Original message: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 at 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 at 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 at 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 at 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 at 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 at 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 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
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> 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
>
>
>
> _______________________________________________
> 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/20170627/472604e0/attachment-0001.html>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 18:03:32
in reply to nevent1q…ud6u
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Seen on
wss://relay.noswhere.comPublished at
2023-06-07 18:03:32Event JSON
{
"id": "0a0153479712dd1d6b132996b64d457e4f5f569a5a3880137bbd363b41414e55",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686161012,
"kind": 1,
"tags": [
[
"e",
"f10d3c1837e5518719736f82b51f13e32ba605e8e3996b8db87dad10332b09a3",
"",
"root"
],
[
"e",
"6af88355fd1c34d96c0c72478a6f9cc287b3dfa6915ecf2fe1218fbefad547e9",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2017-06-27\n📝 Original message:There's a pull req to core already for part of it:\n\nhttps://github.com/bitcoin/bitcoin/pull/10444\n\n\n\n\nOn Tue, Jun 27, 2017 at 12:31 PM, Jorge Timón via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e First the implementation, then the technical design (BIP)... will the\n\u003e analysis come after that?\n\u003e Will there be any kind of simulations of tje proposed size or will thag\n\u003e come only after activation on mainnet?\n\u003e I assume the very last step will be activation on testnet 3 ?\n\u003e\n\u003e\n\u003e On 27 Jun 2017 8:44 am, \"Sergio Demian Lerner via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Currently the only implementation that fulfills the requirements of the\n\u003e NYA agreement is the segwit2x/btc1 implementation, which is being finalized\n\u003e this week.\n\u003e\n\u003e Segwit2mb does not fulfill the NYA agreement.\n\u003e\n\u003e I'm asking now the segwit2x development team when a BIP will be ready so\n\u003e that Core has the opportunity to evaluate the technical proposal.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Well, this Saturday's \"Chinese roundtable\" statement from a bunch of\n\u003e\u003e miners (https://pastebin.com/b3St9VCF) says they intend \"NYA\" in the\n\u003e\u003e coinbase as support for \"the New York consensus SegWit2x program btc1 (\n\u003e\u003e https://github.com/btc1)\", whose code includes the (accelerated\n\u003e\u003e 336-block) BIP 91 change. So, other facts or interpretations could come to\n\u003e\u003e light, but until they do we should probably assume that's what the \"NYA\"\n\u003e\u003e (which just broke 80% over the last 24h) means.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e 80% have set \"NYA\" in their coinbase string. We have no idea what that\n\u003e\u003e\u003e means. People are equating it to BIP 91 -- but BIP 91 did not exist at\n\u003e\u003e\u003e the time of the New York agreement, and differs from the actual text\n\u003e\u003e\u003e of the NYA in substantive ways. The \"Segwit2MB\" that existed at the\n\u003e\u003e\u003e time of the NYA, and which was explicitly referenced by the text is\n\u003e\u003e\u003e the proposal by Sergio Demian Lerner that was made to this mailing\n\u003e\u003e\u003e list on 31 March. The text of the NYA grants no authority for\n\u003e\u003e\u003e upgrading this proposal while remaining compliant with the agreement.\n\u003e\u003e\u003e This is without even considering the fact that in the days after the\n\u003e\u003e\u003e NYA there was disagreement among those who signed it as to what it\n\u003e\u003e\u003e meant.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I feel it is a very dangerous and unwarranted assumption people are\n\u003e\u003e\u003e making that what we are seeing now is either 80% support for BIP-91 or\n\u003e\u003e\u003e for the code in the btc1 repo.\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty \u003cerik at q32.com\u003e wrote:\n\u003e\u003e\u003e \u003e # Jacob Eliosoff:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e will start orphaning non-bit-1 blocks before Aug 1, and we avoid a\n\u003e\u003e\u003e split.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Correct. There are 2 short activation periods in BIP91 either of which\n\u003e\u003e\u003e \u003e would avoid a split.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e # Gregory Maxwell:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e unclear to me _exactly_ what it would need to implement to be\n\u003e\u003e\u003e consistent.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e This is the relevant pull req to core:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e https://github.com/bitcoin/bitcoin/pull/10444\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Seems OK. It's technically running now on testnet5. I think it (or a\n\u003e\u003e\u003e \u003e -bip148 option) should be merged as soon as feasible.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e previously debunked \"XT\" and \"Classic\" hysteria.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e apples vs oranges, imo. segwit is not a contentious feature. the\n\u003e\u003e\u003e \u003e \"bundling\" in segwit2x is, but that's not the issue here. the issue\n\u003e\u003e\u003e is we\n\u003e\u003e\u003e \u003e are indirectly requiring miners that strongly support segwit to install\n\u003e\u003e\u003e \u003e consensus protocol changes outside of bitcoin's standard reference.\n\u003e\u003e\u003e 80% of\n\u003e\u003e\u003e \u003e them have signaled they will do so. these are uncharted waters.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev\n\u003e\u003e\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e I could be wrong, but the latest BIP91 implementation (also included\n\u003e\u003e\u003e in\n\u003e\u003e\u003e \u003e\u003e Segwit2x) cuts the activation period to 336 blocks (2.33 days).\n\u003e\u003e\u003e (This has\n\u003e\u003e\u003e \u003e\u003e been updated at\n\u003e\u003e\u003e \u003e\u003e https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So\n\u003e\u003e\u003e if 80%\n\u003e\u003e\u003e \u003e\u003e of hashpower is actually running that code and signaling on bit 4 by\n\u003e\u003e\u003e July 25\n\u003e\u003e\u003e \u003e\u003e or so, then those 80+% will start orphaning non-bit-1 blocks before\n\u003e\u003e\u003e Aug 1,\n\u003e\u003e\u003e \u003e\u003e and we avoid a split.\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e There may still be a few non-bit-1 blocks that get orphaned after Aug\n\u003e\u003e\u003e 1,\n\u003e\u003e\u003e \u003e\u003e because they're mined by old BIP141 nodes. But it seems like very few\n\u003e\u003e\u003e \u003e\u003e miners won't be signaling either Segwit2x *or* BIP141 by then...\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e Make sense?\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach \u003c\n\u003e\u003e\u003e mark at friedenbach.org\u003e\n\u003e\u003e\u003e \u003e\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e Why do you say activation by August 1st is likely? That would\n\u003e\u003e\u003e require an\n\u003e\u003e\u003e \u003e\u003e\u003e entire difficulty adjustment period with \u003e=95% bit1 signaling. That\n\u003e\u003e\u003e seems a\n\u003e\u003e\u003e \u003e\u003e\u003e tall order to organize in the scant few weeks remaining.\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e If segwit is activated before Aug 1, as now seems likely, there will\n\u003e\u003e\u003e be\n\u003e\u003e\u003e \u003e\u003e\u003e no split that day. But if activation is via Segwit2x (also likely),\n\u003e\u003e\u003e and at\n\u003e\u003e\u003e \u003e\u003e\u003e least some nodes do \u0026 some don't follow through with the HF 3mo later\n\u003e\u003e\u003e \u003e\u003e\u003e (again, likely), agreed w/ Greg that *then* we'll see a split -\n\u003e\u003e\u003e probably in\n\u003e\u003e\u003e \u003e\u003e\u003e Sep/Oct. How those two chains will match up and how the split will\n\u003e\u003e\u003e play out\n\u003e\u003e\u003e \u003e\u003e\u003e is anyone's guess...\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e On Jun 20, 2017 6:16 PM, \"Hampus Sjöberg via bitcoin-dev\"\n\u003e\u003e\u003e \u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e \u003e Ironically, it looks like most of the segwit2x signaling miners are\n\u003e\u003e\u003e \u003e\u003e\u003e \u003e faking it (because they're not signaling segwit which it requires).\n\u003e\u003e\u003e \u003e\u003e\u003e \u003e It'll be unfortunate if some aren't faking it and start orphaning\n\u003e\u003e\u003e \u003e\u003e\u003e \u003e their own blocks because they are failing to signal segwit.\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e Well, they're doing some kind of \"pre-signaling\" in the coinbase at\n\u003e\u003e\u003e the\n\u003e\u003e\u003e \u003e\u003e\u003e moment, because the segwit2x project is still in alpha-phase\n\u003e\u003e\u003e according to\n\u003e\u003e\u003e \u003e\u003e\u003e the timeline. They're just showing commitment.\n\u003e\u003e\u003e \u003e\u003e\u003e I'm sure they will begin signaling on version bit 4/BIP91 as well as\n\u003e\u003e\u003e \u003e\u003e\u003e actually running a segwit2x node when the time comes.\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e \u003e As far as prevent a chain split goes, all those things\n\u003e\u003e\u003e \u003e\u003e\u003e \u003e (148/91/segwit2x(per today)) effectively guarantee a chainsplit--\n\u003e\u003e\u003e so I\n\u003e\u003e\u003e \u003e\u003e\u003e \u003e don't think that holds.\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x\n\u003e\u003e\u003e (or\n\u003e\u003e\u003e \u003e\u003e\u003e BIP148) node, because they wouldn't have the new consensus rule of\n\u003e\u003e\u003e requiring\n\u003e\u003e\u003e \u003e\u003e\u003e all blocks to signal for segwit.\n\u003e\u003e\u003e \u003e\u003e\u003e I don't believe there would be any long lasting chainsplit though\n\u003e\u003e\u003e \u003e\u003e\u003e (because of the ~80% hashrate support on segwit2x), perhaps 2-3\n\u003e\u003e\u003e blocks if we\n\u003e\u003e\u003e \u003e\u003e\u003e get unlucky.\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e Hampus\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e Because a large percentage of miners are indifferent, right now\n\u003e\u003e\u003e miners\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e have\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e to choose between BIP148 and Segwit2x if they want to activate\n\u003e\u003e\u003e Segwit.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e Miners can simply continuing signaling segwit, which will leave them\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e at least soft-fork compatible with BIP148 and BIP91 (and god knows\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e what \"segwit2x\" is since they keep changing the actual definition\n\u003e\u003e\u003e and\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e do not have a specification; but last I saw the near-term behavior\n\u003e\u003e\u003e the\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e same as BIP91 but with a radically reduced activation window, so the\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e story would be the same there in the near term).\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e Ironically, it looks like most of the segwit2x signaling miners are\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e faking it (because they're not signaling segwit which it requires).\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e It'll be unfortunate if some aren't faking it and start orphaning\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e their own blocks because they are failing to signal segwit.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e I don't think the rejection of segwit2x from Bitcoin's developers\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e could be any more resolute than what we've already seen:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e https://en.bitcoin.it/wiki/Segwit_support\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e I think it is very naïve to assume that any shift would be\n\u003e\u003e\u003e temporary.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e We have a hard enough time getting miners to proactively upgrade\n\u003e\u003e\u003e to\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e recent versions of the reference bitcoin daemon. If miners\n\u003e\u003e\u003e interpret\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e the situation as being forced to run non-reference software in\n\u003e\u003e\u003e order\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e to prevent a chain split because a lack of support from Bitcoin\n\u003e\u003e\u003e Core,\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e that could be a one-way street.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e I think this is somewhat naive and sounds a lot like the repeat of\n\u003e\u003e\u003e the\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e previously debunked \"XT\" and \"Classic\" hysteria.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e There is a reason that segwit2x is pretty much unanimously rejected\n\u003e\u003e\u003e by\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e the technical community. And just like with XT/Classic/Unlimited\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e you'll continue to see a strong correlation with people who are\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e unwilling and unable to keep updating the software at an acceptable\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e level of quality-- esp. because the very founding on their fork is\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e predicated on discarding those properties.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e If miners want to go off and create an altcoin-- welp, thats\n\u003e\u003e\u003e something\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e they can always do, and nothing about that will force anyone to go\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e along with it.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e As far as prevent a chain split goes, all those things\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e (148/91/segwit2x(per today)) effectively guarantee a chainsplit--\n\u003e\u003e\u003e so I\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e don't think that holds.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e \u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e \u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e _______________________________________________\n\u003e\u003e\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\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\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170627/472604e0/attachment-0001.html\u003e",
"sig": "f417a32f7a8949c24b0c6a46c9113de596e78967c85e446b863718b0ffc235166cabce92decf45bfa7f341b09935a88416a853c4d313f19a4da42de7862859d4"
}