feat: integrate rocksdb to persist btc payments

[gregdhill]

Signed-off-by: Gregory Hill gregorydhill@outlook.com

My reasoning is that we cannot trust that the BTC payment for a parachain request will definitely be in the mempool - if not already included in a block. We could use the listtransactions Bitcoin RPC to check what transactions our node has made but it is far easier to maintain a simple KV lookup for request ID to TxId.

TODO

• Lock transaction on fetch from store
• Migrate existing payments for backwards compatibility
• Re-register change addresses at startup

[sander2]

My reasoning is that we cannot trust that the BTC payment for a parachain request will definitely be in the mempool

I am not sure this is true, if we use the transaction creation mutex correctly.

Anyway, my main problem with this approach is atomicity - sending the transaction and writing to the database needs to be one atomic action, which it is not. If the program stops executing after submitting the transaction but before the database write, you will end up making the transaction again at startup.

[sander2]

As discussed, the way forward here is probably to store the raw transaction in the database prior to sending them out. Then at startup, you can just resend any transactions still in the database.

With this approach we do need to be careful with our transaction creation mutex. If there is a raw transaction in the database at startup, we must send them to the bitcoin chain prior to creating new transactions, since otherwise bitcoin core can try to spend the same uxto twice.