BIP91 activation does not orphan non bit-4 blocks

[tomasvdw]

I have noticed that on activation of BIP91 non-bit 1 blocks are rejected but non-bit 4 blocks are not.

It would be much safer to also reject non-bit 4 signaling blocks as customary with earlier softforks, because

• This removes the risk of the hardfork causing a chainsplit (unless miners would run a new implementation which maliciously reuses bit 4 as SegWit-only)
• By extension, this removes the need for replay protection
• It eliminates the inconsistency that only non-SegWit miners are forced to upgrade.

I understand the benefit of compatibility with existing non-mining nodes through BIP91, but attempting compatibility with (some) miners seems to have more drawbacks than benefits as it increases the risks of the hardfork.

(Note if this is accepted and hands are short I can do a PR for this)

[jameshilliard]

I have noticed that on activation of BIP91 non-bit 1 blocks are rejected but non-bit 4 blocks are not.

Mandatory bit1 signalling is only temporary until segwit is locked in. Miners already will have to upgrade otherwise they risk building on top of invalid blocks.

It would be much safer to also reject non-bit 4 signaling blocks as customary with earlier softforks

This would increase disruption during mandatory signalling as there would be potentially more orphans, this would not likely be an issue for larger pools but for smaller miners that aren't keeping up with recent changes.

This removes the risk of the hardfork causing a chainsplit (unless miners would run a new implementation which maliciously reuses bit 4 as SegWit-only)

It's trivial for any miner to false signal, in fact many effectively already do since they hard code version bits in their stratum servers.

By extension, this removes the need for replay protection

It does not since we've already established that it's impossible to prevent false signalling.

It eliminates the inconsistency that only non-SegWit miners are forced to upgrade.

Maintaining backwards compatibility as much as possible and minimizing disruption should be a goal.

attempting compatibility with (some) miners seems to have more drawbacks than benefits as it increases the risks of the hardfork

It does not, and it would have been preferable if we could avoid a mandatory signalling period, unfortunately there's just no realistic technical way we could do that at 80% hashpower without waiting for the existing segwit deployment to expire.

[tomasvdw]

This would increase disruption during mandatory signalling as there would be potentially more orphans, this would not likely be an issue for larger pools but for smaller miners that aren't keeping up with recent changes.

Well, the 40% non-Core miners will also have to upgrade and otherwise also increase orphan rate. Why would this not be a problem for them, but would it be a problem for the 30% SegWit-only miners?

It's trivial for any miner to false signal, in fact many effectively already do since they hard code version bits in their stratum servers.

There is quite a difference between a chainsplit because some miners did not upgrade, or a chainsplit caused by maliciously (and openly) false flagging bit 4 without actually following the SegWit2X specification

The first is likely, the latter is not really realistic due to its destructive nature. Why would miners want to cause such damage?

[jameshilliard]

There is quite a difference between a chainsplit because some miners did not upgrade, or a chainsplit caused by maliciously false flagging bit 4 without actually following the SegWit2X specification

You're intentionally trying to make a HF coercive, that's the complete wrong approach as it would only encourage false signalling.

The first is likely, the latter is not really realistic due to its destructive nature. Why would miners would want to cause such damage?

You're looking at this all completely wrong, the HF should be done cleanly and in a way that minimizes disruption as much as possible. The hard fork should be something users will want to upgrade to because it improves things, it should not be something they are forced into, by design bitcoin is highly resistant to coercive tactics like that.

[kek-coin]

@tomasvdw there is absolutely no point to signalling bit4 after BIP91 locks in.

1. BIP9 was intentionally designed to let version bits be reused; forcing them to stay occupied completely messes up that mechanism. Is there any rationale behind this?

2. It does not help S2X in any way; the hardfork activation logic - as far as I am aware - goes something along the lines of "IFF segwit has been active for 3 months -> hardfork". Doesn't even require bit4 signalling to have reached 80% ever.

3. Fake-signalling bit4 is trivially easy. You are not forcing anyone to upgrade this way.

Why would miners want to cause such damage?

Are you forgetting that they already have done exactly this in the past?

[tomasvdw]

You're intentionally trying to make a HF coercive, that's the complete wrong approach as it would only encourage false signaling.

Of course. Any softfork is coercive for the minority miners, but we want to make SegWit2X coercive; not just SegWit. Coercion (by risking losses) of the minority is why we have a functional consensus system.

IMO false signaling is a red herring. Bit signaling is not just technical, and a miner that would signal a bit defined as spec X, but have his node behaves as spec Y would be very destructive. No miner would benefit from such destructive behavior, as miners benefit from seeking consensus .

BIP9 was intentionally designed to let version bits be reused;

You can just enforce signaling until the hardfork.

It does not help S2X in any way; the hardfork activation logic - as far as I am aware - goes something along the lines of "IFF segwit has been active for 3 months -> hardfork". Doesn't even require bit4 signalling to have reached 80% ever.

It does help S2X as it prevents a chain split. Why would anyone be against that?

Why would we require the ~70% non-segwit miners to upgrade but the ~30% segwit miners not, if this so clearly increases the risks of a chain split?

From the first commits by Jeff Garzik, we've seen changes that accommodate non upgrading BIP141 nodes (with BIP91), and non upgrading BIP148 nodes (with the fast activation). But if we want SegWit2X to be successful we should instead encourage upgrading, especially for miners.

Frankly, I get the impression that @jameshilliard and @kek-coin, you are both primarily aiming at SegWit activation, not the success of SegWit2X.

[jameshilliard]

Any softfork is coercive for the minority miners, but we want to make SegWit2X coercive; not just SegWit.

The goal is to minimize coerciveness of soft forks as much as is technically possible. Soft fork features in general are designed to be as optional as realistically possible for both users and miners, we do sometimes have to make trade-offs however for technical reasons. BIP91 only has a mandatory signalling period because there's not a technical way to lower the activation threshold unless we wait for the existing segwit deployment to expire. If we could lower the segwit activation threshold without a mandatory signalling period we would have done that instead.

IMO false signaling is a red herring. Bit signaling is not just technical, and a miner that would signal a bit defined as spec X, but have his node behaves as spec Y would be very destructive. No miner would benefit from such destructive behavior, as miners benefit from seeking consensus

