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

Disconnect network service bits 6 and 8 until Aug 1, 2018 #10982

Merged
merged 1 commit into from Aug 7, 2017

Conversation

Projects
None yet
@TheBlueMatt
Contributor

TheBlueMatt commented Aug 3, 2017

Immediately disconnect peers that use service bits 6 and 8 until August 1st, 2018
These bits have been used as a flag to indicate that a node is running incompatible
consensus rules instead of changing the network magic, so we're stuck disconnecting
based on the service bits, at least for a while.

Staying connected to nodes on other networks only prevents both sides from reaching consensus quickly, wastes network resources on both sides, etc.

Didn't add constants to protocol.h as the code there notes that "service bits should be allocated via the BIP process".

@TheBlueMatt TheBlueMatt changed the title from Disconnect network service bits 6 and 8 until Aug 1, 2018 to Disconnect network service bits 8 until Aug 1, 2018 Aug 3, 2017

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 3, 2017

Contributor

Updated to only disconnect bit 8 based on comments by the Bitcoin-ABC (bit 5 users) folks indicating they want to change their network magic to ensure good separation for their nodes. Based on the comments from the btc1 folks, I think we should consider merging this sooner rather than later.

Contributor

TheBlueMatt commented Aug 3, 2017

Updated to only disconnect bit 8 based on comments by the Bitcoin-ABC (bit 5 users) folks indicating they want to change their network magic to ensure good separation for their nodes. Based on the comments from the btc1 folks, I think we should consider merging this sooner rather than later.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 3, 2017

Contributor

It was pointed out that irrespecitve of whether Bitcoin-ABC changes their network magic to further split their nodes off from nodes wasting their resources, disconnecting nodes with bit 5 will only help their nodes and future Core nodes, so I went ahead and re-added that check.

Contributor

TheBlueMatt commented Aug 3, 2017

It was pointed out that irrespecitve of whether Bitcoin-ABC changes their network magic to further split their nodes off from nodes wasting their resources, disconnecting nodes with bit 5 will only help their nodes and future Core nodes, so I went ahead and re-added that check.

@TheBlueMatt TheBlueMatt changed the title from Disconnect network service bits 8 until Aug 1, 2018 to Disconnect network service bits 5 and 8 until Aug 1, 2018 Aug 3, 2017

@jheathco

This comment has been minimized.

Show comment
Hide comment
@jheathco

jheathco Aug 4, 2017

@TheBlueMatt any reason you started referring to bit 5 instead of bit 6? Looks like the PR still refers to bit 6 (as does master branch of ABC).

jheathco commented Aug 4, 2017

@TheBlueMatt any reason you started referring to bit 5 instead of bit 6? Looks like the PR still refers to bit 6 (as does master branch of ABC).

@TheBlueMatt TheBlueMatt changed the title from Disconnect network service bits 5 and 8 until Aug 1, 2018 to Disconnect network service bits 6 and 8 until Aug 1, 2018 Aug 4, 2017

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 4, 2017

Contributor

@jheathco heh, sorry, inconsistent 0base vs 1-base naming.

Contributor

TheBlueMatt commented Aug 4, 2017

@jheathco heh, sorry, inconsistent 0base vs 1-base naming.

@deadalnix

This comment has been minimized.

Show comment
Hide comment
@deadalnix

deadalnix Aug 4, 2017

deadalnix commented Aug 4, 2017

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 4, 2017

Contributor

@deadalnix awesome, sounds good. Note that its probably still a good idea for Core to do the disconnect-on-service-bit thing here as it just adds a second layer of ensuring the networks properly split and dont waste each others' resources.

Contributor

TheBlueMatt commented Aug 4, 2017

@deadalnix awesome, sounds good. Note that its probably still a good idea for Core to do the disconnect-on-service-bit thing here as it just adds a second layer of ensuring the networks properly split and dont waste each others' resources.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Aug 4, 2017

Member

I don't like the general idea since it burns a service bit unnecessarily, but since it's just for a year or so, and we don't seem to be in shortage of service bits, I don't mind it either.

Member

luke-jr commented Aug 4, 2017

I don't like the general idea since it burns a service bit unnecessarily, but since it's just for a year or so, and we don't seem to be in shortage of service bits, I don't mind it either.

@fanquake fanquake added the P2P label Aug 5, 2017

@Leviathn

This comment has been minimized.

Show comment
Hide comment
@Leviathn

Leviathn commented Aug 5, 2017

utACK

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Aug 5, 2017

Member

Looks straightforward and correct to me - utACK cae246e.

Would be good to create an issue to track this to make sure this code gets removed after T>=1533096000.

Member

laanwj commented Aug 5, 2017

Looks straightforward and correct to me - utACK cae246e.

Would be good to create an issue to track this to make sure this code gets removed after T>=1533096000.

@laanwj laanwj added this to the 0.15.0 milestone Aug 5, 2017

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

NAK, this will cause a premature network split.

Contributor

jgarzik commented Aug 5, 2017

NAK, this will cause a premature network split.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Aug 5, 2017

Member

One remaining relaying node is enough to prevent a premature chain split. Which should be fine as not everyone will be upgrading to 0.15 at the same time. If you think there's a risk of that, run a node without this code and make sure to be connected to both nodes signaling and not signaling this flag.

Member

laanwj commented Aug 5, 2017

One remaining relaying node is enough to prevent a premature chain split. Which should be fine as not everyone will be upgrading to 0.15 at the same time. If you think there's a risk of that, run a node without this code and make sure to be connected to both nodes signaling and not signaling this flag.

@kek-coin

This comment has been minimized.

Show comment
Hide comment
@kek-coin

kek-coin Aug 5, 2017

Since the S2X hardfork blockheight is known, would it be better to only disconnect when the block prior to the hardfork block is found and relayed?

kek-coin commented Aug 5, 2017

Since the S2X hardfork blockheight is known, would it be better to only disconnect when the block prior to the hardfork block is found and relayed?

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

