Consensus::DEPLOYMENT_SEGWIT2X is incorrectly named

[petertodd]

It should be named Consensus::DEPLOYMENT_BIP91, as it implements the BIP91 reduced threshold segwit activation soft-fork.

As @luke-jr pointed out in pull-req #58, the segwit2x hard-fork - also referred to as BIP102 in this codebase - activates 90*144 blocks ("90 days") after segwit activates regardless of how segwit is activated. So it could, for instance, activate due to a the BIP148 user-activated soft-fork activating segwit, even though miners supporting that softfork would have no intent to hard-fork.

The segwit2x hard-fork is in fact is quite similar to Bitmain's recent user-activated-hard-fork proposal in that it needs user support to come into affect, and will follow a minority hashing power chain even if the majority of hashing power does not support the segwit2x hard-fork.

[benkloester]

NACK, I don't see how this has any effect on the code whatsoever.

[rikur]

Where do they find these people to develop the newb fork?

[JaredR26]

Where do they find these people to develop the newb fork?

Peter is a core dev who has decided that trying to interrupt and derail another project is the best use of his time.

[booung]

@JaredR26 You have already had a post deleted by @jgarzik and been asked to keep it professional in the very PR this issue is referencing. Please try to keep discussion technical :)

[jaybny]

is this github or 4chan?!

[WaveringAna]

some days I cant tell the difference between the 2

[JaredR26]

is this github or 4chan?!

I wasn't aware that the words "core dev," "interrupt," or "derail" were popular 4Chan terminology. Noted.

Regardless of that, Peter IS a core dev, and this is yet another attempt to treat bit signaling as if segwit activation was divorced from the hardfork. That goes against the charter and it serves no purpose here.

Everything I stated except perhaps speculating on how Peter spends his time was true.

[jaybny]

@JaredR26 is it your opinion that Consensus::DEPLOYMENT_SEGWIT2X is correctly named or incorrectly named? and why? because its a valid technical point. hes helping you guys.. bec. open source.

[JaredR26]

It is named correctly. From an email thread Peter started around the same time he opened this issue:

and there are a number of other implementations of BIP91 in existence. In short, bit-4 no longer means "segwit2x hard-fork"

Other people's attempts to co-opt a bit chosen by another project have no value here, nor would they have any value anywhere else. I'm stunned that you're actually trying to present other people's co-opting an activation bit of this project as a serious argument [for it being changed].

I can only imagine the outrage that core would express of some other project attempted to co-opt the meaning of one of their service activation bits. Yet despite that, the argument here is literally that this project should be changed to accommodate Core's attempts to change the meaning of our service activation bits.

No. That is never going to happen for any project, even a core project. No one can claim ownership over the the service bit specifications, even if Core believes that it belongs to them. Sorry.

[snavsenv]

Is it me or is Jareds post extremely confusing?

[nukebloodaxe]

It's a consequence of using the quote feature via email, it has resulted in the quotes being marked for only one line. As a result, you have to carefully work out where the quote ends and his reply begins by backtracking to prior messages; this may not be a problem in email messages themselves, but I follow these threads via the Github interface.

Essentially, right now I suspect the problem is that we can't tell the difference between Consensus::DEPLOYMENT_SEGWIT2X and Consensus::DEPLOYMENT_SEGWIT2X ; Where both BIP91 and BIP102 are effectively rolled into the same activation mechanism, and yet not [ there are two independently timed deployments, with their own code paths, taking place here after all.] Personally, I like clear labels for debugging, and although this is honestly trivial, it will do no harm to provide further clarification.

[snavsenv]

The new york agreement says we hardfork, so we hardfork , who cares about all this technical stuff? /s

[is55555]

ACK - Consensus::DEPLOYMENT_BIP91 is the correct name

[jgarzik]

Troll issue deleted

[spurin]

Also ACK - Consensus::DEPLOYMENT_BIP91 is more appropriate

[JaredR26]

It's a consequence of using the quote feature via email, it has resulted in the quotes being marked for only one line. As a result, you have to carefully work out where the quote ends and his reply begins by backtracking to prior messages; this may not be a problem in email messages themselves, but I follow these threads via the Github interface

Sorry, am/was replying on my phone via email, can't actually reply on github from here. Fighting with autocorrect is already fun enough. Did this quote show up correctly? I'll try to watch it / fix it in the future.

[snavsenv]

If nobody runs BTC1 and people just run BIP91 patched software (You could argue BTC1 is just BIP91 patched software even.) then the real troll issue is SegWit2x because it wasnt even neccesary to begin with. SegWit2x will continue to troll for the next 3 months or however long until the network knows wether the hardfork will happen, and wether some people will consider that hardfork bitcoin. Gonna be awkward and what is the purpose again?

[nukebloodaxe]

@JaredR26 Yes, that formatting has come through fine, I understand the difficulties of working with phones and email, so perfectly understandable. It's one of those catch-22's though, do you point it out and seem slightly offensive/rude, or do you let the end user know (it's not always apparent which is right because it's person dependent ;) )