Lets assume there are some miners that are not wanting/intending to follow the HF, if forced to signal bit4 they now have no other option than to false signal because otherwise their blocks will be orphaned. This behavior wouldn't be considered destructive, it would just them considered protecting themselves. If signalling is optional then it is much more likely the miner will signal accurately.

It does help S2X as it prevents a chain split. Why would anyone be against that?

Because it doesn't at all, it gives a false sense of security and very likely would make things worse as any miners that intend to reject the HF would be forced to false signal.

Why would we require the ~70% non-segwit miners to upgrade but the ~30% segwit miners not, if this so clearly increases the risks of a chain split?

The mandatory signalling is only there at all because there are no other realistic technical options.

But if we want SegWit2X to be successful we should instead encourage upgrading, especially for miners.

We should avoid being coercive as much as possible and instead try and make the fork as desirable as possible. Use the carrot not the stick.

[drunkenclam]

Why would we require the ~70% non-segwit miners to upgrade but the ~30% segwit miners not, if this so clearly increases the risks of a chain split?

If there are >0% miners NOT signalling bit 4 or bit 1, BIP141 Segwit miners risk building blocks on those not signalling blocks, while the majority of miners is orphaning those blocks. Segwit miners have to upgrade as well, or at least use a Segwit2x or BIP148 border node.

[jameshilliard]

Segwit miners have to upgrade as well, or at least use a Segwit2x or BIP148 border node.

A BIP148 border node would not be enough as it doesn't contain BIP91.

[tomasvdw]

@jameshilliard I believe that the risk of some <20% splitting the chain with false flagging is much smaller than <20% splitting the chain by not updating their software.

But I guess our difference here is more ideological than technical.

I will leave this open for the segwit2x team to either close or adopt.

[jameshilliard]

I believe that the risk of some <20% splitting the chain with false flagging is much smaller than <20% splitting the chain by not updating their software.

Clearly the best solution would be to decouple BIP91 activation from the HF as I've recommend, making BIP91 activation coupled was clearly a political decision that makes it harder to determine actual support for the HF by itself.

[tomasvdw]

I don't understand what you are saying. There is already a proposal for SegWit decoupled from the HF. It has only 30% mining support. How is that the best solution?

This issue and repository is about SegWit2X, which is SegWit and a 2mb HF.

[jameshilliard]

There is already a proposal for SegWit decoupled from the HF.

I'm saying there should be separate activation for BIP91 and for the HF, because the decisions will be separate no matter what.

It has only 30% mining support.

It's much higher than that, it was just being used as a bargaining chip.

How is that the best solution?

Because the decisions are inherently decoupled regardless of if you use the same activation bit or not. Hard fork activation simply does not work the same way as soft fork activation does technically.

[Pheromon]

I agree: Core is now quiet because btc1 will allow them to have segwit enabled even with their client, and that's all they want. After that, they will start to complain about the HF and take every chance of ruining it: they don't want to increase the block size, ever. And they will succed this time too. You'll see.

[jameshilliard]

I agree: Core is now quiet because btc1 will allow them to have segwit enabled even with their client, and that's all they want.

Core has been pretty much universally opposed to segwit2x publicly https://en.bitcoin.it/wiki/Segwit_support so clearly they aren't being quiet.

[kek-coin]

Frankly, I get the impression that @jameshilliard and @kek-coin, you are both primarily aiming at SegWit activation, not the success of SegWit2X.

No, I am pointing out that your proposal doesn't actually help with anything. The only measurable difference it would make is add more crud to the code making the code review stage that much harder. Bloating the diff will only serve to make this project's code less attractive and therefore make S2X success chance lower.

[Pheromon]

Yes, they are already opposing the block size increase since now but they are not vocal yet, because they know that it's good that S2X starts: they would get segwit even for users running Core.

And since core will not merge S2X, all the users running it will fork themselves on the date of the HF activation: you'll see they will become more vocal after segwit is activated and they'll start every kind of FUD to avoid people to run other bitcoin clients.

[kek-coin]

This forum (github) is not for political discussion, it is for technical discussion about and contribution to the Segwit2X project. Furthermore, the position of developers of different projects are irrelevant to the technical merits (or lack thereof) of mandatory bit4 signalling. Please stay ontopic.

[JaredR26]

This forum (github) is not for political discussion, it is for technical discussion about and contribution to the Segwit2X project.

@kek-coin Can you point to anything technical that you have contributed or even discussed that wasn't directly related to your political goals?

A discussion about signaling is inherently political, as are any discussions about divorcing the hardfork from the segwit activation. This project is for the combined hardfork and segwit activation, not independently. Moreover, there are essentially no technical reasons to be opposed to the hardfork's small increase. I'm sure you and @jameshillard and others would disagree with that statement, and some people would agree with that statement, including technical people with experience. And that is entirely my point - The opposition to the hardfork itself is political, just like the support for it.

So stop decrying political discussion in one breath and opposing the hardfork in the other. As far as viable arguments against this, I only see one: It may encourage miners to falsely signal even though they will not accept the hardfork. This is offset by one of the intended advantages - it forces miners to take action and thus may encourage them to make an informed decision prior to the hardfork, which will be attempted and cannot be stopped.

A chainsplit is inevitable given the opposition that core has presented for political reasons. I think mandatory bit4 signaling would be a good thing to add to reduce the damage that will be caused by the coming chainsplit, even if it does have some downsides.

The hard fork should be something users will want to upgrade to because it improves things, it should not be something they are forced into,

@jameshillard I've seen you say this a lot, and I don't mean to discount your efforts with BIP91 compatibility here, but have you actually made any contributions, proposals, or suggestions to the hardfork itself (rather than the activation, signaling, or BIP148/BIP141 compatibility)? Because as many times as you've said that, if you haven't done the latter then those would seem to be empty words. I'm asking because I legitimately don't know if you have and I simply missed it.

[jameshilliard]

Moreover, there are essentially no technical reasons to be opposed to the hardfork's small increase. I'm sure you and @jameshillard and others would disagree with that statement, and some people would agree with that statement, including technical people with experience. And that is entirely my point - The opposition to the hardfork itself is political, just like the support for it.

The size itself is far from the biggest issue though, it's just not feasible to properly test/review a HF in 3 months. This is an issue even if everyone supports the HF.

it forces miners to take action and thus may encourage them to make an informed decision prior to the hardfork, which will be attempted and cannot be stopped

Except every major miner already has to take action unless they want to risk orphan blocks.

