You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like it's based on electrs, how much of an effort would be make it work for elements chains?
Not that confident yet with Rust, but I could try to make contribution if you think is feasible to use the same codebase. If not, would be better to do it as a fork?
It's actually just the electrum server implementation (src/electrum/server.rs) that's based on electrs, the index and query engines are separate, so it can't benefit much from bs/electrs's support for elements.
It should however be feasible do to this in a manner similar to how bs/electrs does it, with a compile time flag that switches the data types to elements's and adds some special-case behaviors for CT, issued assets and peg ins/outs.
Can you tell me a little more about the use-case? What are you looking to do with this?
For the time being Blockstream's fork of electrs (namely Esplora?) is the only explorer out there for elements. It's optimized for "enterprise" workflows, but as a "personal" indexer use cases a bit less (ie. too much resource hungry).
When I say personal, I mean "hey this is my xpub, please notify myself when new transactions are coming in related to this wallet, don't care about indexing others"
Therefore HTTP2 server-side sent push (or maybe gRPC streaming even more) would be very useful for couple of micro-services I run.
I think then at this point I would go with doing then a PoC that uses zmq notifications of an elements node to get blocks, and a custom block/tx parser that filters per script of a given xpub.
The idea is to keep the same exact RES API as Esplora plus server-side push/streaming, to make sure clients are cross-compatible
I can definitely see how it could be useful to make this available for elements. I will look into this, but it probably won't happen soon. Will gladly accept a PR if it doesn't overly complicate the codebase.
Activity
shesek commentedon Feb 22, 2021
It's actually just the electrum server implementation (
src/electrum/server.rs) that's based on electrs, the index and query engines are separate, so it can't benefit much from bs/electrs's support for elements.It should however be feasible do to this in a manner similar to how bs/electrs does it, with a compile time flag that switches the data types to elements's and adds some special-case behaviors for CT, issued assets and peg ins/outs.
Can you tell me a little more about the use-case? What are you looking to do with this?
tiero commentedon Feb 22, 2021
For the time being Blockstream's fork of electrs (namely Esplora?) is the only explorer out there for elements. It's optimized for "enterprise" workflows, but as a "personal" indexer use cases a bit less (ie. too much resource hungry).
When I say personal, I mean "hey this is my xpub, please notify myself when new transactions are coming in related to this wallet, don't care about indexing others"
Therefore HTTP2 server-side sent push (or maybe gRPC streaming even more) would be very useful for couple of micro-services I run.
tiero commentedon Feb 22, 2021
I think then at this point I would go with doing then a PoC that uses zmq notifications of an elements node to get blocks, and a custom block/tx parser that filters per script of a given xpub.
The idea is to keep the same exact RES API as Esplora plus server-side push/streaming, to make sure clients are cross-compatible
shesek commentedon Feb 22, 2021
BWT provides a real-time streaming API for wallet events (also available via WebHooks) and has an HTTP API that's somewhat similar to Esplora, but also different in some ways.
I can definitely see how it could be useful to make this available for elements. I will look into this, but it probably won't happen soon. Will gladly accept a PR if it doesn't overly complicate the codebase.