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

Bắt đầu bằng cách so sánh interface corepc với các phương thức dành riêng cho Elements được liệt kê trong proposal, sau đó đọc rpc.rs của liquid-functionary làm ví dụ về phần công việc client bị trùng lặp. Quyết định xem fork hay extension crate xử lý các kiểu dùng chung và việc versioning tốt hơn. Hoàn thành khi một RPC client tương thích với elementsd bao phủ các phương thức khác biệt bắt buộc và các phương thức Elements-only bằng một cách tiếp cận versioning có thể bảo trì.

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.