Deploying this change for NODE_SEGWIT2X - bit 7 - creates chain splits in the wild on an inconsistent basis -- the upgrade rate to (0.15?).

This creates chain splits even though Bitcoin Core and segwit2x nodes are validating 100% the same rules today; it creates chain splits because of a presumed future rule deviation.

The outcome is a bunch of non-deterministic islands. This is a very hostile and unsafe change prior to segwit2x fork deployment.

Consider, for example, what would happen if this code were hypothetically deployed on July 1 2017 for NODE_BIP148. Nodes would be split off prematurely, at an inconsistent rate (rate of upgrade).

Contributor

jgarzik commented Aug 5, 2017

Deploying this change for NODE_SEGWIT2X - bit 7 - creates chain splits in the wild on an inconsistent basis -- the upgrade rate to (0.15?).

This creates chain splits even though Bitcoin Core and segwit2x nodes are validating 100% the same rules today; it creates chain splits because of a presumed future rule deviation.

The outcome is a bunch of non-deterministic islands. This is a very hostile and unsafe change prior to segwit2x fork deployment.

Consider, for example, what would happen if this code were hypothetically deployed on July 1 2017 for NODE_BIP148. Nodes would be split off prematurely, at an inconsistent rate (rate of upgrade).

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

It is safe and a convenient optimization for this codebase to make this change after a chain split, but not before.

Contributor

jgarzik commented Aug 5, 2017

It is safe and a convenient optimization for this codebase to make this change after a chain split, but not before.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 5, 2017

Contributor

@kek-coin we are absolutely not in the business of trying to determine what clients running incompatible consensus rules will do. Ignore @jgarzik's fudding, this obviously doesn't create a split until their incompatible rules kick in, it will only make upgraded nodes more cleanly separated, its not like the network wont still be well-connected.

Contributor

TheBlueMatt commented Aug 5, 2017

@kek-coin we are absolutely not in the business of trying to determine what clients running incompatible consensus rules will do. Ignore @jgarzik's fudding, this obviously doesn't create a split until their incompatible rules kick in, it will only make upgraded nodes more cleanly separated, its not like the network wont still be well-connected.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

Disconnecting service bits should only be enabled after peers have started banning each other on the network, thus proving the safety of service bit disconnect.

It is obviously unsafe to disconnect outside that set of conditions.

ETA: @TheBlueMatt Please reconsider that every disagreement of opinion is not "fudding", and we can have an honest debate.

Contributor

jgarzik commented Aug 5, 2017

Disconnecting service bits should only be enabled after peers have started banning each other on the network, thus proving the safety of service bit disconnect.

It is obviously unsafe to disconnect outside that set of conditions.

ETA: @TheBlueMatt Please reconsider that every disagreement of opinion is not "fudding", and we can have an honest debate.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

Specific review:

  1. The subject line says bits 6 and 8, yet the current code as of this writing masks bits 5 and 7.

  2. bit 5 isNODE_BITCOIN_CASH = (1 << 5) in the BitcoinABC codebase, and bit 7 is NODE_SEGWIT2X = (1 << 7) in the btc1 codebase.

  3. NODE_BITCOIN_CASH is provably divergent today, Bitcoin Core and BitcoinABC peers ban each other today, so it is obviously safe to add this disconnect logic as an optimization to what would automatically be arrived at already.

  4. NODE_SEGWIT2X is not divergent today, Bitcoin Core and btc1 peers do not ban each other today, and including this bit in the disconnect logic would create new network disruptions that would not otherwise exist.

One bit is safe for the network as a whole, one bit is disruptive to the network as a whole - today.

Contributor

jgarzik commented Aug 5, 2017

Specific review:

  1. The subject line says bits 6 and 8, yet the current code as of this writing masks bits 5 and 7.

  2. bit 5 isNODE_BITCOIN_CASH = (1 << 5) in the BitcoinABC codebase, and bit 7 is NODE_SEGWIT2X = (1 << 7) in the btc1 codebase.

  3. NODE_BITCOIN_CASH is provably divergent today, Bitcoin Core and BitcoinABC peers ban each other today, so it is obviously safe to add this disconnect logic as an optimization to what would automatically be arrived at already.

  4. NODE_SEGWIT2X is not divergent today, Bitcoin Core and btc1 peers do not ban each other today, and including this bit in the disconnect logic would create new network disruptions that would not otherwise exist.

One bit is safe for the network as a whole, one bit is disruptive to the network as a whole - today.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Aug 5, 2017

Member
Member

jtimon commented Aug 5, 2017

@sdaftuar

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Aug 5, 2017

Member

Concept ACK

It is safe and a convenient optimization for this codebase to make this change after a chain split, but not before.

@jgarzik I believe it is safer for the network topology to not suddenly change at the same time of a consensus rule change -- that is likely to be disruptive (I could imagine users of our software could suddenly find themselves without any peers, depending on the adoption rate of btc1) and forces users to be reactive, rather than proactive, to networking issues that arise. We used similar reasoning with the peering changes that accompanied segwit: the preferential peering was active long before segwit activated, by design, so that the network topology could change gradually with software deployment, and any unexpected behaviors could be understood and corrected before the consensus changes took place.

I don't feel strongly about whether the change in this PR happens now (ie for the 0.15 release, which is imminent), or in a future 0.15.1 or so, assuming we expect the latter to happen well in advance of any planned chain splits. But I strongly believe the network topology should largely adjust pre-fork, and not post-fork, to minimize disruption.

Furthermore, I don't think that btc1 making a network magic code change at the fork point would eliminate the need for this PR -- the goal is for the network topology to start changing earlier, and not suddenly be disrupted. (Perhaps if btc1 changed network magic a few weeks or more before any planned fork, then that would be sufficient to eliminate the need here, but as I see btc1#99 (comment) there is clearly no appetite for this.)

Based on the adoption rates of earlier releases, I don't expect the whole network to suddenly upgrade to 0.15 and cause a network split (I happen to personally run many older versions of bitcoin core, and I assume many others do too, which would serve as bridges).

