Add (insecure!) Bitcoin headers over DNS support

[petertodd]

Disabled by default.

Use this with Matt Corallo's https://bitcoinheaders.net/ service.

[RCasatta]

Nice!

I understand not providing a default value for the dns-data provider makes sense but citing bitcoinheaders.net in the command help or in the readme would make the user not knowing the strategy able to use it and inform himself/herself

[petertodd]

Yeah, I think before this is actually merged it should be easier to use.

But first, I want to figure out how to make this more secure. It should have some kind of minimum work threshold, or signature check. Matt's service is signed with DNSSEC. But there's no good way to validate DNSSEC signatures client-side.

The issue with a minimum work threshold is for older timestamps you need to validate a lot of headers to get a reasonable amount of total work. ASICs have gotten much better over the years.

[TheBlueMatt]

Please dont check this, just ignore it. The block header is self-validating by PoW :p

[petertodd]

Actually, that's kinda what I'm doing with that check: if some addresses are added, without the right prefix, they'll be ignored on the off chance that the remaining addresses are a valid block header.

But yeah, I don't actually check PoW in this version of the code so...

[TheBlueMatt]

Hmm, but I kinda wanted the ability to change the prefix arbitrarily on the server side without it impacting clients.

[petertodd]

Ah! Well, if you're going to do that, you should document that.

[petertodd]

The issue with a minimum work threshold is for older timestamps you need to validate a lot of headers to get a reasonable amount of total work. ASICs have gotten much better over the years.

So difficulty as of Sept 2016, when OpenTimestamps in its current form was released, was 220 billion. Currently it's 64 trillion. So 291 blocks worth of 2016 blocks are equivalent to one block today. Older timestamps do exist, as other timestamps can be converted to OTS format. But they're pretty uncommon. By 2019 difficulty had risen to 6 trillion, which is already ~1/10th of the current difficulty.

In terms of a dollar value, the current 6.25 BTC block reward is worth $230,000 today. So one 2016 era block would cost $790 in terms of lost revenue to make. It's probably good enough to just have a sum difficulty target, and query block headers (in parallel) until that target is reached. One or two current-era blocks is probably fine: for use-cases where someone would actually spend ~$200k to fake some timestamps, you're probably checking more carefully than with DNS anyway.

It also wouldn't be a bad idea to do this via a timeout: fetch as many headers as you can in, say, 5 seconds, even if you've gotten more than the target amount. We can cache headers of course too, so this would help with subsequent validations too.