0xB10C
commented
5 years ago I like the idea. The response includes the data we need. Yet I don't think it's needed for a MVP/alpha. Can be added later.
A few thoughts to keep in mind for the implementation, since the getrawmempool RPC can take 30s+ on fuller mempools:
- Use Bitcoin Core v0.19.0+, which will include a patch that speeds up the JSON encoding in Core significantly.
- Consider using the REST interface of Core which again is significantly faster than RPC the interface and returns the same values. Additionally doesn't require RPC authentication token handling in bademeisterd, which could make usage and code more complex. (Might be worth checking if we can go fully without RPC and only use REST for the daemon and the API as well, but that's for another issue).
- Start the query for the current mempool and zmq message handling at the same time in separate goroutines.
When bademeister starts cold with a running bitcoind instance, it only learns about new txs coming in and doesn't see the existing mempool.
We can use the
getrawmempoolrpc withverbose: trueto get the initial state:https://bitcoin.org/en/developer-reference#getrawmempool