An `elementsd`-compatible fork of `corepc` for unified RPC client support

[philipr-za]

Background

The rust-bitcoin ecosystem has converged on corepc as a unified library for managing RPC communication with bitcoind. It provides versioned, type-safe client bindings for Bitcoin Core's JSON-RPC interface and is actively maintained alongside rust-bitcoin itself.

rust-elements currently has no equivalent. Downstream projects that need to talk to elementsd end up writing their own ad-hoc RPC clients on top of jsonrpc. For example, liquid-functionary maintains its own rpc.rs. This is duplicated effort, and the resulting clients tend to lag behind upstream changes, cover only the methods each project happens to need, and have inconsistent type definitions.

Proposal

Create an elementsd-compatible fork (or sibling crate) of corepc that:

1. Keeps all the common parts of corepc unchanged. The elementsd RPC surface is largely a superset of bitcoind's — the majority of methods are either identical or close enough that corepc's existing types can be reused directly.
2. Overrides the subset of methods that differ. Some Bitcoin Core methods return different or extended data on elementsd (e.g. anything involving amounts/assets, blinded outputs, or pegged-in coins). These need Elements-specific response types.
3. Adds the Elements-only methods. Things like getsidechaininfo, getpeginaddress, claimpegin, rawblindrawtransaction, issueasset, listissuances, asset/token RPCs etc. would need to be added.

Structurally, this could be done either as

1. A fork of corepc
2. A separate crate that depends on corepc and re-exports/extends its types

Open questions

• Fork vs. extension crate: I am not sure which is easier to maintain?
• Versioning is a little tricky as in corepc there are versions of the interface that track the Bitcoin releases and Elements also tracks the Bitcoin releases but also has its own versions.

[apoelstra]

Because of the versioning complexity we almost certainly want to maintain a fork of types, rather than attempting an extension crate of some sort.

For client I think we can cheat and define our own fork which depends on corepc's client and just calls its macros to define our own Client struct etc.