Fallback to bitcore.io fails when trest.bitcoin.com is returning error

[pybitcash]

Fallback to bitcore.io fails when trest.bitcoin.com is returning error

[selfdrivingmenee]

Doesn't work for me.
The few times it works it's the few times the trest.bitcoin.com API works.
Seems to me that the lib fails to call the second API.

[selfdrivingmenee]

I forked you to do some testing. I'll add a different differnet API provider and submit pull request to your repo. May you look in why the fallback to seconday API was failing? Thanks :-)

[CryptoSecEd]

@selfdrivingmenee Which provider are you looking at? I've found this one, which should have testnet support: https://api.fullstack.cash/docs/

[merc1er]

It seems that the fallback does not work for key.get_balance('bch')

A temporary way to fix this:

key.get_balance() / 100000000

The get_balance() method's fallback works.

I will investigate the issue with the 'bch' argument.

Edit: get_balance() worked because trest worked for a second for whatever reason, but indeed fallback does not work.

[merc1er]

I just learned that trest.bitcoin.com was intentionally taken down as no longer maintained.

[selfdrivingmenee]

ouch! I imagine still that this bug propagates to the non- test version on the library tho

[merc1er]

@selfdrivingmenee Which provider are you looking at? I've found this one, which should have testnet support: https://api.fullstack.cash/docs/

I've also been looking at this one, very similar to rest.bitcoin.com and even fast.
My only concern is that the free tier has very low API limits: only 3 requests per minute allowed 🤨

But would be good to include it as a fallback!

[selfdrivingmenee]

I swapped the current fallback API with the main one and things got back in working order.
As a fallback API I'm testing (not in the lib) cryptoapis.io , they require a (free) API key but being (also, with "paid" key) commercial provider they offer an SLA so I think it's interesting to have them supported.

Side note: main chain (and even some nodes on the testnet) accepts max one OP_return per each transaction so the splitting system for long messages should be changed. I'm evaluating the various tx chaining solutions, should I open a separate issue?

[merc1er]

@selfdrivingmenee did you start working on a PR already?

If not, I will start working on fixing this.

[selfdrivingmenee]

Not working on a PR yet. As my 2c goes, I'd first take advantage of the non-operative bitcoin.com trest to fix the fallback system and then add another provider :-)
I'll update you on how my search for a provider goes

[merc1er]

@selfdrivingmenee could you test #65 on your end?

I tested it in a few different ways:

• editing the main endpoint's URL to an incorrect URL (ex: https://trest.bitcoin.com/1nc0rrect/)
• blacklisting trest.bitcoin.com in my Hosts file
• blacklisting main endpoint domain name in my router's DNS

Edit: Travis-CI and local tests passed

[selfdrivingmenee]

Working on my side, thankyou!!!
I did my testing, I'd suggest cryptoapis.io as the backup one introducing an initialization variable "API KEY". They work great and also allow for a very easy commercial integration.