Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[esplora] Expose ElectrumX endpoints #168

Open
altafan opened this issue Nov 18, 2022 · 6 comments
Open

[esplora] Expose ElectrumX endpoints #168

altafan opened this issue Nov 18, 2022 · 6 comments

Comments

@altafan
Copy link
Collaborator

altafan commented Nov 18, 2022

Similarly to esplora block explorer, we should expose ElectrumX endpoints through websocket.

We could run a second service websocat inside electrs containers in order to expose the websocket (in my test, I ran it in a dedicated container with the command docker run --net=nigiri -d -p 1234:1234 ghcr.io/vi/websocat:0.11.0 -b ws-l:0.0.0.0:1234 tcp:electrs-liquid:50001 but it shouldn't be a problem to run inside electrs).

At this point, it would be enough to expose the port over which websocat runs to expose ElectrumX endpoints. Still, I think it could be worth adding an /electrum-websocket/api endpoint to access those endpoints in order to:

  1. hide the websocat service to the user
  2. stick with blockstream esplora APIs.

Another thing I noticed from my tests is that esplora has /scripthash endpoints:

Not sure why they are not working but maybe we're missing something in the config of esplora, in the way it connects to the underlying electrs service. We should investigate on this. In case we don't figure this out, the fallback would be making those endpoints available via chopsticks.

@tiero
Copy link
Member

tiero commented Nov 18, 2022

Not sure why they are not working

Worth raising the issue to the Esplora repsoitory also? You can also check their dockerfiles

@tiero
Copy link
Member

tiero commented Feb 3, 2023

As we may having some issues in packaging websocat inside the container vulpemventures/docker-electrs#6

Quick & Dirty let's add a new container just for websocat, behind a --bitcoin-electrum-ws & --liquid-electrum-ws flag respectively? cc/ @altafan

@altafan
Copy link
Collaborator Author

altafan commented Feb 3, 2023

I would hide these services to the user by exposing no flags. Let's always start them. We can then "hide" them with chopsticks by overriding the ws endpoints.

This can be a solution, but we should investigate how to correctly configure esplora to enable these kind of "third-party" endpoints (we don't have any endpoint for the asset registry too) before opening an issue.

@tiero
Copy link
Member

tiero commented Feb 3, 2023

Let's always start them

My concern was to not have 2 more containers running all the time, if not needed. (That's why we were trying to stuff it inside the electrs image). But ok

how to correctly configure esplora to enable these kind of "third-party" endpoints

How think I am fine to just have in localhost to connect to different port than the Electrum TCP. We already do this for electrs API, esplora UI etc...

Otherwise, we need to introduce a reverse proxy if we want to be "100%" close to Blockstream production (caddy, traefik, ngnix etc..), but yes should be a separate issue from just having a websocat running.

@altafan
Copy link
Collaborator Author

altafan commented Feb 3, 2023

So, to recap, let's add 2 new websocat containers for btc and liquid respectively, without any new flag. These services are started just like the others.

We override the esplora ws endpoints with chopsticks.

@tiero
Copy link
Member

tiero commented Feb 3, 2023

We override the esplora ws endpoints with chopsticks.

dont even need to do that. Just exposing websockets on ie. 55000 and 55001 should be fine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants