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

Comienza comparando la interfaz de corepc con los métodos específicos de Elements enumerados en la propuesta, y después lee rpc.rs de liquid-functionary como ejemplo del trabajo duplicado del cliente. Decide si un fork o una crate de extensión gestiona mejor los tipos compartidos y el versionado. Se considera terminado cuando un cliente RPC compatible con elementsd cubre los métodos diferentes requeridos y los métodos Elements-only con un enfoque de versionado mantenible.

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.