Preparation for DNS seeds and hardcoded seeds (may require a service bit)

[chjj]

The current mainnet DNS seeds are sort of an issue. The nodes who sit behind these DNS seed servers give no guarantees of switching to the current segwit2x branch.

A p2p network split is almost guaranteed with the situation as it is. SW2x should prepare for this. After a while, the current DNS seeds, assuming they all use the current bitcoin core code, will stop returning addrs for any nodes running segwit2x. After the HF activates, segwit2x nodes will be banned from the legacy network for relaying >1mb blocks. Since there are more frequent disconnections due to bans, the legacy addrman will stop prioritizing sw2x addrs as highly, and maybe drop them altogether.

This same situation applies to the hardcoded mainnet seeds. Assuming the majority do not switch to the segwit2x branch, it could cause similar issues.

This results in a situation where a new segwit2x nodes may not be able to find any compatible peers to connect to initially.

There's probably a couple ways to prepare for this, here's one I'm thinking of:

1. Segwit2x implements a service bit, marking support for segwit2x (make it a high bit, since there's currently a few different proposals competing to use service bit 5/6, I think).
2. Someone willing to run a segwit2x-friendly DNS seed server runs one. This DNS seed server is shipped with the first production release of segwit2x.
3. The DNS seed server responds with all addrs, until the HF occurs, at which time it will only respond with addrs which have the segwit2x service bit.
4. During the interim between segwit and the HF, any volunteer here willing to collect enough segwit2x addrs to create a new hardcoded seed list can do so, which would be shipped with the next release of segwit2x.

As time goes on, this will be less of an issue. But the initial bootstrapping of the p2p network might have to be done this way.

[theslagter]

why not wait with the hardfork if a split is such a concern?

[christophebiocca]

Segwit2x implements a service bit, marking support for segwit2x (make it a high bit, since there's currently a few different proposals competing to use service bit 5/6, I think).

What's the benefit of this over simple major-version filtering (since a bump of that is already landed)? Conceptually, major-version bump does seem to represent the underlying reality better than a service bit (major-version -> mandatory, service-bit -> optional).

The DNS seed server responds with all addrs, until the HF occurs, at which time it will only respond with addrs which have the segwit2x service bit.

If SPV clients cache their connected nodes, the switchover should probably happen beforehand, (say, CACHE_EXPIRY before + some margin in case blocks are mined quicker than expected)?

[benkloester]

@theslagter A P2P split will occur whether this hardfork is in 3 months or 3 years, so there needs to be code to account for that and ensure that bootstrapping remains possible, either via DNS or hardcoded seeds. Those seeds obviously need to be running Segwit2x.

[christophebiocca]

I'm assuming we'll want the operator to follow a variant of https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md, except tweaked to include the segwit2x filtering cutover as well?

I'm going to look at the work required in running such a service.

[christophebiocca]

Ok, looking deeper into this:

We're definitely going to want a filtering seed DNS server, for testing purposes, even before Block X occurs.

DDOS risk.

We'll need to harden that infrastructure against DDOS attacks, or it'll be the single biggest point of failure for the system around the time of the hardfork (especially for SPV nodes, see below).

This probably means having the DNS hosting be run on beefy infrastructure, or even outsourced (AWS Route53 would have no issues with arbitrarily high volume). Unfortunately this might run afoul of the no-metadata-collection clause (because AWS, IIRC, collects tons of it) of the DNSSeed policy. Of course, that policy is for Bitcoin Core, we could have a different one that disallows metadata collection by the operator, but not by the hosting service (although that's kind of an arbitrary split, since the hosting service usually makes most of this info available to the operator). On the other hand that's the kind of change that leads to massive amounts of accusations of misbehaviour, even when done with the best of intentions. It should only be done as a last resort. Instead, merely using multiple DNS servers and taking good advantage of DNS caching to protect against short outages should do the job.

SPV client considerations.

Most SPV clients (at least bitcoinj, possibly others) tend to go back to the DNS seeds at each boot, and hold on to essentially no peer-list. This means SPV wallets would be vulnerable to being on the shorter chain if they keep their current DNS seeds list, and the operators of those seeds decide to blacklist segwit2x nodes (which they could argue to be "nonfunctionning" in the sense of not following Core consensus). The 6 seeds on latest master for Core are run by Pieter Wuille, Matt Corallo, Luke Dashjr, Christian Decker, and Jonas Schnelli, so this is not unthinkable. So at a minimum this new DNS seed should come up relatively early, and SPV wallet makers that want to guarantee being on the "big" side of the split will have something to use (and won't have to rush an update out to their nodes at the last minute).

[MickSHunt]

changing btc1 to a different service bit is literally causing a bilateral split(altcoin). how about just leave the service bit alone and if btc1 activates everyone has to upgrade to a segwit2x compatible node or just be left unsynced. meaning its a true network upgrade rather than a 2 chain split where more drama continues for months with fighting over which is the "real bitcoin".

in short make it mandatory to upgrade if btc1 activates

[christophebiocca]

@MickSHunt the service bit:

1. Doesn't exist yet, it was a suggestion to help spot which nodes are 2MB ready. Right now code is already landed to bump the major version, so we'll probably use that instead.
2. Cannot cause a chain split, nodes ignore service bits they don't understand.

Maybe you're thinking of the block bit 4 for signalling? That's a different thing entirely, although on its own it cannot cause a bilateral split.

[MickSHunt]

@christophebiocca

'ignore service bits they dont understand'

exactly!! thus ignores chainbtc1. thus bilateral split(altcoin) by changing the service bit, legacy nodes and other implementations of segwit which use the legacy service bit will ignore btc1 nodes. meaning btc1 becomes a separate network because its not communicating with legacy nodes. what needs to occur is legacy nodes need to communicate but then find out they are being left behind(orphaning blocks and kept unsynced).. not ignoring and continuing as a minority/majority separate chain with other that are on same service bit, while btc1 on a different service bit/network

[christophebiocca]

by changing the service bit, legacy nodes and other implementations of segwit which use the legacy service bit will ignore btc1 nodes.

No, I mean they don't do anything if they see a service bit they don't know how to deal with.

Your node will not be split from the network merely for advertising an unknown service bit. For example BU/Classic uses a service bit to signal XThin support and this did not result in a netsplit.

[MickSHunt]

i understand the positive possibility of it. but you have to understand the negative as it says above

3. The DNS seed server responds with all addrs, until the HF occurs, at which time it will only respond with addrs which have the segwit2x service bit.

now imagine a jgarzik DNS seed 'only respond with addrs which have segwit2x bit.' and a luke/sipa/ and other core devs dns lists legacy service bits. where the nodes are set to ignore each other. they will form two networks.

however if segwit2x activates. all nodes should upgrade to segwit2x anyway. so segwit2x becomes a default rule and not treated as an 'optional service' which one DNS can choose to list nodes of and other DNS choose not to..

[benkloester]

now imagine a jgarzik DNS seed 'only respond with addrs which have segwit2x bit.' and a luke/sipa/ and other core devs dns lists legacy service bits. where the nodes are set to ignore each other. they will form two networks.

Post hardfork that is the desired behaviour, as the clients not setting the service bit will not recognize Segwit2x blocks as valid anyway and will not relay them (and in fact will ban them from their P2P network).

[christophebiocca]

If you really wanted to keep peers from banning each other you could only conditionally relay >2MB blocks only to nodes that have major-version set to 1 or higher, and since the code that invalidates <=1MB block at block X doesn't add to a node's ban score for relaying a too-small block, it would keep the peer network fully connected (not that that gives you much benefit at all).

The problem with that is that even if this were to happen, the chains would still be separate. That's inherent in a hard-fork (bilateral or not): Old nodes will reject (some) new blocks (in this case they will reject the first block produced under the new rules). So trying to keep the nodes together in one P2P network is an academic exercise, it doesn't actually fix the issue of a chain split.

[MickSHunt]

@christophebiocca

So trying to keep the nodes together in one P2P network is an academic exercise, it doesn't actually fix the issue of a chain split. but by playing with service bits does more to ensure a split rather than just unsyncing due to orphans

[christophebiocca]

Again, service bits (if we even had one, which we don't) will not make non-supporting nodes ignore/ban your node (you can turn on every service bit on a node today, and the worst case outcome is that other nodes will try to send you messages you don't understand, because they think you support a protocol extension that you don't actually support). They're meant to be a "I support this optional/extra protocol, on top of the basics".

What is going to cause the network split is the fact that SegWit2X nodes will relay a block larger than 1MB, and get banned for it. Once that starts happening odds are that the crawlers populating Core's DNS seeds will no longer be able to reach the SegWit2x nodes, and so they won't show up in seed lists.

In addition, the DNS seed crawlers could be trivially modified to drop nodes that look like they support SegWit2x from their lists. There's not much we can do about that at all short of looking exactly identical to Core nodes, including not relaying > 1MB blocks, which defeats the whole point of the process.

This entire issue is to deal with the aftermath of that. We can't get banned for service bits because we don't even have one yet (and the new DNS seed I'm working on setting up doesn't use them at all, so we probably won't have one ever).

If you think it'd be worth it (or even possible) to keep both the P2P network in one piece and avoid a chain split, I highly recommend writing up a proposal and filing a separate issue for it. There's nothing this issue can do that'll decrease/increase the chance of a network split. It just tries to mitigate the consequences of such a split.

[magmahindenburg]

Bitcoin.com would be happy to build a DNS seed service for this.

[christophebiocca]

@magmahindenburg You can take Peter Wuille's DNS seed code, which already exists for this purpose, and adjust it to support major-version filtering.

Alternatively I'm building a new codebase to do the crawling/indexing/DNS-serving that'd be more modular and has built in support for major-version filtering. This might be useful if you're already running your own DNS infrastructure as the components doing the serving will be separately usable from the ones doing the crawling.

[jgarzik]

DNS seeds listed in segwit2x client will need to return nodes that support 2M blocks. (we just discussed this on the segwit2x tech call)

[christophebiocca]

@jgarzik from the first day they run? No cutoff date (makes my life easier, just confirming)?

Any objection to major-version filtering to achieve that goal?

[jgarzik]

What best serves users is a wide spread of DNS seeds, run by different people/orgs, which return 2M-capable nodes. That can occur via major version filtering, or a version bit as OP title indicates, and as @jameshilliard has suggested.

This doesn't matter so much in the short term, when the network is in the transition SegWit-and-1M state, but it does matter that new seeds + code is in place well before 2M HF.

[kleetus]

The dns seeds in bitcoin core have always been an irritant of mine. I like @christophebiocca idea of the crawler. In the short-term, dns seeds pointed to a cross-section of diverse nodes seems logical until such time the crawler becomes viable. Preferably, if we can get a seed from all 5 major bitcoin constituencies (miners, web wallets, exchanges, merchant processors and non-mining full node operators) this would be great good.

[christophebiocca]

@kleetus, sorry, I don't think I understand the distinction you're making here? The crawler is just a way to populate DNS seeds. I just figured it'd be easier to build it that way than to try and adapt a relatively monolithic codebase that does crawling, monitoring, and DNS serving all at once.

Nodes need a way to connect to their first peer or they'll never bootstrap. That's the purpose of the DNS seeds.

[kleetus]

@christophebiocca I am not sure I am making any distinctions here. Until the crawler can perform this task (which I think is needed), we should change out the existing seeds with ones that will be useful after the hard fork.

[jgarzik]

In case it wasn't clear - concept ACK - definitely on the todo list

[jgarzik]

PR #74 addresses part of this: DNS seeds update.

Another change to advertise NODE_SEGWIT2X service bit is part of the picture too.

[adam3us]

can others gain access to the "just discussed this on a conference call"?

[jgarzik]

All points outlined by @chjj should be taken care of at this point.