Remove testnet-seed.bitcoin.petertodd.org from testnet seeds. That domai... #4203

...n doesn't resolve for at least a week.

Calling @petertodd

As I said privately to schildbach I'm out of country and don't have the ability to log into that server for another week. (Laptop died unexpectedly)

As discusses on the mailing list DNS seeds should be best effort; inability to handle them being down is a security issue.

Anyway, if you want you can have your funds back from the grant.

Let's just wait another week or two then. There is no hurry here, it's not like the change would propagate instantly. Also, bitcoind should be able to handle non-working DNS seeds fine, so if it doesn't this is a good test case.

Thanks. And yeah, a week ago I thought it'd just be a week but unexpectedly found myself changing plane tickets yet again to speak at the Tel Aviv Bitcoin meet up next week.

@petertodd You just pointed at other people so I assumed you won't look at it. @laanwj I heard of at least of one case of bitcoin-qt not being able to bootstrap, because Matt's node (the only one returned by his seed) is also down. So if this is a test case, it has failed.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/780319e81ec4fc6c675b9ed548b01933c0db799d for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

Semi-failed - in bitcoin-qt you can just use -addnode once of course and after that you don't need the seeds again. Other apps are less robust of course.

@schildbach Please stop relying entirely on DNS seeds in the Android Wallet.

@wtogami I don't see any alternative for bootstrapping. IRC seeds have been abandoned a long time ago. Hardcoded nodes get outdated very quickly. I only see the user enter an own peer, and that's supported since 2011.

Bitcoin Core has a hard coded fallback list. (we need to add that for testnet for code parity at the very least)

Secondly bootstrapping should only need to be done once, not every time the node starts up.

@petertodd Hardcoded nodes get outdated very quickly. Heck, even hardcoded DNS seed lists get outdated very quickly, as proven by the current situation.

I agree about further node startups. That part just hasn't been coded, and it cannot be done with the current bitcoinj API.

I'm not sure I'd call the current situation "outdated" - again, the seeds are best effort. In particular, just removing a non-malicious, if incompetently run, seed isn't very useful compared to adding another redundent one.

@schildbach If all the bootstrap nodes are down you can hardly blame the software. Removing bootstraps isn't going to solve the problem in that case. It would remove all redundancy.

If bootstrapping for the testnet is important we need more bootstraps not less.

Closing this.

@laanwj It wasn't me blaming the software. Maybe you're referring to @wtogami 's comment?

I'm trying to contribute by keeping the list of seeds up to date. If that means at some point we have no seeds any more, well then we're at least honest about the situation.

I'd appreciate if we could keep this pull open until the issue is resolved.

@schildbach I think your definition of "up to date" is flawed: if my DNS seed is up 90% of the time, and someone else's is up 90% of the time, we've got 99% uptime between the two of them. (Uncorrelated obviously) A much better pull request would be the addition of another DNS seed. Perhaps you want to run one?

Whether or not the development fund is getting good value for its money is another matter; obviously I'm not a very competent sysadmin. But hey, I'm going to wind up visiting five countries before getting home when I was expecting to visit just one; I'm probably not the right person for it.

I'm not sure why we're even discussing to remove a seed simply because of some downtime. If the seed would be up 50% of the time, that would be enough to justifiy having it configured. And as long as it will come online again before the next release, there's absolutely no point in removing it just to add it again.

If the seed would be gone forever this would be another issue, but as it seem it will be back up in a few days.

@schildbach Right, I think there is a misunderstanding here. The list of seeds in chainparams.cpp is not meant to be a day-to-day reflection of which DNS seeds which are up. That would result in a lot of git diff chatter :) If it was down for months at a time, I would agree with you and remove the seed.

Maybe someone should write a document with requirements for DNS seeds. But having 99% uptime is not one of those. Due to the nature of P2P networks I'd rather have more, sometimes unreliable DNS seeds than a few very-reliable ones.