If we had more time on our hands and someone was so inclined, a more conservative change would be to just limit the number of outbound peers that offer these service bits, eg to 2 out of our 8. However, given the relatively constrained time frames, I don't think the review burden of a more complicated change is worth it, given how low risk I view this change to already be. And if we want to get this merged for 0.15 or 0.15.1 the change should be as minimal as possible, along the lines of this PR.

Will test.

Member

sdaftuar commented Aug 5, 2017

Concept ACK

It is safe and a convenient optimization for this codebase to make this change after a chain split, but not before.

@jgarzik I believe it is safer for the network topology to not suddenly change at the same time of a consensus rule change -- that is likely to be disruptive (I could imagine users of our software could suddenly find themselves without any peers, depending on the adoption rate of btc1) and forces users to be reactive, rather than proactive, to networking issues that arise. We used similar reasoning with the peering changes that accompanied segwit: the preferential peering was active long before segwit activated, by design, so that the network topology could change gradually with software deployment, and any unexpected behaviors could be understood and corrected before the consensus changes took place.

I don't feel strongly about whether the change in this PR happens now (ie for the 0.15 release, which is imminent), or in a future 0.15.1 or so, assuming we expect the latter to happen well in advance of any planned chain splits. But I strongly believe the network topology should largely adjust pre-fork, and not post-fork, to minimize disruption.

Furthermore, I don't think that btc1 making a network magic code change at the fork point would eliminate the need for this PR -- the goal is for the network topology to start changing earlier, and not suddenly be disrupted. (Perhaps if btc1 changed network magic a few weeks or more before any planned fork, then that would be sufficient to eliminate the need here, but as I see btc1#99 (comment) there is clearly no appetite for this.)

Based on the adoption rates of earlier releases, I don't expect the whole network to suddenly upgrade to 0.15 and cause a network split (I happen to personally run many older versions of bitcoin core, and I assume many others do too, which would serve as bridges).

If we had more time on our hands and someone was so inclined, a more conservative change would be to just limit the number of outbound peers that offer these service bits, eg to 2 out of our 8. However, given the relatively constrained time frames, I don't think the review burden of a more complicated change is worth it, given how low risk I view this change to already be. And if we want to get this merged for 0.15 or 0.15.1 the change should be as minimal as possible, along the lines of this PR.

Will test.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

The specific and immediate impact of this change is that Bitcoin Core nodes would disconnect all segwit2x nodes, even though they share the same rulesets today.

Contributor

jgarzik commented Aug 5, 2017

The specific and immediate impact of this change is that Bitcoin Core nodes would disconnect all segwit2x nodes, even though they share the same rulesets today.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 5, 2017

Contributor

@jgarzik I'm really not sure what basis your argument has, here. This change very clearly wont harm 2x nodes as they already do preferential peering and will obviously stay well-connected thanks to the numerous 0.14 and previous nodes on the network, I'm really not sure how you could argue otherwise. The idea that the network should suddenly change topology come hard fork is only adding potential for issues on that day, so this change can only help y'all smoothly fork off.

Contributor

TheBlueMatt commented Aug 5, 2017

@jgarzik I'm really not sure what basis your argument has, here. This change very clearly wont harm 2x nodes as they already do preferential peering and will obviously stay well-connected thanks to the numerous 0.14 and previous nodes on the network, I'm really not sure how you could argue otherwise. The idea that the network should suddenly change topology come hard fork is only adding potential for issues on that day, so this change can only help y'all smoothly fork off.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Aug 5, 2017

Member

nit: Would be nice to use named constants.

Member

NicolasDorier commented Aug 5, 2017

nit: Would be nice to use named constants.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

Disconnecting peers that are otherwise 100% interoperable is just bananas.

