New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[consensus] SegWit2x signalling on bit 4 #6

Closed
wants to merge 11 commits into
base: segwit2x
from

Conversation

@jgarzik

jgarzik commented May 29, 2017

Incorporates and supercedes #1

shaolinfry and others added some commits May 8, 2017

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard May 29, 2017

This part is missing

jameshilliard commented May 29, 2017

This part is missing

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik May 29, 2017

@jameshilliard It's not missing; That was removed intentionally. SegWit2x uses different signaling logic than BIP 91.

jgarzik commented May 29, 2017

@jameshilliard It's not missing; That was removed intentionally. SegWit2x uses different signaling logic than BIP 91.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard May 29, 2017

@jgarzik This will conflict with the existing deployment, see here for why you can't do a full redeployment until the existing deployment expires.

jameshilliard commented May 29, 2017

@jgarzik This will conflict with the existing deployment, see here for why you can't do a full redeployment until the existing deployment expires.

@@ -3040,7 +3047,7 @@ bool ContextualCheckBlock(const CBlock& block, CValidationState& state, const Co
// {0xaa, 0x21, 0xa9, 0xed}, and the following 32 bytes are SHA256^2(witness root, witness nonce). In case there are
// 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) {

This comment has been minimized.

@jameshilliard

jameshilliard May 29, 2017

This would partition the p2p network due to the unexpected-witness DOS ban .

@jameshilliard

jameshilliard May 29, 2017

This would partition the p2p network due to the unexpected-witness DOS ban .

This comment has been minimized.

@tomasvdw

tomasvdw May 29, 2017

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.

@tomasvdw

tomasvdw May 29, 2017

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.

This comment has been minimized.

@petertodd

petertodd May 29, 2017

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.

@petertodd

petertodd May 29, 2017

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.

This comment has been minimized.

@tomasvdw

tomasvdw May 29, 2017

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.

@tomasvdw

tomasvdw May 29, 2017

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.

This comment has been minimized.

@jameshilliard

jameshilliard May 29, 2017

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.

@jameshilliard

jameshilliard May 29, 2017

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.

This comment has been minimized.

@jameshilliard

jameshilliard May 29, 2017

@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).

@jameshilliard

jameshilliard May 29, 2017

@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).

This comment has been minimized.

@earonesty

earonesty May 30, 2017

@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.

@earonesty

earonesty May 30, 2017

@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.

This comment has been minimized.

@jacob-eliosoff

jacob-eliosoff May 31, 2017

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:

  1. Segwit2x doesn't break old BIP141 nodes
  2. HF can't happen w/o segwit
  3. Neither activates unless Segwit2x reaches 80%
  4. Segwit activation is easier, b/c it gets bit 1 support from both Segwit2x & old BIP141 nodes
@jacob-eliosoff

jacob-eliosoff May 31, 2017

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:

  1. Segwit2x doesn't break old BIP141 nodes
  2. HF can't happen w/o segwit
  3. Neither activates unless Segwit2x reaches 80%
  4. Segwit activation is easier, b/c it gets bit 1 support from both Segwit2x & old BIP141 nodes

This comment has been minimized.

@MickSHunt

MickSHunt Jun 1, 2017

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

@MickSHunt

MickSHunt Jun 1, 2017

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

This comment has been minimized.

@earonesty

earonesty Jun 8, 2017

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.

@earonesty

earonesty Jun 8, 2017

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.

@udiWertheimer

This comment has been minimized.

Show comment
Hide comment
@udiWertheimer

udiWertheimer May 29, 2017

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?

udiWertheimer commented May 29, 2017

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?

@deadalnix

This comment has been minimized.

Show comment
Hide comment
@deadalnix

deadalnix May 29, 2017

There are still no tests.

deadalnix commented May 29, 2017

There are still no tests.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd May 29, 2017

What's the rational for being incompatible with segwit?

petertodd commented May 29, 2017

What's the rational for being incompatible with segwit?

@Vaesper

This comment has been minimized.

Show comment
Hide comment
@Vaesper

Vaesper May 29, 2017

Incorporates and supercedes #1

How can you claim this if you have selectively stripped out the defining feature of #1, which is the BIP91 logic?

Vaesper commented May 29, 2017

Incorporates and supercedes #1

How can you claim this if you have selectively stripped out the defining feature of #1, which is the BIP91 logic?

