Transaction Broadcasting
bitjson opened this issue · comments
Didn't quite make it into v1: most wallet applications need a way to broadcast transactions, but Chaingraph v1 only supports queries, no mutations yet.
I think the best strategy here is probably to add a send_transaction mutation which accepts an encoded_hex and a node_id. We'll probably want to set it up as a Hasura action which is handled by the agent. The agent then attempts to send the transaction to the requested node (which would rebroadcast the transaction if valid).
Slightly more ambitious: since the node can't send us any error messages over the P2P protocol (if the agent wasn't already whitelisted with all trusted nodes, sending invalid transactions would just get the agent banned) – and we don't want to start dealing with RPC interfaces just for these error messages – we can validate the transaction using Libauth (provides better VM error messages than most node implementations anyways).
To evaluate the bytecode for each input, the agent would need the value_satoshis and locking_bytecode for each spent UTXO. (We shouldn't bother validating whether or not the UTXOs are already spent according to a particular node – we can assume the sending wallet is able to handle its own attempted double-spend activity.)
If Hasura implements this feature, we'd be able to parse the transaction and fetch that data before sending the request to the agent (avoiding a round-trip). Though actually, we don't have transaction parsing implemented in Postgres yet, and even if we did, I'm not sure if it's worth wasting DB CPU on that. So we should probably just have the agent handle everything: parse the transaction, request the data from hasura, validate the transaction, then respond to the action. The simplicity (consider handling transaction parsing errors in plpgsql) is worth having transaction sending be a few milliseconds slower. (It's all still happening in the same Kubernetes cluster, so latency is presumably very low.)
We should clearly document that Chaingraph always attempts to send the transaction via the requested node, even if the transaction produces an error from Libauth. (An incompatibility between Libauth and the requested node wouldn't prevent the transaction from being broadcasted if the selected node believes it to be valid.) If present, the Libauth-generated errors are only provided as a developer convenience.
send_transaction is now available as of 3ebddce