dstadulis
commented
1 year ago Goal will be to deliver this by mainnet-beta or at latest beta+1
@jharveyb commented:
theoretically we could also replace the first TX with one that batches the two requests together But we're far from adding that in
Background
In #406 @guggero suggested that: error messaging be added to convey the cause if
tapd's proof generation is blocked.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
tapdproof-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:
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.