A chainsplit is inevitable given the opposition that core has presented for political reasons. I think mandatory bit4 signaling would be a good thing to add to reduce the damage that will be caused by the coming chainsplit, even if it does have some downsides.

How would it reduce damage? We've established that it would make signalling meaningless in regards to indicating actual HF support, I can't see how that's a good thing.

I've seen you say this a lot, and I don't mean to discount your efforts with BIP91 compatibility here, but have you actually made any contributions, proposals, or suggestions to the hardfork itself (rather than the activation, signaling, or BIP148/BIP141 compatibility)?

I've been involved in plenty of HF development in the past, I've flown to meetings with other developers to discuss parameters and other aspects of how one would do a HF properly, ultimately ideas from those discussions were incorporated into forks such as spoonnet. So yes I've made plenty of effort in regards to doing a HF properly.

[JaredR26]

it's just not feasible to properly test/review a HF in 3 months

I don't read this as a technical issue. It could be - but we'd need specific concerns and examples, and a specific timeline and path for resolution of those. So far I haven't seen anything like that.

And even if that were true, then it would behoove everyone to chip in to help as much as possible. If just prior to the hardfork we all come up short and feel that it isn't properly tested, an emergency deployment by miners can extend the timeline.

Except every major miner already has to take action unless they want to risk orphan blocks.

Not if mining with default coinbase settings with recent versions of Bitcoin core, or if they are already choosing to signal segwit.

How would it reduce damage? We've established that it would make signalling meaningless in regards to indicating actual HF support, I can't see how that's a good thing.

I don't agree that we've established that. As @tomasvdw stated, the risks of false signaling are far lower and far less of an issue than the risks of us winding up with two viable Bitcoin chains.

It would reduce damage by, as I stated, requiring the miners to take more specific action as it relates to segwit2x, even if they have already taken action in relation to segwit-only. That action will increase awareness and encourage people to get off the fence, even if they decide to falsely signal for a time.

So yes I've made plenty of effort in regards to doing a HF properly.

Thank you for putting in your time. Have you or can you bring those specific suggestions to the table here in this repo, so we can begin building a less-controversial hardfork? Even if the suggestions can't fit in the timeline, discussing them can't hurt and may provide more motivations for a structured delay of the 3 month timeline that concerns you.

[jameshilliard]

I don't read this as a technical issue. It could be - but we'd need specific concerns and examples, and a specific timeline and path for resolution of those. So far I haven't seen anything like that.

First of all many issues won't be discovered until testing, because of that a specific timeline is difficult, there are likely many unknown unknowns involved, I'd estimate ~1 year for a full testing/development cycle based on past issues encountered. Integration testing and upgrade of all software that interacts with bitcoind would also take quite a bit of time. On top of that one needs to give nodes time to upgrade, based on past trends we're probably looking at 6 months there at a minimum but likely closer to a year to be on the safe side. 3 months for activation + ~1 month development before code is rolled out is completely unrealistic if we expect the HF to be safe and properly tested.

Not if mining with default coinbase settings with recent versions of Bitcoin core, or if they are already choosing to signal segwit.

It's explained already in BIP91 that miners need to upgrade.

As @tomasvdw stated, the risks of false signaling are far lower and far less of an issue than the risks of us winding up with two viable Bitcoin chains.

That logic doesn't make much sense, if miners have the choice of signalling one way or the other they are more likely to signal actual intentions, forcing them to signal one way or the other means they have no option but to false signal if they intend to not follow the HF.

It would reduce damage by, as I stated, requiring the miners to take more specific action as it relates to segwit2x, even if they have already taken action in relation to segwit-only. That action will increase awareness and encourage people to get off the fence, even if they decide to falsely signal for a time.

They already have to take action for BIP91 compatibility.

Have you or can you bring those specific suggestions to the table here in this repo, so we can begin building a less-controversial hardfork? Even if the suggestions can't fit in the timeline, discussing them can't hurt and may provide more motivations for a structured delay of the 3 month timeline that concerns you.

I've suggested basing the HF off of spoonnet as a starting point which deals with a lot of the issues.

[kek-coin]

@JaredR26

@kek-coin Can you point to anything technical that you have contributed or even discussed that wasn't directly related to your political goals?

All of my argumentation on the github issues is based on technical reasons. I have done some minimal code review and pointed out issues I've spotted. I'm not sure what you think my political goals are, and I'm pretty sure that a statement from me won't convince you if you think I'm here for dishonest reasons, but can you at least agree that ranting about "core this core that waa waa core is ruining everything" is offtopic for a discussion about whether mandatory bit4 signalling is a good idea or not?

A discussion about signaling is inherently political, as are any discussions about divorcing the hardfork from the segwit activation. This project is for the combined hardfork and segwit activation, not independently. Moreover, there are essentially no technical reasons to be opposed to the hardfork's small increase. I'm sure you and @jameshillard and others would disagree with that statement, and some people would agree with that statement, including technical people with experience. And that is entirely my point - The opposition to the hardfork itself is political, just like the support for it.

I'm not sure why you feel like strawmanning my opinion (it's not the blocksize increase that primarily concerns me - and I assure you my concerns are technical in nature) or why you seem to think that "technical people with experience disagreeing with the statement that there are no technical reasons to be opposed to the hardfork's small increase" indicates political rather than technical opposition, but I'll tell you this; throwing aside people's concerns without giving them a chance to explain is a surefire way to give them a bad taste about this whole project and make it that much less motivating for them to try and help out.

Offtopic bullshit aside, I oppose the mandatory bit4 signalling idea because - in short - it fails to achieve any of the goals set out in OP while increasing the code surface and therefore the attack surface of the entire Bitcoin ecosystem. Point-by-point:

