checksum0 / go-electrum Goto Github PK

Responses unmarshaling don't work for errors returned by ElectrumX and Fulcrum servers.

I called the GetBlockHeader function with a block height that doesn't exist.

Unmarshal received message failed: json: cannot unmarshal object into Go struct field response.error of type string

The reason for that is that ElectrumX, Fulcrum, and Electrs/Esplora are inconsistent when it comes to the error response format.
Please see the examples (for Bitcoin Testnet servers):

ElectrumX

✗ echo '{"jsonrpc": "2.0", "method": "server.version", "id": 0}' | netcat 49.12.127.114 10068
{"jsonrpc":"2.0","result":["ElectrumX 1.16.0","1.4"],"id":0}

✗ echo '{"jsonrpc": "2.0", "method": "blockchain.block.header", "params": [4294967295], "id": 0}' | netcat 49.12.127.114 10068
{"jsonrpc":"2.0","error":{"code":1,"message":"height 4,294,967,295 out of range"},"id":0}

Fulcrum

✗ echo '{"jsonrpc": "2.0", "method": "server.version", "id": 0}' | netcat 203.132.94.196 51001
{"id":0,"jsonrpc":"2.0","result":["Fulcrum 1.8.2","1.4"]}

✗ echo '{"jsonrpc": "2.0", "method": "blockchain.block.header", "params": [4294967295], "id": 0}' | netcat 203.132.94.196 51001
{"error":{"code":1,"message":"Invalid height"},"id":0,"jsonrpc":"2.0"}

Electrs/Esplora

✗ echo '{"jsonrpc": "2.0", "method": "server.version", "id": 0}' | netcat 35.225.54.191 50001
{"id":0,"jsonrpc":"2.0","result":["electrs-esplora 0.4.1","1.4"]}

✗ echo '{"jsonrpc": "2.0", "method": "blockchain.block.header", "params": [4294967295], "id": 0}' | netcat 35.225.54.191 50001
{"error":"missing header","id":0,"jsonrpc":"2.0"}

The client handles correctly only the response returned by the Electrs/Esplora server, as only this response format can be unmarshaled to the response struct that assumes a string as an error:

See https://electrumx.readthedocs.io/en/latest/protocol-changes.html#version-1-5 for details.

Hi,

Would it be possible to enable batching of calls, I am currently looking at electrs (rust implementation of electrumx) which it seems does support batching now (and previously did not).

And I believe that the original electrumx also supports batching.

This would be really handy instead of iteration of a collection and calling an rpc - X amount of times.

Thanks in advance

Implement masternode function to support protocol v1.4.

• masternode.announce.broadcast()
• masternode.list()
• protx.diff()
• protx.info()

When working on testnet and mainnet integration tests in keep-network/keep-core#3599 we stumbled upon random panics when running tests:

=== FAIL: pkg/bitcoin/electrum TestGetLatestBlockHeight_Integration (unknown)
panic: assignment to entry in nil map

goroutine 511 [running]:
github.com/checksum0/go-electrum/electrum.(*Client).listenPush(0xc00036cc40, {0x120e9eb, 0x1c})
	/go/pkg/mod/github.com/keep-network/[email protected]/electrum/network.go:264 +0x74
github.com/checksum0/go-electrum/electrum.(*Client).SubscribeHeaders.func1()
	/go/pkg/mod/github.com/keep-network/[email protected]/electrum/subscribe.go:40 +0x36
created by github.com/checksum0/go-electrum/electrum.(*Client).SubscribeHeaders
	/go/pkg/mod/github.com/keep-network/[email protected]/electrum/subscribe.go:39 +0xfd

=== FAIL: pkg/bitcoin/electrum TestGetLatestBlockHeight_Integration/electrs-esplora_tcp_get (unknown)

=== FAIL: pkg/bitcoin/electrum TestGetLatestBlockHeight_Integration/electrumx_wss_get (unknown)
panic: assignment to entry in nil map

goroutine 511 [running]:
github.com/checksum0/go-electrum/electrum.(*Client).listenPush(0xc00036cc40, {0x[120](https://github.com/keep-network/keep-core/actions/runs/5215398427/jobs/9424824985?pr=3599#step:5:121)e9eb, 0x1c})
	/go/pkg/mod/github.com/keep-network/[email protected]/electrum/network.go:264 +0x74
github.com/checksum0/go-electrum/electrum.(*Client).SubscribeHeaders.func1()
	/go/pkg/mod/github.com/keep-network/[email protected]/electrum/subscribe.go:40 +0x36
created by github.com/checksum0/go-electrum/electrum.(*Client).SubscribeHeaders
	/go/pkg/mod/github.com/keep-network/[email protected]/electrum/subscribe.go:39 +0xfd

I think the problem lies in how the library handles closing the connection.

SubscribeHeaders creates a goroutine that writes to s.pushHandlers map in the listenPush function. If Shutdown() is called at the same time, unfortunate ordering of calls can lead to clearing s.pushHandlers = nil and then attempting to s.pushHandlers[method] = append(s.pushHandlers[method], c).

Separately from this issue, I think the goroutines created in SubscribeHeaders are leaking given there is no clear exit signal for them - the channel returned by listenPush is never closed and they are stuck on reading.