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

Open
#268 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
rust
Domain
api, backend

Research direction

Start by comparing the corepc interface with the Elements-specific methods listed in the proposal, then read liquid-functionary's rpc.rs as an example of the duplicated client work. Decide whether a fork or extension crate best handles shared types and versioning. Done means an elementsd-compatible RPC client covers the required differing and Elements-only methods with a maintainable versioning approach.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Rust
Stars
57
Forks
40
Avg merge
11h 58m
Merged PRs (30d)
1

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ElementsProject/rust-elements

All issues in ElementsProject/rust-elements

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.