1. It doesn't remove any chainsplit risk because it increases the motivation/chances for false-signalling.
2. It doesn't remove the need for replay or wipeout protection - wipeout protection is better done by something like Bitmain's "must be big" requirement, replay protection can be done by unilateral coin-tainting by mixing with post-split coinbase dust (unilateral meaning it only has to happen on one chain, you'll want to do it on the hashrate-majority chain).
3. Segwit miners are already mandated to upgrade to make sure they don't build on top of malicious non-bit1-signalling blocks after enforcement of S2X begins.
4. Any unnecessary code will just clutter up the diff and make if harder to vet the code for any bugs/vulnerabilities, which is kinda fucking crucial when it comes to the software that is supposed to protect a multi-billion-dollar ecosystem.

[JaredR26]

I'd estimate ~1 year for a full testing/development cycle based on past issues encountered.

See, this is the reason I have trouble taking your contributions as a serious technical input rather than a politically motivated play. You're suggesting here that a simple +2mb hardfork change, which touches only a few lines of code and makes no structural changes to the system or its data is going to take longer than the full development cycle of Segwit took (November 2015 to September 13th 2016), touching 5k lines of code, changing structures, and simultaneously maintaining backwards compatibility despite massive system changes.

Are you really asserting that you think that the charter's 2x hardfork is going to take LONGER than that?

On top of that one needs to give nodes time to upgrade, based on past trends we're probably looking at 6 months

This situation is tremendously different than past trends on many levels, and the 84% committed hashrate is a strong forcing function to upgrade or suffer with a nearly unusable chain post-fork. Business support for the hardfork will further motivate a rapid upgrade.

Not if mining with default coinbase settings with recent versions of Bitcoin core, or if they are already choosing to signal segwit.

It's explained already in BIP91 that miners need to upgrade.

I find it funny that you are now effectively arguing against the exact same thing you argued in favor of 16 days ago. Which is it, miners should be forced to signal and that is not a big deal, or miners should not be forced to signal and orphaning is a big deal?

That logic doesn't make much sense, if miners have the choice of signalling one way or the other they are more likely to signal actual intentions, forcing them to signal one way or the other means they have no option but to false signal if they intend to not follow the HF.

Sure it does. If they don't want to follow the charter, they are welcome to activate segwit on their own, or start their own fork. If they want segwit, the charter is the only way. You keep trying to act like the two are distinct; They are not in this github, regardless of the popularity of the opinion anywhere else.

I started out tentatively disagreeing with this request as unnecessary, but you've convinced me; Bit1 and Bit4 mean the same thing within the bounds of this charter after lock-in. Bit1 signaling is mandatory to ensure compatibility with BIP148 and to ensure a successful launch, something you yourself strongly pushed for. You didn't raise any false signal objections to the bit1 false signaling; If people want to falsely signal support, that's their decision. Bit4 mandatory signaling can be done in the exact same fashion, and is not incompatible with BIP91, BIP148, or anything else. It is the best step towards fulfilling the objectives of the charter.

I've suggested basing the HF off of spoonnet as a starting point which deals with a lot of the issues.

Well that's something I guess, but without any indications of how to take spoonnet from the state it is in now to the point where it could fulfill the charter's objectives, I don't see how that really helps. I'm sure the timelines of the charter could be pushed slightly with sufficient justification, but vague commitments with timelines more than a year out are not going to fly.

concept ACK

[JaredR26]

but can you at least agree that ranting about "core this core that waa waa core is ruining everything" is offtopic for a discussion about whether mandatory bit4 signalling is a good idea or not?

It seems I misread what exactly you were responding to. My apologies.

"technical people with experience disagreeing with the statement that there are no technical reasons to be opposed to the hardfork's small increase" indicates political rather than technical opposition,

It seems to me that the exact line when a discussion crosses over from "technical" to "political" is difficult to define, and I (mistakenly) thought you were drawing that line in a way that was highly debatable. My point was that whenever rational, technical people having a discussion on a technical question could come to different conclusions, that is inherently somewhat "political," but it is still an on-topic technical discussion. Thus, some "political" discussion is fine.

I mistakenly thought you were drawing that line about Thomas's comments, not the one about the core developers. My bad.

throwing aside people's concerns without giving them a chance to explain is a surefire way to give them a bad taste about this whole project and make it that much less motivating for them to try and help out.

I agree with this statement, strongly. Though that does not mean that the final decisions should necessarily change.

It doesn't remove any chainsplit risk because it increases the motivation/chances for false-signalling.

I disagree with this point; Forcing people to take action over no action counterbalances the fast timelines that are a frequent concern with this project. A small amount of orphaning is a strong motivator for people to get informed and prepare for the coming chainsplit.

If people want to falsely signal, that is on them. If they want to activate segwit on their own without segwit2x, they are welcome to chainsplit and do so. If they choose to falsely signal and benefit from the segwit2x compromise, doing so should require them to intentionally signal the wrong thing before defecting, as the two cannot be decoupled under this charter. This has a psychological impact, which shouldn't be discounted - Most people are averse to lying, and if they do, most people are less likely to continue to lie when confronted on it. Far fewer people are averse to simply omitting information, which is what could happen if bit1 signaling is required but bit4 is not.

It doesn't remove the need for replay or wipeout protection

It isn't supposed to, that isn't the point of this suggestion.

Segwit miners are already mandated to upgrade to make sure they don't build on top of malicious non-bit1-signalling blocks after enforcement of S2X begins.

Bit1 signaling is required, something you pushed for very strongly, and got. Bit1 and Bit4 mean the same thing after lock in, under this charter(to miners). Why would you be opposed to requiring bit4, but strongly pushed for requiring bit1? It is compatible with all other BIP's or existing clients that I am aware of.

Any unnecessary code will just clutter up the diff and make if harder to vet the code for any bugs/vulnerabilities,

This is a valid point overall, but not really in light of the fact that bit1 signaling is already required. Requiring bit1 and bit4 signaling simultaneously adds almost no logic; a simple AND, or maybe a specific error message response about Bit4.

Since a chainsplit is going to be inevitable at hardfork time, anything that helps ease that is worthy of small tradeoffs, even if that thing is purely psychological. Psychology matters in consensus systems.

[jameshilliard]

You're suggesting here that a simple +2mb hardfork change, which touches only a few lines of code and makes no structural changes to the system or its data is going to take longer than the full development cycle of Segwit took (November 2015 to September 13th 2016), touching 5k lines of code, changing structures, and simultaneously maintaining backwards compatibility despite massive system changes.

No hard fork is simple, in fact many of the issues deal with during segwit development would also be issues for a "simple" hard fork.

Are you really asserting that you think that the charter's 2x hardfork is going to take LONGER than that?

For doing it properly with something like spoonnet yes, already requirements like replay and wipeout protection are being added to this project, that means more codepaths to test. Fact of the matter is this stuff just isn't simple, which is something one comes to realize after being closely involved in Bitcoin development.

This situation is tremendously different than past trends on many levels, and the 84% committed hashrate is a strong forcing function to upgrade or suffer with a nearly unusable chain post-fork. Business support for the hardfork will further motivate a rapid upgrade.

So the plan is to leave everyone else in the dust? Even with 100% support for the fork you'd be looking at serious disruption with the proposed HF timeline.

Which is it, miners should be forced to signal and that is not a big deal, or miners should not be forced to signal and orphaning is a big deal?

I'd prefer to not force miners to signal at all if we had a better option, BIP91 has a mandatory signalling period only out of necessity, I did however decide to add a lock-in period to mitigate the risk there.

If they don't want to follow the charter, they are welcome to activate segwit on their own, or start their own fork. If they want segwit, the charter is the only way. You keep trying to act like the two are distinct

They are distinct, that's just how the fork mechanics work.

If people want to falsely signal, that is on them.

Want and forced to are not the same thing.

Why would you be opposed to requiring bit4, but strongly pushed for requiring bit1?

Sigh...I don't like having to use mandatory signalling to lower the threshold...I just recognize that we live in a world of engineering realities and that is the best option we have without waiting for the existing deployment to expire.

This is a valid point overall, but not really in light of the fact that bit1 signaling is already required. Requiring bit1 and bit4 signaling simultaneously adds almost no logic.

This is not correct as BIP91 uses existing BIP9 fork activation code for the most part(with some minor tweaks), the proposed mandatory bit4 signalling would not really be able to reuse the code in the same way.

Since a chainsplit is going to be inevitable at hardfork time, anything that helps ease that is worthy of small tradeoffs, even if that thing is purely psychological. Psychology matters in consensus systems.

Trying to coerce people will only make them less likely to support the fork.

[jheathco]

I agree 100% with JaredR26 re testing. To compare the testing needs/timeframe of a 2MB HF to that of SegWit is ridiculous. While a HF would require serious live testing, from a code review standpoint it's night and day being that it touches very few lines of code.

[kek-coin]

@JaredR26

You are accusing me of bringing politics into github when you are the one that treats activation mechanism as psyop tools. Do you realize the irony?

It isn't supposed to, that isn't the point of this suggestion.

Well that's funny because OP says

• By extension, this removes the need for replay protection

[JaredR26]

No hard fork is simple, in fact many of the issues deal with during segwit development would also be issues for a "simple" hard fork.

Dealing with them a second time around is still easier than the first.

Fact of the matter is this stuff just isn't simple, which is something one comes to realize after being closely involved in Bitcoin development.

Asserting that stuff is simple is very different from asserting that A is simpler than B. I did the latter, and you are implying that I said the former; This project is not currently anywhere near as complicated as Segwit, and will not require anywhere near as much development and testing time.

So the plan is to leave everyone else in the dust? Even with 100% support for the fork you'd be looking at serious disruption with the proposed HF timeline.

I didn't write the charter, and if I did, I wouldn't have written it the way it is now. But it is far far better than the rut we've been stuck in for 2 years now, and it is going to proceed as outlined there. So yes, there will be a disruption; All we can do is try to minimize the impact of that disruption.

They are distinct, that's just how the fork mechanics work.

Without segwit2x, segwit wouldn't activate without splitting the chain. Since the goal is to avoid splitting the chain and get Bitcoin un-stuck, the coupled agreement is the only option. Wishing it were otherwise will not make it so, but trying to make it otherwise will cause the chainsplit to be much worse.

Want and forced to are not the same thing.

As I said, they're free to fork at that time if they wish for segwit without segwit2x and don't want to lie with their signals. Obviously they won't. Also obviously, the hardfork is going to happen; The only thing we can do about it is mitigate the damage it causes. Trying to bolster the arguments against the hardfork which has less than a 16% minority is not a mitigation, it is an amplification.

I just recognize that we live in a world of engineering realities and that is the best option we have without waiting for the existing deployment to expire.

We also live in a world with a consensus reality that requires other people to agree with you. Decoupled segwit-only will not achieve that, and attempting to force it to be decoupled is going to worsen the chainsplit.

Trying to coerce people will only make them less likely to support the fork.

Sorry, were you talking about BIP148 or the censorship on the bitcoin forums/communities? I'm confused.

[JaredR26]

You are accusing me of bringing politics into github when you are the one that treats activation mechanism as psyop tools. Do you realize the irony?

"Psychology" and "psyop" have different meanings and implications. So to be clear, you are of the opinion that psychology is irrelevant to a consensus system that is decided by humans?

It isn't supposed to, that isn't the point of this suggestion.

Well that's funny because OP says

By extension, this removes the need for replay protection

Ah, right you are(again!), I missed that. See, I'm finding lots of things to agree with you on today. I don't actually agree with that statement at all; Replay protection is a separate issue entirely. I still believe the psychological impacts are more than worth the small tradeoffs of bit4 signaling.

[kek-coin]

So to be clear, you are of the opinion that psychology is irrelevant to a consensus system that is decided by humans?

No.

Are you of the opinion that coercing people into picking between lying and kneeling is likely to lead to the latter? Mandatory bit1 and bit4 signalling are inherently incomparable because bit1 signalling triggers BIP141 to activate in ~85% of the network, whereas bit4 signalling only matters to miners, which would have had to make a choice already anyway - signal bit1 and enforce mandatory bit1 signalling or risk being orphaned.

[JaredR26]

Are you of the opinion that coercing people into picking between lying and kneeling is likely to lead to the latter?

So basically what BIP148 is trying to do?

I am of the opinion that that small amount of potential-but-probably-irrelevant coercion would be far less damaging than allowing a small group of vocal die-hard libertarians to endanger a $45 billion dollar ecosystem.

Mandatory bit1 and bit4 signalling are inherently incomparable because bit1 signalling triggers BIP141 to activate in ~85% of the network, whereas bit4 signalling only matters to miners,

Exactly, it only matters to miners. It in no way interferes with any other BIP, just like if signaling on bit 6 were required instead. If you really want we could discuss a plan where bit4 could mean "I am aware of segwit2x and will follow it" and bit5 signaling could mean "But I won't support the hardfork." Whatever you want to call it. But bit4 requires action, and is specific enough to encourage informed action. If someone signals on bit4 and not bit5, that should mean they are explicitly aware of the coming hardfork and that they do not intend to reject it, whereas bit5 could mean they are aware of it but do intend to reject it.

But required Bit4 signaling is needed and beneficial.

[kek-coin]

So basically what BIP148 is trying to do?

What part of BIP148 lets people lie?

But required Bit4 signaling is needed and beneficial.

It is really not needed and I have serious doubts about its benefits (although I don't blame you for seeing that last part differently). Mandatory bit1 signalling is necessary to be backwards compatible with the current segwit deployment; mandatory bit4 signalling really isn't necessary at all; it is signalling for the sake of signalling, without any consequence beyond the signalling.

The hardfork is going to happen anyway, regardless of signalling. So by then (the hardfork date) miners will have to have chosen what software to run, regardless of what bits were signalled 3 months ago. If that is not strong enough of a psychological factor, then some mandatory fake-or-real-you-choose signalling on bit4 isn't going to help.

[jameshilliard]

Dealing with them a second time around is still easier than the first.

Sure, but there's still a lot of testing needed and there are plenty other issues as well that need to be dealt with across the ecosystem.

This project is not currently anywhere near as complicated as Segwit, and will not require anywhere near as much development and testing time.

IMO doing it correctly would have similar complexity. Sure you can cut corners but that has the potential to cause major issues.

I didn't write the charter, and if I did, I wouldn't have written it the way it is now. But it is far far better than the rut we've been stuck in for 2 years now, and it is going to proceed as outlined there. So yes, there will be a disruption; All we can do is try to minimize the impact of that disruption.

The charter says 6 months...which would still be rushed for a HF but would be significantly better than the proposed 3 months.

Without segwit2x, segwit wouldn't activate without splitting the chain. Since the goal is to avoid splitting the chain and get Bitcoin un-stuck, the coupled agreement is the only option. Wishing it were otherwise will not make it so, but trying to make it otherwise will cause the chainsplit to be much worse.

It's clear that there will be a chain split with the current HF proposal, the best we can do is make sure that happens as cleanly as possibly with minimal disruption. Trying to force everyone to follow it is counterproductive.

As I said, they're free to fork at that time if they wish for segwit without segwit2x and don't want to lie with their signals. Obviously they won't. Also obviously, the hardfork is going to happen; The only thing we can do about it is mitigate the damage it causes. Trying to bolster the arguments against the hardfork which has less than a 16% minority is not a mitigation, it is an amplification.

You mitigate damages by trying to make the HF as clean and voluntary as possible, not by trying to force people to go along with it.

We also live in a world with a consensus reality that requires other people to agree with you. Decoupled segwit-only will not achieve that, and attempting to force it to be decoupled is going to worsen the chainsplit.

Other people are only required to agree with you if your intention is to stay on the same chain. It's not a matter of trying to force it to be decoupled, it fundamentally is decoupled simply due to forking mechanics.

Sorry, were you talking about BIP148 or the censorship on the bitcoin forums/communities? I'm confused.

The whole idea behind BIP148 is that it is user making a choice in regards to which blocks they accept and the resultant market forces making it the most valuable chain. There's no requirement in BIP148 that forces miners to mine segwit transactions, the only requirement is that activation logic is triggered so that other miners are able to. Bitcoin is not a democracy, it's individual voluntary choice, changes IMO should be made so that they are as optional and opt-in as technically possible.

[jli225]

@jameshilliard I beg to differ. No one can force you since you have already made decision, but this project has the obligation to inform those people who have been negatively affected by censorship what the roadmap of the economic majority, hashrate majority and user majority is. Thus we can mitigate the risk of chain split.

Anyway, no one tries to force you. Bitcoin is a voluntary ecosystem. You or anyone can fork to anything at anytime. No one has the ability to force you on the same chain. If you dislike SegWit2X, you can fork to have a SegWit only version today.

Anyway, this is the SegWit2X project. Don't have the illusion that you can seperate the SegWit part from the Hard Fork part.

[hmsln]

@jli225 Separating the HF part from the SW part isn't a political move, but a technical one: binding them together in the code needlessly complicates the Segwit2X implementation (thus making it harder to test and deploy in the short amount of times that we have) without any real benefit (as it would be trivial for any miner to change its software after Segwit activation to remain on the non-forking branch in case of an ulterior hard fork).

Another aspect to grasp is that it is impossible to guarantee that all the economy (holders, traders, merchants and miners) all proceed with the HF. There will be a split if the HF proceeds, the only question is: how big will the non-forking branch be? If the HF brings consensual features, then it might just be a few inattentive miners and nodes who were not following the debates and did not upgrade (and perhaps a few die hards opponents) - not a big deal. If the features brought by the HF are contentious, on the other hand, you might well see an economically significant number of users stay on the non-forked branch - this would be a very serious split.

Even the Core developers have said that a HF would be needed at some point, and you should not underestimate the chances of a sane, well-planned, well-reviewed, well-tested HF proposal to have quasi-anonymous approval. We can do this, but we will need time.

[Pheromon]

Even the Core developers have said that a HF would be needed at some point Yes, they're telling that since many years, with the only intention to destroy momentum of other sw actually trying to do it. Their plan is to never do it to augment block size.

[jli225]

@hmsln I appreciate your good intent, but I suggest you inform yourself by reading much more diffent viewpoints. For example, @Pheromon just told you something different. You don't need to believe it. But at least you shall compare it with the previous story you learnt.

Also, if you think it's techincal, then we are now trying to mitigate the risk of chain split technically. Bitcoin is censorship-resistant money. Concept ACK.

[HostFat]

@tomasvdw I think that it is anyway a good idea to make the PR, even if it will not be included on segwit2x, so that other devs can evaluate it and maybe some miners can embrace it on their code.

[earonesty]

@jameshilliard

I've suggested basing the HF off of spoonnet as a starting point which deals with a lot of the issues.

If this sort of HF, possibly with a more gradual size increase (17%/year for 10 years), had been submitted as a pull req to core with a 12-18 month timeline to core, it would probably have been merged by now.

@JaredR26

I am of the opinion that that small amount of potential-but-probably-irrelevant coercion

Vocal proponents of hard-forking could have easily paid someone to work on a spoonet fork. "Coercion" to use hasty and generally reviled code is not nearly as effective. I was a fan of doing this for a bit, and I asked around, and got all the consensus I needed from a number of devs. I just .... never got around to it.

The problem is I only cared in a vague theoretical way. I hold, I use, but I'm never bothered by fees personally - or even ideologically... When faced with engineering and a lot of time spent simulating and figuring out how to get the python testing framework to work the way I wanted it to... I was like "too lazy", and sort of let my branch lay fallow.

You have to understand that this is how real open source works. If nobody cares about it that much, it doesn't get focus. Thing is... some of the most vocal proponents of hard forking do have money.... and none of them (apparently) is willing to pony up for a full time dev for the 6 months or so it would take for them to work on it.

Which, to me, smacks of some weird double-standard. "Yes we want bigger blocks", but "No we don't want to pay someone to work on it properly".

[JaredR26]

Vocal proponents of hard-forking could have easily paid someone to work on a spoonet fork.

You have to understand that this is how real open source works. If nobody cares about it that much, it doesn't get focus. Thing is... some of the most vocal proponents of hard forking

Maybe in January 2015 it worked like that. I'm sure you think that BitcoinXT, Classic, BU were all created just because some people were too lazy to do it the right way? And they were censored in every forum because all three were simply bad through and through?

Several of the prominent current devs have stated that they will continue to block any non-segwit blocksize increases under any conditions for the forseeable future, regardless of community support because they know better than everyone else. At least two of the prominent current devs have basically said they will pull a Mike Hearn if the 2x hardfork successfully activates.

I have several ideas and proposals that I've wanted to bring up for months, and would be willing to begin working on. I haven't brought them up on bitcoin-dev, and won't, because the current environment is simply too toxic and they would be rejected or ignored almost immediately. And I'm not the only one.

I've had rational, well-thought out posts be moderated to bitcoin-dev, and I've had rational, unoffensive, well-thought out posts removed from other forums frequently because a small group of individuals did not like what I was saying. Censorship in a consensus system has consequences, hence the last 2 years.

and none of them (apparently) is willing to pony up for a full time dev for the 6 months

I find it funny that you state this here. This is precisely what segwit2x is, the only point of disagreement supposedly is the timeline, though without any hard data to back that opposition.

So since we're here right now, discussing very nearly the same thing you said needs to be done... How many core devs do not explicitly oppose segwit2x? Have any of them given clear evidence that the timeline cannot be achieved? Open your eyes man. The way you think the world should work and the way it has been since mid 2015 are not the same.

[jli225]

@jaredR26 Thank you for speaking out the truth. You are not alone. Thank you.

[booung]

@JaredR26

Several of the prominent current devs have stated that they will continue to block any non-segwit blocksize increases under any conditions for the forseeable future, regardless of community support because they know better than everyone else.

I dont think they have exactly 'stated' that if so source please. That sounds more like what you think core want. I think core want to rollout the only well tested properly peer reviewed solution segwit first, then start working on other solutions and when they are peer reviewed, coded, and tested roll them out. Software development\deployment shouldn't be rushed especially for something worth $40B

I have several ideas and proposals that I've wanted to bring up for months, and would be willing to begin working on. I haven't brought them up on bitcoin-dev, and won't, because the current environment is simply too toxic and they would be rejected or ignored almost immediately. And I'm not the only one.

Peer review can be harsh but if enough people think its a good idea it would be accepted. Just because you have an idea doesn't mean it is good and should be accepted.

[jli225]

@booung

if enough people think its a good idea it would be accepted.

Glad to see that you got it eventually. Moreover, you could conveniently delete "if". It's exactly why the Bitcoin community majority came here to initiate SegWit2X project.

I also agree that just because current Core Committee has an idea doesn't mean it is good and should be accepted by Bitcoin community. It's common sense that the roadmap of current Core has been rejected by Bitcoin community, because the interest of current Core is opposite of Bitcoin community's.

Any Core Committee member, whether being full-time paid coder/reddit-twitter-spokesman by Blockstream or not, is still welcome to be involved in the new Bitcoin reference version project. However, any of their proposals must pass the peer-review procedure in this decentralized group. Peer review can be harsh but if enough people think its a good idea it would be accepted. Actually, the necessary procedures shall be peer reviewed, coded, and tested roll them out.

Some Core Committee members shall be reminded that actions like a shrew shouting abuses in the street are no longer allowed. That is, they are no longer allowed to spam lies to slander Satoshi, Gavin, Mike Hearn, Coinbase, Bitmain, Bitpay, and so many Bitcoiners.

@Peter Todd (Today): An endless list of dishonest people like Hearn, Andresen...

Such ill-bred behavior shall no longer be encouraged in the new reference version group. The continuance of toxic atmosphere is intolerable. We shall remind ourselves not to be another Core Committee where those self-righteous Blockstream-related guys saw their view above Bitcoin community's and recklessly slandered Bitcoiners regularly while other devs were indifference.

As for me, the 1-line-change hard fork part shall be tested at least one month. Better to have three months. And the contentious SegWit part such as the ridiculous 75% discount and abnormal BC1 SW address format shall be changed to be more appropriate in the future after enough test. Such a 3000-lines-change shouldn't be rushed especially for something worth $40B, even after it's activated being certain ransom.

[JaredR26]

@booung

Several of the prominent current devs have stated that they will continue to block any non-segwit blocksize increases under any conditions for the forseeable future, regardless of community support because they know better than everyone else.

I dont think they have exactly 'stated' that if so source please. That sounds more like what you think core want.

Luke-jr: "No block size increase is likely to be needed in the near future." From: https://goo.gl/CWb2pM

Greg Maxwell: Q: "Do you foresee any hard-fork proposal ever being merged into Bitcoin Core in the future?" A: "There is basically no ethical change that can't be done via a softfork except changes to the POW."

And earlier:

"Bitcoin is fine the way it is-- it could be even better, but it doesn't need to" From: https://goo.gl/ABZtni

Luke and Greg's comments were both recent. Going back a little further in time:

Wladimir van der Laan: "A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions. I’m afraid increasing the blocksize will kick this can down the road and let people (and the large Bitcoin companies) relax, until it’s again time for a block chain increase" From: https://goo.gl/EjGpHS

Matt Corrallo: "Personally, I'm rather strongly against any commitment to a block size increase in the near future." https://goo.gl/sj7Wdu

Peter Todd: "But then again, changing the blocksize is setting precedent that we're willing to change an economic parameter too." (Appears to be IRC logs from early July, 2013, added to the blockchain: https://bitcoinstrings.com/blk00281.txt)

I haven't found anything to indicate any of those people have changed their views since then, but all of the people listed are opposed to segwit2x.

I did find many example of everyone except Luke stating in the past that they would support a "small increase" with "very broad consensus." Segwit2x is one of the smallest increases to be proposed in the history of this debate, and appears to have 90% of the miners supporting it and at least 50% of the major businesses in the community. Actions speak louder than words; None of the people who said they would support "small increases" with "wide support" are actually doing so. Instead they are attacking this project from every angle they can think of; the BIP proposal thread right now is laughable and awful, and I doubt many segwit2x supporters are going to wade into that if any do.

It is also interesting to note that segwit2x is almost identical to the HK 2016 agreement that was signed by Luke-jr, Peter Todd, Matt Corallo, Johnson Lau, and James Hilliard. Of those people, James may support this; All of the others oppose it. Actions speak louder than words.

Peer review can be harsh but if enough people think its a good idea it would be accepted. Just because you have an idea doesn't mean it is good and should be accepted.

You don't think there's something odd when every single proposal or proponent from one side of the debate gets ignored, attacked, insulted, or dragged through reddit's censorship-driven mudslinging to the point where they quit posting and contributing altogether? That's normal for decentralized development?

[gmaxwell]

@JaredR26

Greg Maxwell: Q: "Do you foresee any hard-fork proposal ever being merged into Bitcoin Core in the future?" A: "There is basically no ethical change that can't be done via a softfork except changes to the POW."

The "quote" you give of me at without a link is a incorrect edited quotation: Here is the link https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/diwr5lc/

Do you foresee any hard-fork proposal ever being merged into Bitcoin Core in the future? If Core will only ever merge soft-forking changes from here on out, then Core is going to be supplanted.

I do but I also disagree. There is basically [...]

I continued below:

as I said I think there will be hardforks in the future

Were you merely ignorantly copying someone elses dishonesty, if so please provided a link now, or is this your original work?

Edit: @jgarzik I understand this project has a "real name" policy ( https://twitter.com/AaronvanW/status/882213865798471685 ), I would appreciate knowing JaredR26's "real name". Or is does this policy only apply to parties that might be critical of your efforts?

[mpatc]

Greg, rather than drag us even further in the mud, can you clarify your current positions on things like this project, segwit2x, and a near-future 2mb hard fork in general? The referenced quote is an old r/bitcoin post; much less relevant than your words here and now. I honestly don't know where you stand on these things. Please, enlighten us.

It seems easier and more appropriate (in this forum) than assuming bad faith. That's what reddit is for, right?

On Jul 9, 2017 4:43 PM, "Gregory Maxwell" notifications@github.com wrote:

@JaredR26 https://github.com/jaredr26

Greg Maxwell: Q: "Do you foresee any hard-fork proposal ever being merged into Bitcoin Core in the future?" A: "There is basically no ethical change that can't be done via a softfork except changes to the POW."

The "quote" you give of me at without a link is a extremely dishonest edited quotation: Here is the link https://www.reddit.com/r/ Bitcoin/comments/6h612o/can_someone_explain_to_mewhy core_wont_endorse/diwr5lc/

Do you foresee any hard-fork proposal ever being merged into Bitcoin Core in the future? If Core will only ever merge soft-forking changes from here on out, then Core is going to be supplanted.

I do but I also disagree. There is basically [...]

I continued below:

as I said I think there will be hardforks in the future

Were you merely ignorantly copying someone elses dishonesty, if so please provided a link now, or is this your original work?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/btc1/bitcoin/issues/40#issuecomment-313953317, or mute the thread https://github.com/notifications/unsubscribe-auth/APNcvou-xSTtUXiEBVYPN_yX63DmAed0ks5sMTtggaJpZM4OA6ww .

[gmaxwell]

@mpatc I believe this project is ill-advised and unethical. Like almost every other developer who has supported and grown the system since 2011 I do not support it ( https://en.bitcoin.it/wiki/Segwit_support ). I also don't care about it-- like Bitcoin XT, Classic, and soon to be Unlimited, this repository will become abandonware when its undisclosed sponsors stop funding it. I have elaborated on my views a number of times previously: https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/divtc93/

I raised the above because I was directed here by someone who was concerned that I was probably being misquoted. To the extent that I'm not being smeared here I have no interest in this repository.

[tomasvdw]

Can we please keep the discussions on-topic of the issue at hand? These discussions make the issues unreadable.

[JaredR26]

I would appreciate knowing JaredR26's "real name".

Considering I've emailed on Bitcoin-dev from my real name and emailed you personally with the same, and 10 seconds on google would find all about me, I think you're just trying to distract from the issue at hand. You're very good at that, so props on that.

The "quote" you give of me at without a link is a incorrect edited quotation:

The quote I gave aligns with your actions even if your words do not. But fortunately, they do, since you said you disagree with the hardfork but think it will happen; My statement was about what you oppose, and you oppose all hardforks.

if so please provided a link now, or is this your original work?

It was mine, go ahead and send your attackers now.

Like almost every other developer who has supported and grown the system since 2011 I do not support it ( https://en.bitcoin.it/wiki/Segwit_support ).

You state almost every developer since 2011 and then you link to a list of developers that, by RULE, only includes developers who have committed something to bitcoin in the last 12 months, (7 months after everyone who disagreed with you gave up and quit) and only applies that rule to developers who disagree with the 5-shades-of-green desired narrative. You should be ashamed of yourself for posting such deceit.

when its undisclosed sponsors stop funding it.

The sponsors are fully disclosed publicly.

[jli225]

@gmaxwell Hey Gregory Maxwell, please curb yourself from being abusive to others. At least please hide your name. It's annoying to see the surname of James Clerk Maxwell whom I admire so much being stigmatized. Hey Gregory Maxwell, don't be abusive to others.

Glad to know that you realized the current Core Committee is ill-advised and unethical and it became an echo chamber after everyone who disagreed with you gave up and quit.

You were caught slandering Satoshi, Gavin and Mike Hearn regularly in chats among Core Committee members. I don't care if you feel ashamed. Please curb yourself and tell your colleague not to be so shameless. Hey Gregory Maxwell, don't be abusive to others.

The era of Core Committee has gone over. Its current representative, known as Bitcoin Judas, should repent of the evil that has been done to the community.