[consensus] SegWit2x signalling on bit 4 #6
Conversation
|
This part is missing |
|
@jameshilliard It's not missing; That was removed intentionally. SegWit2x uses different signaling logic than BIP 91. |
| // multiple, the last one is used. | ||
| bool fHaveWitness = false; | ||
| if (VersionBitsState(pindexPrev, consensusParams, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_ACTIVE) { | ||
| if (VersionBitsState(pindexPrev, consensusParams, Consensus::DEPLOYMENT_SEGWIT2X, versionbitscache) == THRESHOLD_ACTIVE) { |
There was a problem hiding this comment.
This would partition the p2p network due to the unexpected-witness DOS ban .
There was a problem hiding this comment.
Isn't BIP91 futile because of the doubling of the block size? I would think that existing installations would need to upgrade to SEGWIT2X signaling anyway.
There was a problem hiding this comment.
What do you mean by "futile"? Segwit is a significant technical upgrade to Bitcoin, not just a blocksize increase.
Because BIP91 is a soft-fork, existing segwit nodes (~80% of the P2P network) are in no particular rush to upgrade, as BIP91 is backwards compatible with segwit.
There was a problem hiding this comment.
I understand, but I would assume SEGWIT2X signalling includes SegWit and a hardfork block size doubling as per the agreement. I don't understand how that can be made compatible with these 80% of the nodes.
There was a problem hiding this comment.
BIP91 can be rolled out essentially immediately by miners, any HF will take many months of development testing and deployment. I see no reason why we should delay SegWit especially since it's easier to activate a HF is SegWit has already been activated.
There was a problem hiding this comment.
@tomasvdw I don't think major changes should be coupled together unless there are technical reasons to do so. We should deploy in a decoupled manner as it's clearly much simpler and safer to do so in that way, that is clearly evident from this PR which would have caused an unintentional network partition(and there are likely still issues that would cause major network problems).
There was a problem hiding this comment.
@jameshilliard + @deadalnix : i think it's OK to couple these changes, as long as they are compatible. HF lock-in should happen on BIT1 activation... not BIT4 activation. This prevents the situation where an HF locks in and an SF doesn't... and vice versa. Any other activation criteria seems disingenuous.
There was a problem hiding this comment.
HF locking in on bit 1 activation would mean segwit could be activated while <80% support Segwit2x. I don't think that's consistent w/ Segwit2x's intent. Better to make HF lock-in depend on bit 4, while making that HF contingent on segwit activating earlier - I believe this is how Sergio's Segwit2MB worked. That way:
- Segwit2x doesn't break old BIP141 nodes
- HF can't happen w/o segwit
- Neither activates unless Segwit2x reaches 80%
- Segwit activation is easier, b/c it gets bit 1 support from both Segwit2x & old BIP141 nodes
There was a problem hiding this comment.
would a simple solution be
after soft segwit enables,
the later Hard consensus event is then to simply remove the math cludge which separated the witness. to then just have a single block of 4mb where all serialised tx's sit in the exact same 1 merkle area without any of the / 4 or *2 math manipulation, and where none of the 'stripping'/'filtering' code cludge would be needed either, due to all nodes being updated anyway
There was a problem hiding this comment.
the "math kludge" is actually a really important feature designed to reduce utxo bloat and simplify pruning. witness should be separated. ideally, after a hard fork, there would be no other kind of transaction. or at least the legacy transactions would remain limited to 1mb, by weighting them more.
|
NACK. This pull request is quite odd. First commits are for activating the current deployment of Segwit using BIP91, next commits remove that to attempt activating something else (Segwit2x? What is that?) which seems like it would split the p2p network. Is this a wanted outcome? It's not clear what this fork is trying to achieve, nor how does this pull request gets us there. Is there a BIP describing any of that? |
|
There are still no tests. |
|
What's the rational for being incompatible with segwit? |
|
NACK, incompatible with current segwit deployment and missing tests. |
| NODE_BLOOM = (1 << 2), | ||
| // NODE_WITNESS indicates that a node can be asked for blocks and transactions including | ||
| // witness data. | ||
| NODE_WITNESS = (1 << 3), |
There was a problem hiding this comment.
Why are you confusingly re-using the same name?
There was a problem hiding this comment.
It might make more sense to define a new version bit, like in the BIP149 reference implementation:
bitcoin/bitcoin@master...shaolinfry:uasegwit-flagday#diff-1df47808b82268c616535e7b20216dfbR272
There was a problem hiding this comment.
If this is intended to replace the existing segwit sf then why would it be confusing?
There was a problem hiding this comment.
I think the fact that the names of these constants are being used by explorers and tools to render service flags is enough reason to use a different name (NODE_WITNESS2X), to ensure consistency.
There was a problem hiding this comment.
When this activates, those bits will become dead code.
Consider the picture of the network six months after this activates, when SegWit2X (and therefore segwit) is active.
The long term view implies avoiding dragging early artifacts into long term code.
Cosmetically renaming the symbol is, of course, no problem.
There was a problem hiding this comment.
@jgarzik Is this being proposed for release only after the existing deployment expires? Please also provide technical rational for not being backwards compatible with BIP141.
|
The output goal of the SegWit2x working group is to couple signaling and activation of segwit with the signaling/activation of a base block size increase. That is the core charter. Solutions inside that charter are heartily welcomed. Solutions incompatible with that charter cannot be used. Thanks to @jameshilliard , @tomasvdw and @petertodd for their constructive comments and feedback so far. |
|
@jgarzik Using BIP91 style activation can still be linked to a HF activation, you can make the HF activation codepath dependent on BIP141 activation and have bit 4 trigger both BIP91 and a lock in a future HF at the same time, that's still far simpler and safer than trying to redeploy BIP141 since you then only have one activation codepath to test for. |
|
"What's the rational for being incompatible with segwit?" @petertodd The first-pass goal is creating code that matches the NYC agreement. (Admittedly a non-answer) The high level charter is meeting the plainly stated "segwit AND 2m_base_blksz" outcome by coupling the two (rather than fully decoupled). So the real answer is that we want to be maximally compatible with segwit within the bounds of the charter - a safe network upgrade to segwit-AND-2m. Post-hashpower-activation segwit2x will be the only segwit, for all intents and purposes, so deviations pre-activation would simply be legacy code post-. |
|
@jgarzik The NYC agreement does not say anywhere that it needs to be incompatible with BIP141, you can do a coupled activation using dual lock in of BIP91 and HF while still being compatible until the HF activation flag day(I don't think the timeline for testing a HF is realistic but that would still be safer than trying to redeploy BIP141). |
|
@jameshilliard Right; As noted in another comment, the compatibility goal is "maximally compatible with segwit within the bounds of the charter" |
|
@jgarzik So why are you trying to redeploy BIP141 then, just lock in BIP91 at the same time as the HF using bit 4 and make sure the HF requires BIP141 to be active. |
|
@jameshilliard What about false flagging to achieve SegWit only? I understand that false flagging is always possible, but with a separate SEGWIT2X it is difficult and destructive as it would require redefining bit 4 as SegWit only. When using BIP91, this is as simple as temporarily setting bit 4, so any miner mining SEGWIT2X would effectively yet involuntarily also support SegWit only. If we propose SegWit + HF, wouldn't it be best if all nodes can consciously decide to use this package or not, instead of having existing SegWit nodes "limp in" only to be kicked off when the HF occurs? |
|
@tomasvdw Ultimately individuals can flag and accept whatever blocks they want. If there ends up being significant false flagging then that would indicate that the HF part is undesirable and should not be deployed. It is best to have upgrades split up where it makes sense technically, I don't think it's a good idea to couple SW and HF activation, but doing that with BIP91 is still far better than trying to do a full redeployment. If the HF ends up being unacceptable by itself then there should not be any reason to deploy it tied to another proposal. This is why I've advocated for doing the HF part properly(something along the lines of spoonnet and with appropriate testing) so that it has a reasonable chance of community adoption. Making a proposal worse by intentionally breaking backwards compatibility will not increase its chance of adoption. |
|
@jgarzik Have you actually discussed this with other signers of the Barry Agreement? Is this work you're doing under contract for it? After all there seems to be disagreement about what the agreement actually is, with at least three very different interpretations re: segwit and a HF. |
Then they will have to decide amongst themselves, I am no one. I am simply pointing out the risks when there is a clear intention by numerous parties not to follow through with the HF.
If that is truly the case then the WG will either need the non-segwit supporters to agree to it, or else they will need to modify the agreement so that segwit ONLY comes with the HF. Simply tricking the non-segwit supporters isn't going to work. |
I thought it was pretty clear that those risks are there regardless.
It already says simultaneous deployment, BIP91+HF fits just fine there. |
Do you think core or the community would accept BIP91 (or COOP) if completely combined with a hardfork at the activation instant? If so, that would probably work, the difficulty would be in testing and releasing BIP91+HF before segwit bit1 times out in November, 5 months. Unless core wanted to simply extend BIP141 in a release between now and then and encourage users to upgrade. That could probably get consensus if core were on board because it fulfills the spirit of the charter(if not the letter, i.e. the unavoidable delays). |
That's not technically feasible without significantly delaying segwit activation.
This also can't be done safely until after the existing deployment expires Let's be perfectly clear, for technical reasons making the proposal incompatible with the existing segwit deployment means we would have to delay activation until after the existing deployment expires, I don't think you will get much support for that. |
I see no reason why it would be any different to signal on any given bit before November 15th than after it, since segwit was designed to be backwards compatible, but we've already established that I know nothing about segwit specifics, so I'll take your word for it. That still puts us at an impasse. I don't think a bit1 signaling process makes most users follow the defection side of the coming contentious hardfork is going to keep the support of the anti-segwit miners who agreed to the charter. You don't think that the core/community support will materialize without that. I don't see anything in between without rewriting the charter, which neither of us could possibly hope to do. |
That's explained here in BIP91, it's mostly p2p related.
The problem is that you're thinking about this in the wrong way, you're trying to come up with ways to force users to follow the HF and not trying to make the HF better so that they will want to upgrade to it. |
We can't even come up with ways to make segwit good enough that more than 71% of them want to upgrade to it. Like I've said, I like segwit. How the hell are we going to do that for a hardfork? There's no way man. No way. I'm not going to try to work the impossible. If you find a hardfork that both Jihan Wu and Luke Jr would accept simultaneously I'll be on the next plane to shake your hand and buy you a beer, hell, I'll buy you a whole bar. Because that's basically what it would take. There is a way to get the desired 80%+ consensus on segwit, though. That is segwit+HF. It is the only way I see. Anything else and the opposition fork is going to have 25-35% of the community and miners, if not more. |
This is the exact sort of attitude that has us in this mess in the first place, if you refuse to even try and work together I really don't see what else you can expect.
Most of the disagreement isn't over the HF itself but about timelines and development process.
You're talking about 80%+ of miners, getting that is much different from getting 80%+ of the community. That will require the fork being done properly IMO. |
I'm here aren't I? You gotta give me credit for trying. Similarly, I'm glad you're still discussing this, even if everyone else just wants me to shut up. (Sorry!) If there is a path forward, I'd love to find it.
Not between Jihan Wu and Luke Jr. Jihan Wu wants larger blocks, much much bigger. Luke Jr wants smaller blocks. That's why I picked those two, they represent the polar opposite extremes that absolutely will not compromise. Neither side represented by them are smaller than 20% of the community, so without them you cannot have an 80% consensus. I genuinely do not believe there is a way those two sides would compromise together. |
Trying what, exactly? What is your goal here, @JaredR26? If it is to derail technical discussion and stand in the way of progress then you are being very successful. |
Luke Jr is not outright against a block size increase if it's sensible.
If you think Luke Jr will never compromise on anything then clearly you have no understanding of what his position even is. |
I don't believe that. I think Luke Jr. compromised with segwit; That was the compromise struck between the moderates and the small block factions. It just repulsed the big block faction at the same time. Segwit is a proxy war; Segwit is not the problem, the problem is big blockers vs small blockers. The small blockers are afraid any HF sets a precedent that will inevitably lead to more. The big blockers believe segwit sets a precedent that scaling can be done by pushing it off-chain, which they believe is not aligned with Bitcoin and will allow nearly any altcoin to overtake it when Bitcoin gets full. If what you're saying is true, all we have to do is get Luke Jr and Jihan Wu on the same page. Well, and Maxwell would have to agree with Luke, and Roger with Jihan, but once those 4 agreed, everything else would fall into place because the respective communities would follow as well(begrudgingly). You can tell me it is possible all day long; I'll believe what I see and have seen. |
Maybe if we had more cooperation out in the open then that could happen. I'm not saying it's an easy disagreement to solve but if you want to make any progress you first need to actually have an idea what the actual disagreement is. |
Well, I laid it all out for you. I really believe segwit is a proxy war. The real dispute is between the big blockers and the small blockers. You see /r/bitcoin constantly blaming Jihan and BU for blocks being full, but Jihan and BU WANT blocks to be much, much bigger, so why would small blocks be their problem? Its their problem because Segwit was the compromise struck with the small blockers, and the big blockers got left in the dark. That's why core, mostly small blockers who support segwit, are so intensely opposed to segwit2mb, specifically to the HF portion of it(The big blockers from core, Gavin, Mike, etc already left). It has nothing to do with timelines or activation or any of that garbage, we could work through all that, but the real issue will remain. The HF portion of segwit2mb removes the entire concession that the small blockers won with segwit, which was no blocksize increase, and it establishes the possible precedent that the small blockers are terrified of. (And it is a leap of up to 8x in one step, another small blocker fear) Timelines and activation are a distraction from the core issue. Most of the last two years are a distraction from the core issue. But there it is. |
They are being blamed for stalling progress.
Except SegWit isn't the end...it's one step among many that will be needed to scale bitcoin.
They seem to mainly be opposed because they see it as a stalling tactic to keep SegWit from being activated. There are other reasons such as having an unrealistic development and activation timeline as well.
We've tried time and time again to work through those without making any real progress. Those are absolutely real issues.
Development process along with timelines and activation are really the biggest issues right now. You've been sold a narrative that is just not accurate. |
|
@JaredR26 You claim to like segwit, but you have no idea of how it works and claim there is no blocksize increase incorporated into it but at the same time claim that segwit2x (not segwit2mb, by the way) is a 8x increase - implying that segwit is a 4x increase. You are either trolling or just hopelessly out of your depth here. |
No one sold me anything. I read what each side was saying, and I talked to them. Really talked to them and paid attention to specifically what they said and what their actions said.
Re-read what you wrote. If you've tried time and time again to work through something and failed, maybe the thing you were trying to solve wasn't the real problem. Anyway, it doesn't matter. We're way off track into conspiracy theory territory now, I can't prove any of my theories. If core isn't onboard with the +2mb hardfork, but the WG still believes that is the deal, there will be a contentious fork when we reach activation date. The code needs to prepare for that possibility thoroughly to mitigate the damage that will cause. |
I never ever said that, anywhere. I'm fully aware that segwit has a blocksize increase. I said that the big blockers did not get the precedent of a blocksize increase, meaning hardfork base size.
This time it is you that is wrong and should admit it and apologize, lets see if you actually do. Segwit is up to a 4x increase because maxblockweight is 4mb. So segwit2x could theoretically be an 8x increase. This is not how the big blockers see it because it is unlikely to actually be usable for 4x the size of a normal block, and does not help their precedent needs. This is how the small blockers view it because it heightens their fears and supports their position. |
|
I typed out a long post countering you point-for-point but deleted it. This is not reddit, this is not your or my soapbox, this is not the place for you to speak on behalf of Luke and Jihan, this is a forum for technical discussion and review. Please refrain from derailing any further. |
Didn't think so. |
|
I agree @jameshilliard that these changes should be decoupled as much as possible and I'm not sure why some people here expect that a more complex solution which combines two politically hard discussed changes will have even more consensus in the community, than one of these changes alone? To be serious: The best way forward would be to actviated SegWit right now with Bit1 and normal BIP9 procedure, which also let miners save their faces - and then do a HF when it's code is written, well reviewed and tested with Spoonnet, which has already received a lot of research (seeh here: https://bitcoinhardforkresearch.github.io/). I also think that we can add a lot of other small fixes to a HF beside the blocksize and I think many people and also core developers agree, that a HF is fine - when it's ready for production. |
|
@jacob-eliosoff coop proposal and garzik's proposal are similar. But the coop proposal contains tech to ensure that the minority chain dies, and is replay safe, contains new code that has broad appeal, and has more support. Yes, code review would be longer. But consensus would be more likely. |
|
@earonesty What's your source on @jgarzik's proposal? The changes in this github seem like just first steps, and I have no other source. For all I can see Jeff's intent may just be COOP (which I'm happy with too, depending on timing). |
|
Following the next-steps described in point 1 of #6 (comment) , closing this PR. Will re-open new PR that builds on top of commits in PR #1 |
c521b3ac6 Merge btc1#11: fixup define checks. Cleans up some oopses from btc1#5. 8b1cd3753 fixup define checks. Cleans up some oopses from btc1#5. 6b1508d6d Merge btc1#6: Fixes typo fceb80542 Merge btc1#10: Clean up compile-time warnings (gcc 7.1) 0ec2a343f Clean up compile-time warnings (gcc 7.1) d4c268a35 Merge btc1#5: Move helper functions out of sse4.2 object 8d4eb0847 Add HasAcceleratedCRC32C to port_win.h 77cfbfd25 crc32: move helper functions out of port_posix_sse.cc 4c1e9e016 silence compiler warnings about uninitialized variables 495316485 Merge btc1#2: Prefer std::atomic over MemoryBarrier 2953978ef Fixes typo f134284a1 Merge btc1#1: Merge upstream LevelDB 1.20 ba8a445fd Prefer std::atomic over MemoryBarrier git-subtree-dir: src/leveldb git-subtree-split: c521b3ac654cfbe009c575eacf7e5a6e189bb5bb
20 participants
Incorporates and supercedes #1