* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated
@ 2017-06-20 19:49 Ryan J Martin
0 siblings, 0 replies; 18+ messages in thread
From: Ryan J Martin @ 2017-06-20 19:49 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]
I concur with Mark's reply. Just to underscore this: Miners arent going to bother to signaling or changing a setting unless they have to. Anything that requires time--especially if requiring a restart/any time not mining or risks a crash---reduces income. So why would they change any settings unless they have to?
-Ryan J. Martin
On Jun 20, 2017 1:26 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.
On Tue, Jun 20, 2017 at 9:49 AM, Hampus Sjöberg via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I don't think it's a huge deal if the miners need to run a non-Core node
> once the BIP91 deployment of Segwit2x happens. The shift will most likely be
> temporary.
>
> I agree that the "-bip148"-option should be merged, though.
>
> 2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org>:
>>
>> Are we going to merge BIP91 or a -BIP148 option to core for inclusion in
>> the next release or so?
>>
>> Because a large percentage of miners are indifferent, right now miners
>> have to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>
>> Should we be forcing miners to choose to run non-core code in order to
>> activate a popular feature?
>>
>> - Erik
>>
>> _______________________________________________
>> 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: 3378 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated @ 2017-06-20 15:44 Erik Aronesty 2017-06-20 16:49 ` Hampus Sjöberg 2017-06-20 21:49 ` Gregory Maxwell 0 siblings, 2 replies; 18+ messages in thread From: Erik Aronesty @ 2017-06-20 15:44 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 353 bytes --] Are we going to merge BIP91 or a -BIP148 option to core for inclusion in the next release or so? Because a large percentage of miners are indifferent, right now miners have to choose between BIP148 and Segwit2x if they want to activate Segwit. Should we be forcing miners to choose to run non-core code in order to activate a popular feature? - Erik [-- Attachment #2: Type: text/html, Size: 401 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 15:44 Erik Aronesty @ 2017-06-20 16:49 ` Hampus Sjöberg 2017-06-20 17:22 ` Mark Friedenbach 2017-06-20 21:49 ` Gregory Maxwell 1 sibling, 1 reply; 18+ messages in thread From: Hampus Sjöberg @ 2017-06-20 16:49 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 883 bytes --] I don't think it's a huge deal if the miners need to run a non-Core node once the BIP91 deployment of Segwit2x happens. The shift will most likely be temporary. I agree that the "-bip148"-option should be merged, though. 2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org>: > Are we going to merge BIP91 or a -BIP148 option to core for inclusion in > the next release or so? > > Because a large percentage of miners are indifferent, right now miners > have to choose between BIP148 and Segwit2x if they want to activate Segwit. > > > Should we be forcing miners to choose to run non-core code in order to > activate a popular feature? > > - Erik > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 1522 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 16:49 ` Hampus Sjöberg @ 2017-06-20 17:22 ` Mark Friedenbach 0 siblings, 0 replies; 18+ messages in thread From: Mark Friedenbach @ 2017-06-20 17:22 UTC (permalink / raw) To: Hampus Sjöberg; +Cc: Bitcoin Protocol Discussion 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. On Tue, Jun 20, 2017 at 9:49 AM, Hampus Sjöberg via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > I don't think it's a huge deal if the miners need to run a non-Core node > once the BIP91 deployment of Segwit2x happens. The shift will most likely be > temporary. > > I agree that the "-bip148"-option should be merged, though. > > 2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org>: >> >> Are we going to merge BIP91 or a -BIP148 option to core for inclusion in >> the next release or so? >> >> Because a large percentage of miners are indifferent, right now miners >> have to choose between BIP148 and Segwit2x if they want to activate Segwit. >> >> Should we be forcing miners to choose to run non-core code in order to >> activate a popular feature? >> >> - Erik >> >> _______________________________________________ >> 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 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 15:44 Erik Aronesty 2017-06-20 16:49 ` Hampus Sjöberg @ 2017-06-20 21:49 ` Gregory Maxwell 2017-06-20 22:15 ` Hampus Sjöberg 1 sibling, 1 reply; 18+ messages in thread From: Gregory Maxwell @ 2017-06-20 21:49 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 21:49 ` Gregory Maxwell @ 2017-06-20 22:15 ` Hampus Sjöberg 2017-06-20 22:29 ` Jacob Eliosoff 2017-06-20 22:34 ` Gregory Maxwell 0 siblings, 2 replies; 18+ messages in thread From: Hampus Sjöberg @ 2017-06-20 22:15 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3944 bytes --] > 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 > [-- Attachment #2: Type: text/html, Size: 5100 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 22:15 ` Hampus Sjöberg @ 2017-06-20 22:29 ` Jacob Eliosoff 2017-06-20 22:48 ` Mark Friedenbach 2017-06-20 22:34 ` Gregory Maxwell 1 sibling, 1 reply; 18+ messages in thread From: Jacob Eliosoff @ 2017-06-20 22:29 UTC (permalink / raw) To: Hampus Sjöberg; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4643 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 6517 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 22:29 ` Jacob Eliosoff @ 2017-06-20 22:48 ` Mark Friedenbach 2017-06-20 22:57 ` Jacob Eliosoff 0 siblings, 1 reply; 18+ messages in thread From: Mark Friedenbach @ 2017-06-20 22:48 UTC (permalink / raw) To: Jacob Eliosoff; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5254 bytes --] 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: 7413 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 22:48 ` Mark Friedenbach @ 2017-06-20 22:57 ` Jacob Eliosoff 2017-06-20 23:01 ` Jacob Eliosoff 2017-06-21 1:36 ` Erik Aronesty 0 siblings, 2 replies; 18+ messages in thread From: Jacob Eliosoff @ 2017-06-20 22:57 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 6045 bytes --] 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: 8855 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 22:57 ` Jacob Eliosoff @ 2017-06-20 23:01 ` Jacob Eliosoff 2017-06-21 1:36 ` Erik Aronesty 1 sibling, 0 replies; 18+ messages in thread From: Jacob Eliosoff @ 2017-06-20 23:01 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 22:57 ` Jacob Eliosoff 2017-06-20 23:01 ` Jacob Eliosoff @ 2017-06-21 1:36 ` Erik Aronesty 2017-06-21 2:11 ` Mark Friedenbach 1 sibling, 1 reply; 18+ messages in thread From: Erik Aronesty @ 2017-06-21 1:36 UTC (permalink / raw) To: Jacob Eliosoff; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 7443 bytes --] # 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 > > [-- Attachment #2: Type: text/html, Size: 11504 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-21 1:36 ` Erik Aronesty @ 2017-06-21 2:11 ` Mark Friedenbach 2017-06-21 4:05 ` Jacob Eliosoff 0 siblings, 1 reply; 18+ messages in thread From: Mark Friedenbach @ 2017-06-21 2:11 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Dev 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 >> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-21 2:11 ` Mark Friedenbach @ 2017-06-21 4:05 ` Jacob Eliosoff 2017-06-27 15:42 ` Sergio Demian Lerner 0 siblings, 1 reply; 18+ messages in thread From: Jacob Eliosoff @ 2017-06-21 4:05 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 9578 bytes --] 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 > >> > > > [-- Attachment #2: Type: text/html, Size: 13643 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-21 4:05 ` Jacob Eliosoff @ 2017-06-27 15:42 ` Sergio Demian Lerner 2017-06-27 16:31 ` Jorge Timón 0 siblings, 1 reply; 18+ messages in thread From: Sergio Demian Lerner @ 2017-06-27 15:42 UTC (permalink / raw) To: Jacob Eliosoff; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-27 15:42 ` Sergio Demian Lerner @ 2017-06-27 16:31 ` Jorge Timón 2017-06-27 19:26 ` Erik Aronesty 0 siblings, 1 reply; 18+ messages in thread From: Jorge Timón @ 2017-06-27 16:31 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 11099 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 16515 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-27 16:31 ` Jorge Timón @ 2017-06-27 19:26 ` Erik Aronesty 0 siblings, 0 replies; 18+ messages in thread From: Erik Aronesty @ 2017-06-27 19:26 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 22:15 ` Hampus Sjöberg 2017-06-20 22:29 ` Jacob Eliosoff @ 2017-06-20 22:34 ` Gregory Maxwell 2017-06-20 22:53 ` Hampus Sjöberg 1 sibling, 1 reply; 18+ messages in thread From: Gregory Maxwell @ 2017-06-20 22:34 UTC (permalink / raw) To: Hampus Sjöberg; +Cc: Bitcoin Protocol Discussion On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg <hampus.sjoberg@gmail•com> wrote: > 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. All versions of Bitcoin Core since 0.13.1 signal segwit, 0.14.1+ even when downstream mining software doesn't support it. I think it would be useful for there to exist a useful and trivial patch against current (0.14.2) software to engage in the BIP91-like orphaning, like people have provided for BIP148-- but right now I don't see any specification of the behavior so it's unclear to me _exactly_ what it would need to implement to be consistent. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated 2017-06-20 22:34 ` Gregory Maxwell @ 2017-06-20 22:53 ` Hampus Sjöberg 0 siblings, 0 replies; 18+ messages in thread From: Hampus Sjöberg @ 2017-06-20 22:53 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1467 bytes --] > I think it would be useful for there to exist a useful and trivial > patch against current (0.14.2) software to engage in the BIP91-like > orphaning, like people have provided for BIP148-- but right now I > don't see any specification of the behavior so it's unclear to me > _exactly_ what it would need to implement to be consistent. I agree. This is the latest code regarding BIP91 that got merged, https://github.com/btc1/bitcoin/pull/21/files so that should be the spec we need to follow (also the old BIP91 PR: https://github.com/btc1/bitcoin/pull/17/files). Perhaps James Hilliard could give input here though. 2017-06-21 0:34 GMT+02:00 Gregory Maxwell <greg@xiph•org>: > On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg > <hampus.sjoberg@gmail•com> wrote: > > 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. > > All versions of Bitcoin Core since 0.13.1 signal segwit, 0.14.1+ even > when downstream mining software doesn't support it. > > I think it would be useful for there to exist a useful and trivial > patch against current (0.14.2) software to engage in the BIP91-like > orphaning, like people have provided for BIP148-- but right now I > don't see any specification of the behavior so it's unclear to me > _exactly_ what it would need to implement to be consistent. > [-- Attachment #2: Type: text/html, Size: 2082 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-06-27 19:26 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-20 19:49 [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated Ryan J Martin -- strict thread matches above, loose matches on Subject: below -- 2017-06-20 15:44 Erik Aronesty 2017-06-20 16:49 ` Hampus Sjöberg 2017-06-20 17:22 ` Mark Friedenbach 2017-06-20 21:49 ` Gregory Maxwell 2017-06-20 22:15 ` Hampus Sjöberg 2017-06-20 22:29 ` Jacob Eliosoff 2017-06-20 22:48 ` Mark Friedenbach 2017-06-20 22:57 ` Jacob Eliosoff 2017-06-20 23:01 ` Jacob Eliosoff 2017-06-21 1:36 ` Erik Aronesty 2017-06-21 2:11 ` Mark Friedenbach 2017-06-21 4:05 ` Jacob Eliosoff 2017-06-27 15:42 ` Sergio Demian Lerner 2017-06-27 16:31 ` Jorge Timón 2017-06-27 19:26 ` Erik Aronesty 2017-06-20 22:34 ` Gregory Maxwell 2017-06-20 22:53 ` Hampus Sjöberg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox