[enhancement] Performantly handle proving-resource constraints #418
Description
Background
In #406 @guggero suggested that: error messaging be added to convey the cause if tapd's proof generation is blocked.
[tapd could report] a proper error message on the second send attempt (something along the lines of "no confirmed asset outputs available, please wait for previous sends to confirm before sending again")
In instances where tap asset senders have created/broadcast a transaction with an outpoint that contains the recipient's tap asset, there are scenarios in which proof generation will have insufficient "proving resources". In this specific instance, the wallet has no UTXOs to produce new transactions into which a tap proof/send could have taproot-asset proofs timestamped).
Proof Remapping
In a scenario where a sender wishes to add a new recipient to a tap txn (more broadly and abstractly: "remap their previously-confirmed tap proof commitments between bitcoin inputs and unconfirmed outpoints"). tapcli would need to reissue a proof with the subsequent proving actions (e.g. follow up with actions such as repeal state, rebroadcast).
Enhancing error messages to convey cause of tapd proof-generation constraint(s)
If there proving resources are constrained, during this tap asset proof "remapping" process error will be encountered which will be reported to either: CLI or the remapping function (which will inform how the new send request / remapping function should be achieved)
This is a superordinate tracking issue for two subordinate issues:
- enhance error messages detailing proving+receiving constraints
- remap new, unconfirmed tap proofs into new transaction
Remapping Implementation friction
RBF P2P rules used by Bitcoin Core might impede the propagation of broadcasting the new bitcoin transactions which include the taproot-asset proof reamppings.