@lichtamberg

This comment has been minimized.

Show comment
Hide comment
@lichtamberg

lichtamberg May 29, 2017

NACK, incompatible with current segwit deployment and missing tests.

lichtamberg commented May 29, 2017

NACK, incompatible with current segwit deployment and missing tests.

Show outdated Hide outdated src/protocol.h
@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik May 29, 2017

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 commented May 29, 2017

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.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard May 29, 2017

@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.

jameshilliard commented May 29, 2017

@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.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik May 29, 2017

"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 commented May 29, 2017

"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-.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard May 29, 2017

@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 commented May 29, 2017

@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).

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik May 29, 2017

@jameshilliard Right; As noted in another comment, the compatibility goal is "maximally compatible with segwit within the bounds of the charter"

jgarzik commented May 29, 2017

@jameshilliard Right; As noted in another comment, the compatibility goal is "maximally compatible with segwit within the bounds of the charter"

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard May 29, 2017

@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 commented May 29, 2017

@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.

@tomasvdw

This comment has been minimized.

Show comment
Hide comment
@tomasvdw

tomasvdw May 30, 2017

@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 commented May 30, 2017

@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?

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard May 30, 2017

@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.

jameshilliard commented May 30, 2017

@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.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd May 30, 2017

@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.

petertodd commented May 30, 2017

@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.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 4, 2017

I am simply pointing out the risks when there is a clear intention by numerous parties not to follow through with the HF.

I thought it was pretty clear that those risks are there regardless.

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.

It already says simultaneous deployment, BIP91+HF fits just fine there.

jameshilliard commented Jun 4, 2017

I am simply pointing out the risks when there is a clear intention by numerous parties not to follow through with the HF.

I thought it was pretty clear that those risks are there regardless.

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.

It already says simultaneous deployment, BIP91+HF fits just fine there.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

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).

JaredR26 commented Jun 4, 2017

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).

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 4, 2017

Do you think core or the community would accept BIP91 (or COOP) if completely combined with a hardfork at the activation instant?

That's not technically feasible without significantly delaying segwit activation.

Unless core wanted to simply extend BIP141 in a release between now and then and encourage users to upgrade.

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.

jameshilliard commented Jun 4, 2017

Do you think core or the community would accept BIP91 (or COOP) if completely combined with a hardfork at the activation instant?

That's not technically feasible without significantly delaying segwit activation.

Unless core wanted to simply extend BIP141 in a release between now and then and encourage users to upgrade.

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.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

This also can't be done safely until after the existing deployment expires

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.

JaredR26 commented Jun 4, 2017

This also can't be done safely until after the existing deployment expires

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.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 4, 2017

I see no reason why it would be any different to signal on any given bit before November 15th than after it

That's explained here in BIP91, it's mostly p2p related.

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.

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.

jameshilliard commented Jun 4, 2017

I see no reason why it would be any different to signal on any given bit before November 15th than after it

That's explained here in BIP91, it's mostly p2p related.

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.

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.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

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.

JaredR26 commented Jun 4, 2017

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.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 4, 2017

No way. I'm not going to try to work the impossible.

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.

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.

Most of the disagreement isn't over the HF itself but about timelines and development process.

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.

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.

jameshilliard commented Jun 4, 2017

No way. I'm not going to try to work the impossible.

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.

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.

Most of the disagreement isn't over the HF itself but about timelines and development process.

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.

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.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

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.

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.

Most of the disagreement isn't over the HF itself but about timelines and development process.

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.

JaredR26 commented Jun 4, 2017

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.

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.

Most of the disagreement isn't over the HF itself but about timelines and development process.

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.

@kek-coin

This comment has been minimized.

Show comment
Hide comment
@kek-coin

kek-coin Jun 4, 2017

You gotta give me credit for trying.

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.

kek-coin commented Jun 4, 2017

You gotta give me credit for trying.

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.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 4, 2017

Luke Jr wants smaller blocks.

Luke Jr is not outright against a block size increase if it's sensible.

That's why I picked those two, they represent the polar opposite extremes that absolutely will not compromise.

If you think Luke Jr will never compromise on anything then clearly you have no understanding of what his position even is.

jameshilliard commented Jun 4, 2017

Luke Jr wants smaller blocks.

Luke Jr is not outright against a block size increase if it's sensible.

