Remove local node dependency for client

[meeDamian]

While having this dependency on the server is completely expected and justifiable, requiring it for simple [commit] stamping/verification is not and adds a lot of setup friction.

Translating block height to it's merkle root can be done with one request to some public APIs, ex:

https://blockchain.info/block-height/<height>?format=json.

Understandably, 3rd party API calls might not be desired in the core code, but how about:

• making it available on the opt-in basis (ex. --btc-plugin blockchain flag),
• making it an external, installable module:

echo 'OpentimestampPlugin[plugin-name]>=[version]' >> requirements.txt && pip3 install -r requirements.txt

Example implementation: https://github.com/opentimestamps/opentimestamps-client/pull/11

[petertodd]

I think that's a reasonable idea, but I don't know that we need a full plugin module system for this yet.

Also, I'm very dubious about relying on trusted third parties for this; if we want a lighter weight option, better to add a simple SPV client to python-bitcoinlib and then use that.

[meeDamian]

but I don't know that we need a full plugin module system for this yet.

Agreed - I just couldn't think of a better way to keep third party API calls outside of the main code base.

Also, I'm very dubious about relying on trusted third parties for this

Given your background, I totally understand 😄. However, one could argue that the setup simplification it enables, could provide users with value already, while still leaving door open for the SPV implementation later.

As there's plenty of blockchain APIs out there, how about a verification confirmation only in case of the consensus of n > 1 providers?

better to add a simple SPV client to python-bitcoinlib and then use that.

That I don't know how to do, both in Python and Bitcoin contexts.

[petertodd]

We've seen multiple blockchain APIs return incorrect results at once; they're just not very trustworthy, and I'm very dubious about setting an example here that they are.

I need to do a SPV implementation anyway, so I'll add that to the todo list. Also, remember that running a pruned node is a lot less resources than you may think - mainly bandwidth and a few hours waiting for it to sync initially. I also may be able to make OpenTimestamps use the headers-first support in Bitcoin Core here.

[meeDamian]

We've seen multiple blockchain APIs return incorrect results at once; they're just not very trustworthy, and I'm very dubious about setting an example here that they are.

I did not know about this. Could you point me to some relevant cases/scenarios?

I need to do a SPV implementation anyway, so I'll add that to the todo list. Also, remember that running a pruned node is a lot less resources than you may think - mainly bandwidth and a few hours waiting for it to sync initially. I also may be able to make OpenTimestamps use the headers-first support in Bitcoin Core here.

Thank you :). On laptops, even now, every GB and battery % still matters. I'm perfectly fine with SPV and knowing it's on the horizon I'll just wait until I can switch and use/maintain my fork in the meantime. Pity, I'm not able to contribute with this, though.

Thanks for thoughtful replies and I suppose that issue might be closed now.

[petertodd]

I did not know about this. Could you point me to some relevant cases/scenarios?

I'd have to dig through IRC logs, but as an example, blockchain.info has repeatedly returned totally bogus information, and IIRC when miners doing validationless mining were producing bogus blocks during the BIP65 activation multiple block explorers were returning those blocks as valid.

Note that a pruned node is (currently) under about 10GB or so.

I've added this to the TODO.md file, thanks!

[petertodd]

Oh, and come to think of it, another option that might work for you is to make a RPC proxy that pretends to be a Bitcoin Core node, and in the background sends queries to the block explorer of your choice; I'm sure users of more than just OpenTimestamps would find that useful.

[meeDamian]

That's an interesting approach and a good idea. I like how it requires zero changes to projects already dependant on RPC, and might be used where 100% certainty is not crucial, to quickly run a :octocat: project (with limited functionality) or on really thin nodes.

Do you see any advantage it might have over SPV, though?

[petertodd]

Do you see any advantage it might have over SPV, though?

Less work to write. :)

Of course, if we had a SPV client, that'd be even better!