Electrum protocol support

[brandonblack]

ord could gain even more traction if it could use the Electrum protocol instead of bitcoin RPC.

[andrewtoth]

Unless I'm mistaken, I don't think the electrum protocol is suitable for this type of application. ord needs to process all transactions of all blocks to index sats. Electrum is mostly used for fast lookups of address balances and transactions, and is very slow at serving blocks (if it serves them at all, I think most servers will only serve headers).

[casey]

Thanks for the issue! @brandonblack Can you clarify what you're looking for? Is the desire some kind of light client? Or the ability to use public servers to download block data?

[brandonblack]

Sorry, I'm just getting up to speed on ord here, and I think what I'm getting toward is alluded to in this comment on the overall redb sync performance: https://github.com/casey/ord/issues/1377#issuecomment-1418005263

In short, I think we have < 10 years until fragmentation in the sat space makes fully indexing all ordinal sat ranges out of the reach of most users, so we should probably plan for that future now. To do so, we'd want to produce a lighter weight ord which has probably 2 modes:

1. When directly connected to a full -txindex bitcoin node, it indexes all inscriptions to date (along with potentially some other rare stats of interest).
2. When connected to an Electrum server, it only supports queries for specific sats or UTXOs, eg. "make sure I'm not sending something rare by sending this transaction", and "inscribe this sat and tell me what it's number was, then index it for future".

[tyjvazum]

Sorry, I'm just getting up to speed on ord here, and I think what I'm getting toward is alluded to in this comment on the overall redb sync performance: #1377 (comment)

In short, I think we have < 10 years until fragmentation in the sat space makes fully indexing all ordinal sat ranges out of the reach of most users, so we should probably plan for that future now. To do so, we'd want to produce a lighter weight ord which has probably 2 modes:

1. When directly connected to a full `-txindex` bitcoin node, it indexes all inscriptions to date (along with potentially some other rare stats of interest).

2. When connected to an Electrum server, it only supports queries for specific sats or UTXOs, eg. "make sure I'm not sending something rare by sending this transaction", and "inscribe this sat and tell me what it's number was, then index it for future".

This issue seems somewhat related to issue https://github.com/casey/ord/issues/1501 since both suggest a need for additional code modularization (which I think would be required to support point 2 above).

Additionally, this privacy-focused project might be of interest if Electrum is used: https://github.com/chris-belcher/electrum-personal-server

[casey]

I'm not keen on introducing a dependency on the electrum protocol, or re-implementing it ourself. I think this is really about "make syncing fast" and "create new security trade-offs", and I think those things can be supported without introducing a dependency on electrum. Users already have a hard time getting bitcoind running and connecting to bitcoind, and getting ord running correctly. I don't want to add functionality where getting things running requires configuring an additional service, or which requires complex configuration, so you need Docker or something like it to get started.

In short, I think we have < 10 years until fragmentation in the sat space makes fully indexing all ordinal sat ranges out of the reach of most users, so we should probably plan for that future now.

Years away is a long time! We definitely have bigger fish to fry, like making the current sync model fast.

I'm going to convert this to a discussion so that conversation can continue!