That's why I picked those two, they represent the polar opposite extremes that absolutely will not compromise.

If you think Luke Jr will never compromise on anything then clearly you have no understanding of what his position even is.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

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.

JaredR26 commented Jun 4, 2017

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.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 4, 2017

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.

jameshilliard commented Jun 4, 2017

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.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

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.

JaredR26 commented Jun 4, 2017

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.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 4, 2017

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?

They are being blamed for stalling progress.

Its their problem because Segwit was the compromise struck with the small blockers, and the big blockers got left in the dark.

Except SegWit isn't the end...it's one step among many that will be needed to scale bitcoin.

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).

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.

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.

We've tried time and time again to work through those without making any real progress. Those are absolutely real issues.

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.

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.

jameshilliard commented Jun 4, 2017

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?

They are being blamed for stalling progress.

Its their problem because Segwit was the compromise struck with the small blockers, and the big blockers got left in the dark.

Except SegWit isn't the end...it's one step among many that will be needed to scale bitcoin.

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).

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.

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.

We've tried time and time again to work through those without making any real progress. Those are absolutely real issues.

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.

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.

@kek-coin

This comment has been minimized.

Show comment
Hide comment
@kek-coin

kek-coin Jun 4, 2017

@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.

kek-coin commented Jun 4, 2017

@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.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

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.

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.

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.

We've tried time and time again to work through those without making any real progress.

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.

JaredR26 commented Jun 4, 2017

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.

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.

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.

We've tried time and time again to work through those without making any real progress.

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.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

and claim there is no blocksize increase incorporated into it

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.

but at the same time claim that segwit2x (not segwit2mb, by the way) is a 8x increase - implying that segwit is a 4x increase.

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.

JaredR26 commented Jun 4, 2017

and claim there is no blocksize increase incorporated into it

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.

but at the same time claim that segwit2x (not segwit2mb, by the way) is a 8x increase - implying that segwit is a 4x increase.

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.

@kek-coin

This comment has been minimized.

Show comment
Hide comment
@kek-coin

kek-coin Jun 4, 2017

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.

kek-coin commented Jun 4, 2017

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.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Jun 4, 2017

This time it is you that is wrong and should admit it and apologize, lets see if you actually do.

Didn't think so.

JaredR26 commented Jun 4, 2017

This time it is you that is wrong and should admit it and apologize, lets see if you actually do.

Didn't think so.

@lichtamberg

This comment has been minimized.

Show comment
Hide comment
@lichtamberg

lichtamberg Jun 4, 2017

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.

lichtamberg commented Jun 4, 2017

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.

@earonesty

This comment has been minimized.

Show comment
Hide comment
@earonesty

earonesty Jun 5, 2017

@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 commented Jun 5, 2017

@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.

@jacob-eliosoff

This comment has been minimized.

Show comment
Hide comment
@jacob-eliosoff

jacob-eliosoff Jun 5, 2017

@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).

jacob-eliosoff commented Jun 5, 2017

@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).

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Jun 5, 2017

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

jgarzik commented Jun 5, 2017

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

@jgarzik jgarzik closed this Jun 5, 2017

@JaredR26 JaredR26 referenced this pull request Jun 6, 2017

Merged

2M base block size increase #11

@gavinandresen

This comment has been minimized.

Show comment
Hide comment
@gavinandresen

gavinandresen Jun 12, 2017

Failing tests can be fixed with:

