Previous Replacement of addrindexrs and 3rd Party Reliance

[davestaxcp]

Why replace addrinexrs with a electrs on a protocol level?

What were the issues with addrinexrs, what are the advantages of using electrs instead?

Did reliance on electrs (blockstream.info reliance) cause xcp to not be usable (parse txs) in Dec of last year? Why?

How many "3rd party dependencies" are there to run the counterparty protocol?
Is there a better way to be self-sustaining in the event blockstream.info goes down for a few days?
Are there other risks like that in the current protocol?

[adamkrellenstein]

electrs isn't a consensus-critical dependency (like AddrIndexRs was)—it's just used for transaction construction, and any electrs compatible API can be used in its stead. Relying on blockstream.info by default makes things a bit fragile (if it goes down, tx construction stops working, but transactions still parse!), so there's an open issue to have configurable fallbacks: CounterpartyXCP/counterparty-core#3255

There are zero third-party dependencies, besides Bitcoin Core, for parsing + consensus.

[davestaxcp]

if it goes down, tx construction stops working

this is pretty frustrating to users and a bad look!

Users during that time were recieving a 'Counterparty API Error: ...... blockstream.info ....." and wondered why tx creation relied on that at all.
Thus stopping anybody from creating an xcp tx during that time.

---

but happy to see it is being discussed and addressed in CounterpartyXCP/counterparty-core#3255