From what you wrote I can see that you want to different libraries:

1. Lib just for Electrum RPC protocol. You want it process-less
2. User-friendly Electrum interface with more high-level operations

So I can see 3 layers in this program

1. TCP connection pool management. To connect to peers and communicate with them.
2. Electrum JSONRPC protocol
3. High-level API for the user (without scripthash, etc)

The connection management

Alright, I’ve read the python library and I can see that these RPC calls operate over some state (SessionManager class holds global state of all sessions, and connection to a PeerManager which maintains TCP connection to max 8 peers). And you’ll need to handle this state somehow. In erlang and elixir world we use processes for that.

And there are two options for the process. You can make it a global singleton, or a local process. If you want to maintain exactly the same API as in ElectrumX, you’ll need to create a named singleton process. But I’d suggest making library more flexible and isolating process names from it. So, I’d go with SessionManager as a Supervisor module which starts DynamicSupervisor, Registry and starts ElectrumConnection processes under the DynamicSupervisor. This SessionManager can take a name during the start. Each ElectrumConnection holds connection to one peer

And the module would provide these functions

• SessionManager.add_peer(session_manager_pid, peer_opts) to add a peer. This will start the new connection process under the dynamicsup, name it in the registry.
• SessionManager.connect_peer(), SessionManager.disconnect_peer, etc. for peer management
• SessionManager.pick_connection() – randomly picks one connection (you can chose different strategy)
• SessionManager.execute(connection, operation, reply_to) – this one just passes an Electrum operation to the connection process which should send the result to reply_to pid

This is basically how the process pool operates. I can suggest you to take a look at libraries like poolboy

Electrum JSONRPC

This part of the system is a thing that you wanted to be a process-less library for just parsing and handling responses. The problem with your approach was that you wanted it to be somehow coupled with tcp connection, which is a bad way to go.

I’d suggest spliting this into two things:

1. Converting elixir structure for operation into the binary with jsonrpc request/response in it. This is a pretty straightforward thing to write. You can use any data validation library you prefer, but I don’t see any problem in hand-rolling this.

2. Sending and receiving data over TCP as a JSONRPC spec defines. This was already done in libraries like this: GitHub - fanduel-oss/jsonrpc2-elixir: JSON-RPC 2.0 for Elixir · GitHub

Highlevel user interface

Just create something like Electrum.subscribe which internally calls already started global SessionManager and awaits the response

The data comes from an Electrum RPC endpoint, which is what most Bitcoin wallets use to transact.

For instance, the blockchain.scripthash.subscribe is mostly what I am talking about. So, the data lib I was talking about would connect to this endpoint and make sure it subscribes to a specific scripthash.

But what’s a scripthash???

It’s jargon that Bitcoin wallet devs might not want to deal with. In other words, it’s another representation of an address. This call, in short, returns transactions relative to a specific Bitcoin address as they happen.

The goal here is to not only enable devs to connect to this thing, but make it easy and relatable. Ideally, they’d just initiate a connection, passing an IP and a port and then subscribe to a specific address. This is, of course, in the Bitcoin layer lib’s language. Under the hood, it would handle the electrum lib and isolate the dev from all the scripthash gibberish we initially talked about. Not to mention there’s some data conversion involved in the process.

Why not combine both in a single lib, you might ask… because the raw Electrum lib

• Could be used for other purposes someday
• Would be easier to maintain if kept 1:1 with the Electrum RPC specification