diff --git a/qa/rpc-tests/p2p-compactblocks.py b/qa/rpc-tests/p2p-compactblocks.py
index 9151ecf5d..42bdadaa0 100755
--- a/qa/rpc-tests/p2p-compactblocks.py
+++ b/qa/rpc-tests/p2p-compactblocks.py
@@ -123,7 +123,7 @@ class CompactBlocksTest(BitcoinTestFramework):

         # Start up node0 to be a version 1, pre-segwit node.
         self.nodes = start_nodes(self.num_nodes, self.options.tmpdir,
-                [["-debug", "-logtimemicros=1", "-bip9params=segwit:0:0"],
+                [["-debug", "-logtimemicros=1", "-bip9params=segwit:0:0", "-bip9params=segwit2x:0:0"],
                  ["-debug", "-logtimemicros", "-txindex"]])
         connect_nodes(self.nodes[0], 1)

diff --git a/qa/rpc-tests/p2p-segwit.py b/qa/rpc-tests/p2p-segwit.py
index 479f1c679..9451780dd 100755
--- a/qa/rpc-tests/p2p-segwit.py
+++ b/qa/rpc-tests/p2p-segwit.py
@@ -203,7 +203,7 @@ class SegWitTest(BitcoinTestFramework):
         connect_nodes(self.nodes[0], 1)

         # Disable segwit's bip9 parameter to simulate upgrading after activation.
-        self.nodes.append(start_node(2, self.options.tmpdir, ["-debug", "-whitelist=127.0.0.1", "-bip9params=segwit:0:0"]))
+        self.nodes.append(start_node(2, self.options.tmpdir, ["-debug", "-whitelist=127.0.0.1", "-bip9params=segwit:0:0", "-bip9params=segwit2x:0:0"]))
         connect_nodes(self.nodes[0], 2)

     ''' Helpers '''

gavinandresen commented on 687b3cd Jun 12, 2017

Failing tests can be fixed with:

diff --git a/qa/rpc-tests/p2p-compactblocks.py b/qa/rpc-tests/p2p-compactblocks.py
index 9151ecf5d..42bdadaa0 100755
--- a/qa/rpc-tests/p2p-compactblocks.py
+++ b/qa/rpc-tests/p2p-compactblocks.py
@@ -123,7 +123,7 @@ class CompactBlocksTest(BitcoinTestFramework):

         # Start up node0 to be a version 1, pre-segwit node.
         self.nodes = start_nodes(self.num_nodes, self.options.tmpdir,
-                [["-debug", "-logtimemicros=1", "-bip9params=segwit:0:0"],
+                [["-debug", "-logtimemicros=1", "-bip9params=segwit:0:0", "-bip9params=segwit2x:0:0"],
                  ["-debug", "-logtimemicros", "-txindex"]])
         connect_nodes(self.nodes[0], 1)

diff --git a/qa/rpc-tests/p2p-segwit.py b/qa/rpc-tests/p2p-segwit.py
index 479f1c679..9451780dd 100755
--- a/qa/rpc-tests/p2p-segwit.py
+++ b/qa/rpc-tests/p2p-segwit.py
@@ -203,7 +203,7 @@ class SegWitTest(BitcoinTestFramework):
         connect_nodes(self.nodes[0], 1)

         # Disable segwit's bip9 parameter to simulate upgrading after activation.
-        self.nodes.append(start_node(2, self.options.tmpdir, ["-debug", "-whitelist=127.0.0.1", "-bip9params=segwit:0:0"]))
+        self.nodes.append(start_node(2, self.options.tmpdir, ["-debug", "-whitelist=127.0.0.1", "-bip9params=segwit:0:0", "-bip9params=segwit2x:0:0"]))
         connect_nodes(self.nodes[0], 2)

     ''' Helpers '''

@jameshilliard jameshilliard referenced this pull request Jun 23, 2017

Closed

Hard fork on Block X #29

@Kixunil

This comment has been minimized.

Show comment
Hide comment
@Kixunil

Kixunil Jul 1, 2017

Why June 1st? Shouldn't this be July 1st? Or possibly later, given that full (stable) version isn't released yet.

Kixunil commented on src/chainparams.cpp in e4b207f Jul 1, 2017

Why June 1st? Shouldn't this be July 1st? Or possibly later, given that full (stable) version isn't released yet.

hovah pushed a commit to hovah/bitcoin that referenced this pull request Aug 11, 2017

Squashed 'src/leveldb/' changes from 196962ff0..c521b3ac6
c521b3ac6 Merge #11: fixup define checks. Cleans up some oopses from #5.
8b1cd3753 fixup define checks. Cleans up some oopses from #5.
6b1508d6d Merge #6: Fixes typo
fceb80542 Merge #10: Clean up compile-time warnings (gcc 7.1)
0ec2a343f Clean up compile-time warnings (gcc 7.1)
d4c268a35 Merge #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 #2: Prefer std::atomic over MemoryBarrier
2953978ef Fixes typo
f134284a1 Merge #1: Merge upstream LevelDB 1.20
ba8a445fd Prefer std::atomic over MemoryBarrier

git-subtree-dir: src/leveldb
git-subtree-split: c521b3ac654cfbe009c575eacf7e5a6e189bb5bb

@jgarzik jgarzik deleted the 2017_segwit2x_signal branch Oct 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment