New Network Magic
TheBlueMatt opened this issue · comments
btc1 really should add some code to more clearly prevent nodes from connecting to other networks, making sure connections slots arent wasted. This means not relaying addresses for nodes on other networks, immediately disconnecting nodes on other networks, etc.
The easiest way, by far, to do so, is to change the network magic, but other than that we'd likely need to resort to hacks like bitcoin#10982 to help the networks split more quickly, as well as other things to avoid relaying addresses for nodes on other coins.
Changing the network magic would break all existing SPV wallets, as far as I know.
It'd also split-off BU nodes which are otherwise capable of following the network if it has the most hashpower.
is btc1 the only one relaying those addresses? if not seems like something everyone benefits since it creates better distribution
As the core-supported chain is the one breaking the overwhelming majority consensus, I think it would be more appropriate for Bitcoin Core to add code for replay protection. Alternatively both coins could add connection restrictions or replay protections at the same blockheight so long as un-upgraded clients didn't favor one chain over the other any more than the blocksize requirement at fork time.
Bitcoin Cash nodes recently split off without a network magic change and there was no disruption. And the network "learns" the soft partition, due to how the P2P network requests nodes from other peers. Currently my nodes have around 30-35 connections and only 3-4 "satoshi" subvers.
There was some disruption, but most importantly Bitcoin-ABC nodes had a hard time finding each other for a while (at least until they had sufficient transaction flow to get banned by other nodes). Even now, connections slots to Bitcoin nodes are being wasted by ABC nodes and connections slots on ABC nodes are being wasted by Bitcoin nodes. For that reason, the Bitcoin-ABC folks are going to change their network magic (see Bitcoin-ABC/bitcoin-abc#62).
Bitcoin-ABC nodes had a hard time finding each other at first because nRelevantServices lacks NODE_BITCOIN_CASH. They are now aware of that issue.
@jgarzik that does not fully solve the issue, but only one small part of it. Should I read that as a "WONTFIX, Core should merge 10982"?
If Core don't want to follow the majority chain, they should just the magic in their code.
@NiKiZe it really doesn't matter what chain has more users/hashpower/whatever...network magic indicates compatible consensus rules with other nodes with the same network magic. Changing the network magic to indicate lack of compatibility is important.
@TheBlueMatt not if they are trying to steal SPV users.
@betawaffle in that case one could easily identify SPV clients based on incoming version message and switch to old version magic based on that (as SPV clients are ~always incoming peers, not outgoing).
@NiKiZe it really doesn't matter what chain has more users/hashpower/whatever...network magic indicates compatible consensus rules with other nodes with the same network magic. Changing the network magic to indicate lack of compatibility is important.
Then both chains can merge it for activation on the same block and either simultaneously accept or simultaneously reject the legacy clients. Objection?
@JaredR26 this is not about replay protection (which is consensus layer), this is about p2p network logic.
@JaredR26 this is not about replay protection (which is consensus layer), this is about p2p network logic.
Ok, fair, then why does jgarzik's nRelevantServices point not solve the issue? If it breaks compatibility with some set of users, I think it would only be applicable for it to be merged if both chains did it simultaneously just the same. Or am I misunderstanding and this wouldn't break any compatibility?
@JaredR26 that is precisely the point - only using nRelevantServices does not disconnect other full nodes, it only prefers to connect to full nodes which have those services set.
@JaredR26 there's no sense talking about both chains since the chain has not split yet. Furthermore, non-hardforking clients don't need to change anything because they should keep connected to legacy non-hardforking clients. With its small userbase it is more likely that BTC1 nodes will upgrade to new peering logic if it is put in place.
@JaredR26 that is precisely the point - only using nRelevantServices does not disconnect other full nodes, it only prefers to connect to full nodes which have those services set.
Right, which is fine for addressing the vast majority of the problem you're describing.
If you wanted to take it a step beyond that to the realm of breaking compatibility, it would need to be done on both chains. If there won't be two chains as @kek-coin states, it won't matter either way.
With its small userbase it is more likely that BTC1 nodes will upgrade to new peering logic if it is put in place.
There's no data that indicates BTC1 has a small userbase that I'm aware of, as there's no need to run a node for at least 60 days.
Furthermore, non-hardforking clients don't need to change anything because they should keep connected to legacy non-hardforking clients.
Legacy clients should follow the most PoW chain with overwhelming consensus wherever possible, which is what these objections are about.
There's no data that indicates BTC1 has a small userbase that I'm aware of, as there's no need to run a node for at least 60 days.
Really, you are countering my claim that not a lot of people are running BTC1 by asserting that people don't need to run it yet? That is exactly my point, and fits exactly into my reasoning why it should be okay to change the peering logic. Thanks for making my point for me while implying that you are somehow countering it, I guess?
Legacy clients should follow the most PoW chain with overwhelming consensus wherever possible, which is what these objections are about.
As @TheBlueMatt pointed out, it is perfectly possible for BTC1 p2p logic to special-case incoming SPV connections.
Edit: Re-reading that last part - legacy clients can't follow a hardfork chain. I think you simply mistyped and meant SPV but just to make sure.
That is exactly my point, and fits exactly into my reasoning why it should be okay to change the peering logic.
Making clients default to following the wrong chain that has very little mining or community support would be the wrong thing to do, and gains very little if anything for users.
@kek-coin we are talking about over 1000 reachable nodes and probably just as many non reachable nodes + SPV that would need to know and handle any new magic.
It saddens me that the : confused : reaction does not express complete bewilderment at what someone must be thinking to write what they write. I'm sorry, @JaredR26 but I have no clue what you are on about, we seem to be on completely different wavelengths, so I will refrain from derailing the technical discussion on this issue further with this discussion thread.
@NiKiZe as stated before, incoming SPV connections can be specialcased, specialcasing non-SPV connections makes no sense as they would not be on the same side of a chainsplit either? Or are you talking about existing BTC1 nodes? Perhaps major-version 1 can be specialcased as well?
@kek-coin you do know that the NYA agreement have 80-90% of the hashrate? and as such all nodes that does not have a hard 1MB block limit will also follow this chain (not only btc1 explicit nodes). again this means over 1000 reachable nodes + nodes that have outgoing but not incoming connections (these are full nodes) and mentioning of SPV is only on top of that
@jrallison "The vast, vast, vast majority of those nodes run bitcoin core" Do you mean that the over 1000 connectable full nodes that are identified as Bitcoin Unlimited, btc1, or Bitcoin Classic are running Core?
Again(!) there is over 1000 connectable full bitcoin nodes that does NOT have a hard 1MB blocksize limit (these are easy to find numbers in any node explorer) so changing magic and still being compatible with all those nodes (plus full nodes running compatible code but isn't connectable) will be a hell of a kludge if even possible at all.
Do you mean that the over 1000 connectable full nodes that are identified as Bitcoin Unlimited, btc1, or Bitcoin Classic are running Core?
Nope, was referencing the entire set of full nodes (close to ~9k). Realized the context here after the fact and retracted my comment.
btc1 makes very careful analysis of when a new network magic is needed.
New network magic and new ports were used when creating testnet5, when we executed a chain split from testnet3 to testnet5.
The same was suggested for Bitcoin ABC several days ago at https://twitter.com/jgarzik/status/890570498001829889 and again in private, and it sounds like they are looking to transition to a new network magic.
With segwit2x likely to be the majority chain, the goal of "one coin", it makes for the most seamless transition to keep the same network magic and ports. Changing network magic, on the other hand, would seem to go against the NYA charter of widespread agreement to upgrade to segwit + 2M HF.
Closing as way-too-disruptive.
@jgarzik Didn't you assert that "a new network Magic seems cleaner reduces possibility of disruption to basically zero" in regards to BC(C|H)? How is the S2X hardfork different from the BC(C|H) hardfork from a technical perspective that it warrants foregoing the anti-disruptive measures proposed here?