Discussion:
Miners forced to run non-core code in order to get segwit activated
(too old to reply)
Erik Aronesty via bitcoin-dev
2017-06-20 15:44:36 UTC
Permalink
Raw Message
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
Hampus Sjöberg via bitcoin-dev
2017-06-20 16:49:38 UTC
Permalink
Raw Message
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 <
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Mark Friedenbach via bitcoin-dev
2017-06-20 17:22:18 UTC
Permalink
Raw Message
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
Post by Hampus Sjöberg via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Gregory Maxwell via bitcoin-dev
2017-06-20 21:49:50 UTC
Permalink
Raw Message
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
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.
Hampus Sjöberg via bitcoin-dev
2017-06-20 22:15:59 UTC
Permalink
Raw Message
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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 <
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now miners
have
Post by Erik Aronesty via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jacob Eliosoff via bitcoin-dev
2017-06-20 22:29:27 UTC
Permalink
Raw Message
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" <
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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 <
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now miners
have
Post by Erik Aronesty via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Mark Friedenbach via bitcoin-dev
2017-06-20 22:48:23 UTC
Permalink
Raw Message
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.
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...
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jacob Eliosoff via bitcoin-dev
2017-06-20 22:57:34 UTC
Permalink
Raw Message
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?
Post by Mark Friedenbach via bitcoin-dev
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 <
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" <
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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 <
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now miners
have
Post by Erik Aronesty via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jacob Eliosoff via bitcoin-dev
2017-06-20 23:01:14 UTC
Permalink
Raw Message
(That is: "...because they're mined by old non-Segwit2x nodes that *aren't
signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit)
Post by Jacob Eliosoff via bitcoin-dev
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?
Post by Mark Friedenbach via bitcoin-dev
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 <
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" <
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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 <
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now miners
have
Post by Erik Aronesty via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-06-21 01:36:49 UTC
Permalink
Raw Message
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.
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 <
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?
Post by Mark Friedenbach via bitcoin-dev
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 <
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" <
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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 <
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now miners
have
Post by Erik Aronesty via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Mark Friedenbach via bitcoin-dev
2017-06-21 02:11:15 UTC
Permalink
Raw Message
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.
Post by Erik Aronesty via bitcoin-dev
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.
unclear to me _exactly_ what it would need to implement to be consistent.
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
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?
Post by Mark Friedenbach via bitcoin-dev
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
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"
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jacob Eliosoff via bitcoin-dev
2017-06-21 04:05:53 UTC
Permalink
Raw Message
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.
Post by Mark Friedenbach via 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.
Post by Erik Aronesty via bitcoin-dev
will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
split.
Post by Erik Aronesty via bitcoin-dev
Correct. There are 2 short activation periods in BIP91 either of which
would avoid a split.
unclear to me _exactly_ what it would need to implement to be
consistent.
Post by Erik Aronesty via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
are indirectly requiring miners that strongly support segwit to install
consensus protocol changes outside of bitcoin's standard reference.
80% of
Post by Erik Aronesty via bitcoin-dev
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
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
Post by Erik Aronesty via bitcoin-dev
been updated at
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
if 80%
Post by Erik Aronesty via bitcoin-dev
of hashpower is actually running that code and signaling on bit 4 by
July 25
Post by Erik Aronesty via bitcoin-dev
or so, then those 80+% will start orphaning non-bit-1 blocks before Aug
1,
Post by Erik Aronesty via bitcoin-dev
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?
Post by Mark Friedenbach via bitcoin-dev
Why do you say activation by August 1st is likely? That would require
an
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
entire difficulty adjustment period with >=95% bit1 signaling. That
seems a
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
tall order to organize in the scant few weeks remaining.
On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Sep/Oct. How those two chains will match up and how the split will
play out
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
is anyone's guess...
On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
As far as prevent a chain split goes, all those things
(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so
I
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
get unlucky.
Hampus
2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now
miners
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
have
to choose between BIP148 and Segwit2x if they want to activate
Segwit.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
I think it is very naïve to assume that any shift would be
temporary.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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,
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Sergio Demian Lerner via bitcoin-dev
2017-06-27 15:42:53 UTC
Permalink
Raw Message
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 <
Post by Jacob Eliosoff via bitcoin-dev
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.
Post by Mark Friedenbach via 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.
Post by Erik Aronesty via bitcoin-dev
will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
split.
Post by Erik Aronesty via bitcoin-dev
Correct. There are 2 short activation periods in BIP91 either of which
would avoid a split.
unclear to me _exactly_ what it would need to implement to be
consistent.
Post by Erik Aronesty via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
are indirectly requiring miners that strongly support segwit to install
consensus protocol changes outside of bitcoin's standard reference.
80% of
Post by Erik Aronesty via bitcoin-dev
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
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
Post by Erik Aronesty via bitcoin-dev
been updated at
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
if 80%
Post by Erik Aronesty via bitcoin-dev
of hashpower is actually running that code and signaling on bit 4 by
July 25
Post by Erik Aronesty via bitcoin-dev
or so, then those 80+% will start orphaning non-bit-1 blocks before
Aug 1,
Post by Erik Aronesty via bitcoin-dev
and we avoid a split.
There may still be a few non-bit-1 blocks that get orphaned after Aug
1,
Post by Erik Aronesty via bitcoin-dev
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 <
Post by Mark Friedenbach via bitcoin-dev
Why do you say activation by August 1st is likely? That would require
an
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
entire difficulty adjustment period with >=95% bit1 signaling. That
seems a
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
tall order to organize in the scant few weeks remaining.
On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
If segwit is activated before Aug 1, as now seems likely, there will
be
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
no split that day. But if activation is via Segwit2x (also likely),
and at
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Sep/Oct. How those two chains will match up and how the split will
play out
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
is anyone's guess...
On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
moment, because the segwit2x project is still in alpha-phase
according to
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
As far as prevent a chain split goes, all those things
(148/91/segwit2x(per today)) effectively guarantee a chainsplit--
so I
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
don't think that holds.
Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x
(or
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
BIP148) node, because they wouldn't have the new consensus rule of
requiring
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
get unlucky.
Hampus
2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now
miners
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
have
to choose between BIP148 and Segwit2x if they want to activate
Segwit.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
I think it is very naïve to assume that any shift would be
temporary.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
We have a hard enough time getting miners to proactively upgrade to
recent versions of the reference bitcoin daemon. If miners
interpret
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
the situation as being forced to run non-reference software in
order
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
to prevent a chain split because a lack of support from Bitcoin
Core,
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
that could be a one-way street.
I think this is somewhat naive and sounds a lot like the repeat of
the
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
previously debunked "XT" and "Classic" hysteria.
There is a reason that segwit2x is pretty much unanimously rejected
by
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
don't think that holds.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2017-06-27 16:31:26 UTC
Permalink
Raw Message
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-***@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 <
Post by Jacob Eliosoff via bitcoin-dev
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.
Post by Mark Friedenbach via 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.
Post by Erik Aronesty via bitcoin-dev
will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
split.
Post by Erik Aronesty via bitcoin-dev
Correct. There are 2 short activation periods in BIP91 either of which
would avoid a split.
unclear to me _exactly_ what it would need to implement to be
consistent.
Post by Erik Aronesty via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
are indirectly requiring miners that strongly support segwit to install
consensus protocol changes outside of bitcoin's standard reference.
80% of
Post by Erik Aronesty via bitcoin-dev
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
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
Post by Erik Aronesty via bitcoin-dev
been updated at
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
if 80%
Post by Erik Aronesty via bitcoin-dev
of hashpower is actually running that code and signaling on bit 4 by
July 25
Post by Erik Aronesty via bitcoin-dev
or so, then those 80+% will start orphaning non-bit-1 blocks before
Aug 1,
Post by Erik Aronesty via bitcoin-dev
and we avoid a split.
There may still be a few non-bit-1 blocks that get orphaned after Aug
1,
Post by Erik Aronesty via bitcoin-dev
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 <
Post by Mark Friedenbach via bitcoin-dev
Why do you say activation by August 1st is likely? That would require
an
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
entire difficulty adjustment period with >=95% bit1 signaling. That
seems a
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
tall order to organize in the scant few weeks remaining.
On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
If segwit is activated before Aug 1, as now seems likely, there will
be
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
no split that day. But if activation is via Segwit2x (also likely),
and at
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Sep/Oct. How those two chains will match up and how the split will
play out
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
is anyone's guess...
On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
moment, because the segwit2x project is still in alpha-phase
according to
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
As far as prevent a chain split goes, all those things
(148/91/segwit2x(per today)) effectively guarantee a chainsplit--
so I
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
don't think that holds.
Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x
(or
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
BIP148) node, because they wouldn't have the new consensus rule of
requiring
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
get unlucky.
Hampus
2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now
miners
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
have
to choose between BIP148 and Segwit2x if they want to activate
Segwit.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
I think it is very naïve to assume that any shift would be
temporary.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
We have a hard enough time getting miners to proactively upgrade to
recent versions of the reference bitcoin daemon. If miners
interpret
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
the situation as being forced to run non-reference software in
order
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
to prevent a chain split because a lack of support from Bitcoin
Core,
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
that could be a one-way street.
I think this is somewhat naive and sounds a lot like the repeat of
the
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
previously debunked "XT" and "Classic" hysteria.
There is a reason that segwit2x is pretty much unanimously rejected
by
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
don't think that holds.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-06-27 19:26:35 UTC
Permalink
Raw Message
There's a pull req to core already for part of it:

https://github.com/bitcoin/bitcoin/pull/10444




On Tue, Jun 27, 2017 at 12:31 PM, Jorge Timón via bitcoin-dev <
Post by Jorge Timón via bitcoin-dev
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" <
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 <
Post by Jacob Eliosoff via bitcoin-dev
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.
Post by Mark Friedenbach via 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.
Post by Erik Aronesty via bitcoin-dev
will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
split.
Post by Erik Aronesty via bitcoin-dev
Correct. There are 2 short activation periods in BIP91 either of which
would avoid a split.
unclear to me _exactly_ what it would need to implement to be
consistent.
Post by Erik Aronesty via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
are indirectly requiring miners that strongly support segwit to install
consensus protocol changes outside of bitcoin's standard reference.
80% of
Post by Erik Aronesty via bitcoin-dev
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
I could be wrong, but the latest BIP91 implementation (also included
in
Post by Erik Aronesty via bitcoin-dev
Segwit2x) cuts the activation period to 336 blocks (2.33 days).
(This has
Post by Erik Aronesty via bitcoin-dev
been updated at
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
if 80%
Post by Erik Aronesty via bitcoin-dev
of hashpower is actually running that code and signaling on bit 4 by
July 25
Post by Erik Aronesty via bitcoin-dev
or so, then those 80+% will start orphaning non-bit-1 blocks before
Aug 1,
Post by Erik Aronesty via bitcoin-dev
and we avoid a split.
There may still be a few non-bit-1 blocks that get orphaned after Aug
1,
Post by Erik Aronesty via bitcoin-dev
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 <
Post by Mark Friedenbach via bitcoin-dev
Why do you say activation by August 1st is likely? That would
require an
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
entire difficulty adjustment period with >=95% bit1 signaling. That
seems a
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
tall order to organize in the scant few weeks remaining.
On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
If segwit is activated before Aug 1, as now seems likely, there will
be
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
no split that day. But if activation is via Segwit2x (also likely),
and at
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Sep/Oct. How those two chains will match up and how the split will
play out
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
is anyone's guess...
On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
moment, because the segwit2x project is still in alpha-phase
according to
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
As far as prevent a chain split goes, all those things
(148/91/segwit2x(per today)) effectively guarantee a chainsplit--
so I
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
don't think that holds.
Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x
(or
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
BIP148) node, because they wouldn't have the new consensus rule of
requiring
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
get unlucky.
Hampus
2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
Because a large percentage of miners are indifferent, right now
miners
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
have
to choose between BIP148 and Segwit2x if they want to activate
Segwit.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
do not have a specification; but last I saw the near-term behavior
the
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://en.bitcoin.it/wiki/Segwit_support
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
I think it is very naïve to assume that any shift would be
temporary.
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
We have a hard enough time getting miners to proactively upgrade
to
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
recent versions of the reference bitcoin daemon. If miners
interpret
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
the situation as being forced to run non-reference software in
order
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
to prevent a chain split because a lack of support from Bitcoin
Core,
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
that could be a one-way street.
I think this is somewhat naive and sounds a lot like the repeat of
the
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
previously debunked "XT" and "Classic" hysteria.
There is a reason that segwit2x is pretty much unanimously rejected
by
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
don't think that holds.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Gregory Maxwell via bitcoin-dev
2017-06-20 22:34:29 UTC
Permalink
Raw Message
On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg
Post by Hampus Sjöberg via bitcoin-dev
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.
Hampus Sjöberg via bitcoin-dev
2017-06-20 22:53:29 UTC
Permalink
Raw Message
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg
Post by Hampus Sjöberg via bitcoin-dev
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
Post by Hampus Sjöberg via bitcoin-dev
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.
Ryan J Martin via bitcoin-dev
2017-06-20 19:49:57 UTC
Permalink
Raw Message
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-***@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
Post by Hampus Sjöberg via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-***@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...