search

AustEcon / bitsv

BitSV: Bitcoin made easy. Documentation:
https://AustEcon.github.io/bitsv
MIT License
96 stars 28 forks source link

Migrated bchsvexplorer to bsvbookguarda, which replaces it. #78

Closed xloem closed 3 years ago

xloem commented 3 years ago

I was having an issue and emailed bchsvexplorer, and guarda.co's support told me that bchsvexplorer is outdated, and that bsvbook.guarda.co replaces it with a modern api.

ghost commented 3 years ago

Not familiar with bsvbookguarda, but looks good at first glance.

AustEcon commented 3 years ago

Great. Thanks for keeping on top of this.

I'm stretched quite thin just at the moment. Can I come back to this on the weekend?

xloem commented 3 years ago

It's the new version of bchsvexplorer according to the support team at guarda.co, who run it. Regarding the weekend, of course, thanks for touching base.

AustEcon commented 3 years ago

I kind of agree with @kcentrifugal about leaving the paging mechanics and generator expression to one side at the moment

Reasoning: bitsv is not intended to be heavy-duty client software for pulling in thousands of txids (or indexing a bitcom namespace for example). At least, I don't have the time to spend on bitsv right now to allow the scope to creep out.

I have pushed what I think is a reasonable compromise to the above: fca4767

Basically it just always pages through all txids and returns a list of txids (which keeps the return type the same as all other APIs).

This will obviously be very bad for thousands of txids but I don't think that usecase is appropriate anyway (at least I don't have the ability to support it right now and if I did, I wouldn't be using slow, clunky RESTAPIs for it...

Really you'd be looking at a bitsv2.0 async library that hooks into something more like ElectrumX (and whatever services rival it)

But feel free to fork bitsv and make your own way 😃 I do not want to be a blocker for anybody's building - you all have my blessing 🙏

PS: Sorry @xloem that git is not showing you in the commit history for this one... I had to mix in quite a lot of other changes and I don't know how to force dual authorship.. hope you don't mind.

xloem commented 3 years ago

should be fine enough. thanks for your efforts @AustEcon. the reason for many txids was to open avenues for implementing the D:// protocol when many BCAT:// files have been uploaded. I infer that electrumx is the way to go for such ideas.

xloem commented 3 years ago

note: for polyglot, that might mean porting to use electrumx for general D:// use, if there's no backend interface here that would provide for it

AustEcon commented 3 years ago

I don't know sorry. I haven't looked at _unwriter's stuff in a long time - been focused more on ElectrumSV wallet which uses ElectrumX currently as the backing indexer and the SDK (https://github.com/electrumsv/electrumsv-sdk), as well as other projects...

But if I were pulling a ton of txids (and txs) from a single heavily-reused address (as a bitcom namespace) or D:// key that has been updated a lot... I'd be reaching for asyncio for concurrent requests.

ElectrumX is my comfort zone but I imagine Bitbus/Bitsocket from _unwriter would have something more tailor made - You'd know better than me though.

AustEcon commented 3 years ago

I have a chain indexer of my own that is mostly complete that will cover all needs and handle scaling-testnet loads but in the meantime, you may need to forge your own path (with all of the planaria / _unwriter stuff) - I hate being a bottleneck for other people so please don't wait around on me - fork if you need to. Make your own libraries for the _unwriter stuff that complement bitsv... There are so many opportunities and so much building to be done... Don't let me hold you up! 😃

But I'll probably keep bitsv quite minimalist and deal with bug fixes and basic maintenance at least in the near-term (6 - 12 months)