Hi, Calin here. I noticed bchd
is almost there with respect to featureset.
I'd very much like to switch Electron Cash over to bchd as its wallet service/backend/data provider and move away from ElectrumX for basically two reasons:
- The maintainer is antagonistic towards BCH
- ElectrumX (and the version we maintain, Electron X) has serious performance and scaling issues because it is written in Python
This is a short list of items I feel is required and that bchd apparently seems to be missing:
Minimal delay is needed when switching servers and/or when connecting to a new server. This means that the wallet sending the server its addresses and synching with the server's view of the blockchain needs to be fast and minimal in terms of chatter or delay.
Suggestion: Add a protocol command similar to the blockchain.scripthash.subscribe method provided by ElectrumX whereby the wallet can basically tell the server which addresses it is interested in, and the server replies with a digest or hash or some other composite value of the history for each of the addresses in question. This has the advantage that if the client's view and the server's view of the blockchain agree (the common case), no further communication is required to retrieve the full history per address, thus saving time, bandwidth, and overhead, and improving the UX.
Minimal bandwidth consumption and/or delay is needed for verifying transactions -- ideally you want to avoid sending the whole block to prove a tx was in a block, but rather, you do something clever like use merkle proofs. Something akin to ElectrumX's blockchain.transaction.get_merkle is needed to accomplish this.
This is needed by CashShuffle. The client needs to be able to look up any arbitrary address and get a list of the UTXO set for that address. I didn't see such a protocol command in the bchd docs but maybe I missed it. Apologies if that's the case.
ElectrumX has a clever "checkpoint" mechanism whereby blocks before the checkpoint height use merkle proofs as well, See the ElectrumX command: blockchain.block.header. This saves on needing to download headers for blocks before the checkpoint if the blocks in question do not contian any tx's involving the client's wallet.