It is the opposite of the Robustness Principle ("be liberal in what you accept') of RFC1122 and elsewhere: https://tools.ietf.org/html/rfc1122#section-1.2.2

Contributor

jgarzik commented Aug 5, 2017

Disconnecting peers that are otherwise 100% interoperable is just bananas.

It is the opposite of the Robustness Principle ("be liberal in what you accept') of RFC1122 and elsewhere: https://tools.ietf.org/html/rfc1122#section-1.2.2

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Aug 5, 2017

Member

nit: Would be nice to use named named constants.

I don't think that's necessary - the code is short-lived, and the comment already explains it well enough, and one could also say it's more self-contained like this. We wouldn't want to define these service bits with those that have been reserved by following the BIP process.

Member

laanwj commented Aug 5, 2017

nit: Would be nice to use named named constants.

I don't think that's necessary - the code is short-lived, and the comment already explains it well enough, and one could also say it's more self-contained like this. We wouldn't want to define these service bits with those that have been reserved by following the BIP process.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

All,

Please strongly consider the signal it sends to the community, and other protocol/implementation developers, when changing Bitcoin Core to reject otherwise-working, otherwise-interoperable network clients.

This is akin to a Web server rejecting connections with a client string "Internet Explorer" while accepting client strings that include "Mozilla", but are otherwise 100% interoperable.

Let's figure out a way to cooperate and maximize interoperability. Let's be RFC 1122 compliant.

Contributor

jgarzik commented Aug 5, 2017

All,

Please strongly consider the signal it sends to the community, and other protocol/implementation developers, when changing Bitcoin Core to reject otherwise-working, otherwise-interoperable network clients.

This is akin to a Web server rejecting connections with a client string "Internet Explorer" while accepting client strings that include "Mozilla", but are otherwise 100% interoperable.

Let's figure out a way to cooperate and maximize interoperability. Let's be RFC 1122 compliant.

@betawaffle

This comment has been minimized.

Show comment
Hide comment
@betawaffle

betawaffle Aug 5, 2017

otherwise-working, otherwise-interoperable

If you see a car heading in your direction on the wrong side of the road, you don't wait until they have hit you to react.

betawaffle commented Aug 5, 2017

otherwise-working, otherwise-interoperable

If you see a car heading in your direction on the wrong side of the road, you don't wait until they have hit you to react.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Aug 5, 2017

Member

Disconnecting peers that are otherwise 100% interoperable is just bananas.

It is the opposite of the Robustness Principle ("be liberal in what you accept') of RFC1122 and elsewhere: https://tools.ietf.org/html/rfc1122#section-1.2.2

@jgarzik The the Postel maxim is widely, if not yet universally, considered to be a broken idea of the past. When it's brought up in the IETF it's usually with regret or with mocking-- it is directly responsible for many serious problems on the internet today. ( https://tools.ietf.org/html/rfc3117#section-4.5 http://programmingisterrible.com/post/42215715657/postels-principle-is-a-bad-idea ).

It's also frequently in direct conflict with security and reliability.

This is one of those cases. Sudden changes in network topology can leave a node isolated from compatible consensus rules. We depend on long lived connections for durability from various DOS attacks. If suddenly a node finds all its peers incompatible with it even if its smart enough to rapidly realize this and ban incompatible peers (as Bcash's adoption of the segwit signature scheme for replay protection provided but which nothing in s2x provides), it may find that it can not find anything to connect to, e.g. because attackers have filled most of the slots elsewhere on the network.

S2X nodes are not 100% compatible, because compatibility includes what the connection will do in the future as well.

A Bitcoin node depends on information being easy to spread and hard to stifle, but this assumption doesn't hold when you're surrounded with peers with incompatible rules-- the incompatible peers will stifle your communications with the Bitcoin network. The only way to be sure to have robust connections to peers with compatible rules when some event happens is to have them well before the event, so they enjoy protected high priority slots.

This was discussed extensively in the design and development of segwit, since segwit itself results in a change in P2P networking. After extensive consideration we found the best way to make sure there was no problem was to make the topology change in advance. In particular, this moves any topology change related issues for a single node to the time of upgrade, when the operator is certainly paying attention, rather than later when they are not.

Consider a node with 8 peers, all s2x nodes. At some height the s2x issuance activates, and s2x stops sending valid blocks to our node. Yet the s2x network then takes hours (like Bcash, or over a day like the btc1 testnet) to mine the even a single additional block, and because s2x has no replay protection invalid tx signatures will also not cause banning. When s2x does get a block it will only disconnect a single peer and may find connection slots exhausted all over the net (due to attacks or increased demand from other links cutting). If it has a single connection up to the Bitcoin network, if it has more blocks it may not even notice s2x blocks are invalid if they're part of a less-work chain, since s2x doesn't use the HF bit. All of this disruption, potentially quite severe and damaging (e.g. esp if our node in question is a Bitcoin miner) is avoided by not making a hard cut change to the network topology, but instead adopting a topology from the moment the node starts that will continue to be good for it in the future, with the change happening over time rather than as a network wide system-shock.

Above, the claim is made above that "Bitcoin Core nodes would disconnect all segwit2x nodes"; but that isn't the case-- only nodes running this newer software would do so. Historical update rates suggest that this will only be a moderate part of the network. But this moderate part is also important because it means there will be a reasonably large chunk of the network which are more likely to be healthy, partitioned, and more able to take the connections from nodes running older code which aren't aware of the topology change.

I'm not aware of, and I haven't seen presented any argument that there was an actual meaningful risk of any kind of premature partitioning as a result of this under any kind of realistic assumptions. If I've missed it, please walk me through how that might happen.

Let's figure out a way to cooperate and maximize interoperability.

That sounds great, but people have been trying to do so recommending basic prudent changes that would prevent disruption which your project has very vigorously (and in many causes insultingly) rejected.-- including things that even Bcash got right. Especially when your project insists on an nonnegotiable position of making these changes with many times less time than we have consistently expressed is needed to safely accomplish such things. If cooperation is in your plans, why is it not evidence in the timeframes or in the activities thus far?

Most confusingly, given the relative ratio of nodes in the network changes like this are likely to be even more protective of S2X users than they are of Bitcoin's users.

Member

gmaxwell commented Aug 5, 2017

Disconnecting peers that are otherwise 100% interoperable is just bananas.

It is the opposite of the Robustness Principle ("be liberal in what you accept') of RFC1122 and elsewhere: https://tools.ietf.org/html/rfc1122#section-1.2.2

@jgarzik The the Postel maxim is widely, if not yet universally, considered to be a broken idea of the past. When it's brought up in the IETF it's usually with regret or with mocking-- it is directly responsible for many serious problems on the internet today. ( https://tools.ietf.org/html/rfc3117#section-4.5 http://programmingisterrible.com/post/42215715657/postels-principle-is-a-bad-idea ).

It's also frequently in direct conflict with security and reliability.

This is one of those cases. Sudden changes in network topology can leave a node isolated from compatible consensus rules. We depend on long lived connections for durability from various DOS attacks. If suddenly a node finds all its peers incompatible with it even if its smart enough to rapidly realize this and ban incompatible peers (as Bcash's adoption of the segwit signature scheme for replay protection provided but which nothing in s2x provides), it may find that it can not find anything to connect to, e.g. because attackers have filled most of the slots elsewhere on the network.

S2X nodes are not 100% compatible, because compatibility includes what the connection will do in the future as well.

A Bitcoin node depends on information being easy to spread and hard to stifle, but this assumption doesn't hold when you're surrounded with peers with incompatible rules-- the incompatible peers will stifle your communications with the Bitcoin network. The only way to be sure to have robust connections to peers with compatible rules when some event happens is to have them well before the event, so they enjoy protected high priority slots.

This was discussed extensively in the design and development of segwit, since segwit itself results in a change in P2P networking. After extensive consideration we found the best way to make sure there was no problem was to make the topology change in advance. In particular, this moves any topology change related issues for a single node to the time of upgrade, when the operator is certainly paying attention, rather than later when they are not.

Consider a node with 8 peers, all s2x nodes. At some height the s2x issuance activates, and s2x stops sending valid blocks to our node. Yet the s2x network then takes hours (like Bcash, or over a day like the btc1 testnet) to mine the even a single additional block, and because s2x has no replay protection invalid tx signatures will also not cause banning. When s2x does get a block it will only disconnect a single peer and may find connection slots exhausted all over the net (due to attacks or increased demand from other links cutting). If it has a single connection up to the Bitcoin network, if it has more blocks it may not even notice s2x blocks are invalid if they're part of a less-work chain, since s2x doesn't use the HF bit. All of this disruption, potentially quite severe and damaging (e.g. esp if our node in question is a Bitcoin miner) is avoided by not making a hard cut change to the network topology, but instead adopting a topology from the moment the node starts that will continue to be good for it in the future, with the change happening over time rather than as a network wide system-shock.

Above, the claim is made above that "Bitcoin Core nodes would disconnect all segwit2x nodes"; but that isn't the case-- only nodes running this newer software would do so. Historical update rates suggest that this will only be a moderate part of the network. But this moderate part is also important because it means there will be a reasonably large chunk of the network which are more likely to be healthy, partitioned, and more able to take the connections from nodes running older code which aren't aware of the topology change.

I'm not aware of, and I haven't seen presented any argument that there was an actual meaningful risk of any kind of premature partitioning as a result of this under any kind of realistic assumptions. If I've missed it, please walk me through how that might happen.

Let's figure out a way to cooperate and maximize interoperability.

That sounds great, but people have been trying to do so recommending basic prudent changes that would prevent disruption which your project has very vigorously (and in many causes insultingly) rejected.-- including things that even Bcash got right. Especially when your project insists on an nonnegotiable position of making these changes with many times less time than we have consistently expressed is needed to safely accomplish such things. If cooperation is in your plans, why is it not evidence in the timeframes or in the activities thus far?

Most confusingly, given the relative ratio of nodes in the network changes like this are likely to be even more protective of S2X users than they are of Bitcoin's users.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Aug 5, 2017

Member
Member

jtimon commented Aug 5, 2017

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 5, 2017

Contributor

Fixed to use GetTime() instead of GetSystemTimeInSeconds, as I misread the comment and intended the mockable version, not that it matters much.

Contributor

TheBlueMatt commented Aug 5, 2017

Fixed to use GetTime() instead of GetSystemTimeInSeconds, as I misread the comment and intended the mockable version, not that it matters much.

@greenaddress

This comment has been minimized.

Show comment
Hide comment
@greenaddress

greenaddress Aug 5, 2017

Contributor

Concept ACK. Agree with @laanwj this needs to be tracked to remove the code once the disconnect is unnecessary.

Happy the code is confined and explicitly limited to do the disconnect until 1st of August 2018. I don't personally think in this case a constant is useful - comments are to the point
IMHO.

Contributor

greenaddress commented Aug 5, 2017

Concept ACK. Agree with @laanwj this needs to be tracked to remove the code once the disconnect is unnecessary.

Happy the code is confined and explicitly limited to do the disconnect until 1st of August 2018. I don't personally think in this case a constant is useful - comments are to the point
IMHO.

@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Aug 5, 2017

Member

Please strongly consider the signal it sends to the community, and other protocol/implementation developers, when changing Bitcoin Core to reject otherwise-working, otherwise-interoperable network clients.

@jgarzik I can not agree more with this statement. However, it doesn't apply in the slightest to this situation. The btc1 client is already not interoperable with the Core client. It already contains code that will irreversibly split from Core in the very near future. All this PR is doing is easing the transition for both types of clients.

Member

morcos commented Aug 5, 2017

Please strongly consider the signal it sends to the community, and other protocol/implementation developers, when changing Bitcoin Core to reject otherwise-working, otherwise-interoperable network clients.

@jgarzik I can not agree more with this statement. However, it doesn't apply in the slightest to this situation. The btc1 client is already not interoperable with the Core client. It already contains code that will irreversibly split from Core in the very near future. All this PR is doing is easing the transition for both types of clients.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 5, 2017

Contributor

It is not easing a transition when fully interoperable clients are disconnected for no other reason than a service bit is set. For the time period starting now through segwit2x fork time, It is creating disruption where, provably, none would have otherwise existed.

Absent this change, Bitcoin Core and segwit2x peers will communicate without error for months to come.

Contributor

jgarzik commented Aug 5, 2017

It is not easing a transition when fully interoperable clients are disconnected for no other reason than a service bit is set. For the time period starting now through segwit2x fork time, It is creating disruption where, provably, none would have otherwise existed.

Absent this change, Bitcoin Core and segwit2x peers will communicate without error for months to come.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Aug 7, 2017

Contributor

@gandrewstone btc1 nodes should not be making outbound connections to nodes that don't support their consensus rules anyways, they should instead preferentially peer with each other. Inbound connections from pre-0.15.0 nodes will be enough to prevent a network fork from happening before they switch to their incompatible rules.

Contributor

jameshilliard commented Aug 7, 2017

@gandrewstone btc1 nodes should not be making outbound connections to nodes that don't support their consensus rules anyways, they should instead preferentially peer with each other. Inbound connections from pre-0.15.0 nodes will be enough to prevent a network fork from happening before they switch to their incompatible rules.

dagurval referenced this pull request Aug 7, 2017

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Aug 8, 2017

Contributor

Concept ACK

Contributor

petertodd commented Aug 8, 2017

Concept ACK

@SamouraiDev

This comment has been minimized.

Show comment
Hide comment
@SamouraiDev

SamouraiDev commented Aug 8, 2017

ACK

@notespace

This comment has been minimized.

Show comment
Hide comment
@notespace

notespace Aug 8, 2017

Please correct me if I'm wrong, but assuming a large portion of NYA-signaling miners would actually start using the btc1 client, wouldn't this change end up starving out miners who wish to use Bitcoin Core 0.15.0 before the fork, as they wouldn't be able to get blocks as quickly as the btc1-only mining network? Or is every miner supposed to be using the FIBRE network anyways?

Also, as a Core user making transactions, wouldn't this mean that it becomes harder for transactions to find their way into blocks? Or are you hoping the un-upgraded 0.14.3 nodes pick up all the slack of relaying these transactions, and when the old node count dwindles as people upgrade, makes the problem worse?

What prevents the btc1 project from just changing or disabling its service bit to avoid this disruption, like what @gandrewstone is saying?

As long as you are putting in specific rules for specific clients, why not just partition off at the fork block? Or slowly disconnect up to the fork, not all at once on upgrade?

notespace commented Aug 8, 2017

Please correct me if I'm wrong, but assuming a large portion of NYA-signaling miners would actually start using the btc1 client, wouldn't this change end up starving out miners who wish to use Bitcoin Core 0.15.0 before the fork, as they wouldn't be able to get blocks as quickly as the btc1-only mining network? Or is every miner supposed to be using the FIBRE network anyways?

Also, as a Core user making transactions, wouldn't this mean that it becomes harder for transactions to find their way into blocks? Or are you hoping the un-upgraded 0.14.3 nodes pick up all the slack of relaying these transactions, and when the old node count dwindles as people upgrade, makes the problem worse?

What prevents the btc1 project from just changing or disabling its service bit to avoid this disruption, like what @gandrewstone is saying?

As long as you are putting in specific rules for specific clients, why not just partition off at the fork block? Or slowly disconnect up to the fork, not all at once on upgrade?

@automated-response

This comment has been minimized.

Show comment
Hide comment
@automated-response

automated-response Aug 8, 2017

Why the other implementation wouldn't have just done the reciprocal of this by default at launch is beyond me. This will markedly improve connectivity between compatible peers both respective chains. Looks good.

automated-response commented Aug 8, 2017

Why the other implementation wouldn't have just done the reciprocal of this by default at launch is beyond me. This will markedly improve connectivity between compatible peers both respective chains. Looks good.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Aug 8, 2017

Member

why not just partition off at the fork block?

Please read the explanations by Suhas and myself earlier. This was covered.

Member

gmaxwell commented Aug 8, 2017

why not just partition off at the fork block?

Please read the explanations by Suhas and myself earlier. This was covered.

@notespace

This comment has been minimized.

Show comment
Hide comment
@notespace

notespace Aug 8, 2017

OK, I see that it makes sense not to immediately partition at the block.

What about gradually pushing out nodes using the peer selection logic? Then the network would gradually partition safely, even if all upgrade to run 0.15.0 nodes before the fork. Then there remains some cross-communication between btc1 nodes and core nodes.

notespace commented Aug 8, 2017

OK, I see that it makes sense not to immediately partition at the block.

What about gradually pushing out nodes using the peer selection logic? Then the network would gradually partition safely, even if all upgrade to run 0.15.0 nodes before the fork. Then there remains some cross-communication between btc1 nodes and core nodes.

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

This rashly merged commit exactly showed how corrupt the BCore Committee became and why the majority of Bitcoin community decided to go ahead with SegWit2X.

CSmith7703 commented Aug 8, 2017

This rashly merged commit exactly showed how corrupt the BCore Committee became and why the majority of Bitcoin community decided to go ahead with SegWit2X.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Aug 8, 2017

Member

Can we properly define those bits in protocol.h?

Member

jonasschnelli commented Aug 8, 2017

Can we properly define those bits in protocol.h?

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Aug 8, 2017

Member

Can we properly define those bits in protocol.h?

I also dislike the way how those bits where kidnapped (without the BIP process) but setting a proper constant is still the way to go (we have also done that for XTHIN).

Anyways.
Concept ACK.

Member

jonasschnelli commented Aug 8, 2017

Can we properly define those bits in protocol.h?

I also dislike the way how those bits where kidnapped (without the BIP process) but setting a proper constant is still the way to go (we have also done that for XTHIN).

Anyways.
Concept ACK.

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

@jonasschnelli

kidnapped

Yeah, another negative word to defame dissenters. Such dirty tricks should be avoided.

Anyways, glad to see that you BCore committee tries to leave Bitcoin and fork your 2nd altcoin. Will the token still be called BUASF? I can't wait to sell it to buy more Bitcoin.

CSmith7703 commented Aug 8, 2017

@jonasschnelli

kidnapped

Yeah, another negative word to defame dissenters. Such dirty tricks should be avoided.

Anyways, glad to see that you BCore committee tries to leave Bitcoin and fork your 2nd altcoin. Will the token still be called BUASF? I can't wait to sell it to buy more Bitcoin.

@I3ck

This comment has been minimized.

Show comment
Hide comment
@I3ck

I3ck Aug 8, 2017

I thought the #1 priority was to have as many nodes as possible?

I3ck commented Aug 8, 2017

I thought the #1 priority was to have as many nodes as possible?

@piotrnar

This comment has been minimized.

Show comment
Hide comment
@piotrnar

piotrnar Aug 8, 2017

I see some serious lack of imagination here, among the people pushing for this change.

Do you realize that when you start banning peers based on the content of their version messages, it will eventually make the content of these message obsolete?

With this change, you are breaking up the network protocol, by forcing certain nodes to stary lying about who they are and what they want.

piotrnar commented Aug 8, 2017

I see some serious lack of imagination here, among the people pushing for this change.

Do you realize that when you start banning peers based on the content of their version messages, it will eventually make the content of these message obsolete?

With this change, you are breaking up the network protocol, by forcing certain nodes to stary lying about who they are and what they want.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Aug 8, 2017

Member

@piotrnar If they do that they will just harm themselves for the most part, as they connect to the thousands of bitcoin core nodes out there that won't tell them about the blockchain they want to hear about. Where is your concern that Bitcoin also disconnects litecoin nodes?

There will always be malicious peers out there that will lie. That we can't help. Also, this PR disconnects, rather than banning. (In fact, it protects the peers addresses from banning, which will avoid compatible software on the same IPs getting banned everywhere in the network... which happened to some ABC users-- where their Bitcoin node had a hard time getting connections because ABC had gotten them banned all over the place).

Member

gmaxwell commented Aug 8, 2017

@piotrnar If they do that they will just harm themselves for the most part, as they connect to the thousands of bitcoin core nodes out there that won't tell them about the blockchain they want to hear about. Where is your concern that Bitcoin also disconnects litecoin nodes?

There will always be malicious peers out there that will lie. That we can't help. Also, this PR disconnects, rather than banning. (In fact, it protects the peers addresses from banning, which will avoid compatible software on the same IPs getting banned everywhere in the network... which happened to some ABC users-- where their Bitcoin node had a hard time getting connections because ABC had gotten them banned all over the place).

@piotrnar

This comment has been minimized.

Show comment
Hide comment
@piotrnar

piotrnar Aug 8, 2017

@gmaxwell, this is how the protocol evolves: different people introduce different features, that later get approved (or not) by the mining majority.

There is nothing wrong with this process. I don't understand why you have a problem with it.

Are you saying that you are not going to ever allow the miners to vote on any consensus protocol changes, other then the ones that the bitcoin core team has accepted?

piotrnar commented Aug 8, 2017

@gmaxwell, this is how the protocol evolves: different people introduce different features, that later get approved (or not) by the mining majority.

There is nothing wrong with this process. I don't understand why you have a problem with it.

Are you saying that you are not going to ever allow the miners to vote on any consensus protocol changes, other then the ones that the bitcoin core team has accepted?

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

@gmaxwell

If they do that they will just harm themselves

Lie. The 'They' Piotrnar talked about is that the people who run your malicious code to ban others. gMAXWELL, your dishonest ego is quite laughable.

There will always be malicious peers out there that will lie.

So why are you always the malicious one that tells lies frequently?

CSmith7703 commented Aug 8, 2017

@gmaxwell

If they do that they will just harm themselves

Lie. The 'They' Piotrnar talked about is that the people who run your malicious code to ban others. gMAXWELL, your dishonest ego is quite laughable.

There will always be malicious peers out there that will lie.

So why are you always the malicious one that tells lies frequently?

@Pheromon

This comment has been minimized.

Show comment
Hide comment
@Pheromon

Pheromon Aug 8, 2017

Are you saying that you are not going to ever allow the miners to vote on any consensus protocol changes, other then the ones that the bitcoin core team has accepted?

That's exactly what Blockstream is about: they want to be the only ones to decide how and when Bitcoin must evolve. They ignore the community and reject miners because they think they are bad for Bitcoin.

Pheromon commented Aug 8, 2017

Are you saying that you are not going to ever allow the miners to vote on any consensus protocol changes, other then the ones that the bitcoin core team has accepted?

That's exactly what Blockstream is about: they want to be the only ones to decide how and when Bitcoin must evolve. They ignore the community and reject miners because they think they are bad for Bitcoin.

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

@Pheromon
Exactly.
In the ego of gMAXWELL, people who refuse it is anti-decentralization and anti-users.
And people who say NO will be defamed with smear campaign.

CSmith7703 commented Aug 8, 2017

@Pheromon
Exactly.
In the ego of gMAXWELL, people who refuse it is anti-decentralization and anti-users.
And people who say NO will be defamed with smear campaign.

@piotrnar

This comment has been minimized.

Show comment
Hide comment
@piotrnar

piotrnar Aug 8, 2017

They ignore the community and reject miners because they think they are bad for Bitcoin.

I don't know about "the community", but I must say that ignoring the miners can only end up very badly for this project. Doing so bitcoin core is digging its own hole.

piotrnar commented Aug 8, 2017

They ignore the community and reject miners because they think they are bad for Bitcoin.

I don't know about "the community", but I must say that ignoring the miners can only end up very badly for this project. Doing so bitcoin core is digging its own hole.

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

@piotrnar
In the ego of Blockstream, those eight to ten guys are "the community". People who are against those eight guys are anti-decentralization, anti-Bitcoin, anti-users, and liars.

CSmith7703 commented Aug 8, 2017

@piotrnar
In the ego of Blockstream, those eight to ten guys are "the community". People who are against those eight guys are anti-decentralization, anti-Bitcoin, anti-users, and liars.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Aug 8, 2017

Member

@piotrnar It sounds like you are expressing a misunderstanding of the Bitcoin system.

The consensus rules are what defines what is or isn't mining. Namecoin or BCash or whatever miners are not Bitcoin miners because they produce blocks which violate Bitcoin's rules. If you look at the Bitcoin whitepaper, section 8 paragraph 2 talks about how nodes are protected against being overpowered by a majority of hashpower mining blocks which are invalid because they enforce the rules themselves. It would have been possible to define Bitcoin a different way where nodes blindly trust miners, but that isn't how it works or has ever worked. A miner that breaks the rules is simply ignored, and this is an integral part of the system of incentives that keeps the system from becoming insecure.

This is all pretty far off-topic for this PR now... and it shows in that several of the last posts are nothing but random people (Pheromon, and CSmith7703) hurling abusive comments and insults at me. This is not appropriate here and not welcome. We don't come into your projects and insult you. Please take it elsewhere.

Member

gmaxwell commented Aug 8, 2017

@piotrnar It sounds like you are expressing a misunderstanding of the Bitcoin system.

The consensus rules are what defines what is or isn't mining. Namecoin or BCash or whatever miners are not Bitcoin miners because they produce blocks which violate Bitcoin's rules. If you look at the Bitcoin whitepaper, section 8 paragraph 2 talks about how nodes are protected against being overpowered by a majority of hashpower mining blocks which are invalid because they enforce the rules themselves. It would have been possible to define Bitcoin a different way where nodes blindly trust miners, but that isn't how it works or has ever worked. A miner that breaks the rules is simply ignored, and this is an integral part of the system of incentives that keeps the system from becoming insecure.

This is all pretty far off-topic for this PR now... and it shows in that several of the last posts are nothing but random people (Pheromon, and CSmith7703) hurling abusive comments and insults at me. This is not appropriate here and not welcome. We don't come into your projects and insult you. Please take it elsewhere.

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

@gmaxwell

Half truth and actual lies again.
piotrnar knowns Bitcoin, Gmaxwell knowns BCore.
Since BCore is not Bitcoin, then it's fair for GMAXWELL and his blockstream buddies to ban other nodes.

CSmith7703 commented Aug 8, 2017

@gmaxwell

Half truth and actual lies again.
piotrnar knowns Bitcoin, Gmaxwell knowns BCore.
Since BCore is not Bitcoin, then it's fair for GMAXWELL and his blockstream buddies to ban other nodes.

@Pheromon

This comment has been minimized.

Show comment
Hide comment
@Pheromon

Pheromon Aug 8, 2017

I don't know about "the community", but I must say that ignoring the miners can only end up very badly for this project. Doing so bitcoin core is digging its own hole.

Exactly.
And maybe that's their real aim: destroy Bitcoin to save fiat money and banks (like their main investor, AXA).

Pheromon commented Aug 8, 2017

I don't know about "the community", but I must say that ignoring the miners can only end up very badly for this project. Doing so bitcoin core is digging its own hole.

Exactly.
And maybe that's their real aim: destroy Bitcoin to save fiat money and banks (like their main investor, AXA).

@TheCaat

This comment has been minimized.

Show comment
Hide comment
@TheCaat

TheCaat Aug 8, 2017

Contributor

Please lock this.

Contributor

TheCaat commented Aug 8, 2017

Please lock this.

@Pheromon

This comment has been minimized.

Show comment
Hide comment
@Pheromon

Pheromon Aug 8, 2017

If you look at the Bitcoin whitepaper, section 8 paragraph 2 talks about

If you look at the Bitcoin WP, you will not find a block limit as a consensus rule, also it's clearly stated that big (enormous!) blocks would be handled by miners.

So, it seems like you point at the WP only when you want.

Pheromon commented Aug 8, 2017

If you look at the Bitcoin whitepaper, section 8 paragraph 2 talks about

If you look at the Bitcoin WP, you will not find a block limit as a consensus rule, also it's clearly stated that big (enormous!) blocks would be handled by miners.

So, it seems like you point at the WP only when you want.

@piotrnar

This comment has been minimized.

Show comment
Hide comment
@piotrnar

piotrnar Aug 8, 2017

The consensus rules are what defines what is or isn't mining.

Sure - no question about it.

However, what we should be asking is: who, how and why defines (and guards) the consensus rules?

piotrnar commented Aug 8, 2017

The consensus rules are what defines what is or isn't mining.

Sure - no question about it.

However, what we should be asking is: who, how and why defines (and guards) the consensus rules?

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

@Pheromon
Don't forget Gmaxwell looked upon Bitcoin WhitePaper and slandered Satoshi.

@piotrnar
The ego of Gmaxwell defines and guards the consensus rule. Blockstream has spent more than 40 Million in the past two years to form this definition.

Gmaxwell: the last posts are nothing but random people

Anyone who don't follow the ego of Gmaxwell are 'random people'.

CSmith7703 commented Aug 8, 2017

@Pheromon
Don't forget Gmaxwell looked upon Bitcoin WhitePaper and slandered Satoshi.

@piotrnar
The ego of Gmaxwell defines and guards the consensus rule. Blockstream has spent more than 40 Million in the past two years to form this definition.

Gmaxwell: the last posts are nothing but random people

Anyone who don't follow the ego of Gmaxwell are 'random people'.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Aug 8, 2017

Member

Please stop political discussion immediately. Keep it technical.

Member

jonasschnelli commented Aug 8, 2017

Please stop political discussion immediately. Keep it technical.

@CSmith7703

This comment has been minimized.

Show comment
Hide comment
@CSmith7703

CSmith7703 Aug 8, 2017

@jonasschnelli This PR is purely political and out of evil will.

CSmith7703 commented Aug 8, 2017

@jonasschnelli This PR is purely political and out of evil will.

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Aug 8, 2017

Member

The review comments on pull requests are not meant for extended off-topic discussions. Please switch to another channel and keep this discussion for review comments on the code.

Member

MarcoFalke commented Aug 8, 2017

The review comments on pull requests are not meant for extended off-topic discussions. Please switch to another channel and keep this discussion for review comments on the code.

@bitcoin bitcoin locked and limited conversation to collaborators Aug 8, 2017

@bitcoin bitcoin unlocked this conversation Aug 9, 2017

@svyatonik svyatonik referenced this pull request Aug 9, 2017

Merged

Support Bitcoin Cash #434

@brynwaldwick

This comment has been minimized.

Show comment
Hide comment
@brynwaldwick

brynwaldwick Aug 9, 2017

What is the rationale for this versus, say, building compatibility with nodes that use these service bits into the client?

Is there a plan for creating a version compatible with these nodes in the future? Is there any timeline for that?

If I'm running this client in production what is the recommended upgrade path in the case where only tiny shards of the network are not using these service bits?

brynwaldwick commented Aug 9, 2017

What is the rationale for this versus, say, building compatibility with nodes that use these service bits into the client?

Is there a plan for creating a version compatible with these nodes in the future? Is there any timeline for that?

If I'm running this client in production what is the recommended upgrade path in the case where only tiny shards of the network are not using these service bits?

@betawaffle

This comment has been minimized.

Show comment
Hide comment
@betawaffle

betawaffle Aug 9, 2017

@brynwaldwick Those nodes aren't and can't be made compatible. They are hard fork nodes.

betawaffle commented Aug 9, 2017

@brynwaldwick Those nodes aren't and can't be made compatible. They are hard fork nodes.

@bitcoin bitcoin locked and limited conversation to collaborators Aug 9, 2017

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