Closed ffranr closed 10 months ago
As far as I can tell, the change necessary to the AnchorVirtualPsbts
RPC endpoint is minimal. We basically just need to loop over all vPacket
inputs and add them to the tappsbt.InputCommitments
map in our call to r.cfg.ChainPorter.RequestShipment
, just like we're doing now for vPacket.Inputs[0]
.
I guess we also need to add sanity checks?
Does that sound correct to you @guggero ?
Relevant code section from the RPC endpoint:
inputAsset := vPacket.Inputs[0].Asset()
prevID := vPacket.Inputs[0].PrevID
inputCommitment, err := r.cfg.AssetStore.FetchCommitment(
ctx, inputAsset.ID(), prevID.OutPoint, inputAsset.GroupKey,
&inputAsset.ScriptKey, true,
)
if err != nil {
return nil, fmt.Errorf("error fetching input commitment: %w",
err)
}
rpcsLog.Debugf("Selected commitment for anchor point %v, requesting "+
"delivery", inputCommitment.AnchorPoint)
resp, err := r.cfg.ChainPorter.RequestShipment(
tapfreighter.NewPreSignedParcel(
vPacket, tappsbt.InputCommitments{
0: inputCommitment.Commitment,
},
),
)
(I'll take a look elsewhere in the code to see where else we need to make changes.)
From looking at the code, I think we should limit this issue to just supporting multiple inputs of the same asset ID. The following function acts on a single funding descriptor, for example: AssetWallet.FundPacket(...)
.
We also need to address this TODO in this issue: https://github.com/lightninglabs/taproot-assets/blob/0a63d81e7c0b3886161d2df6b07f6f54c1752dfd/tapscript/send.go#L514-L514
This PR should cover full value multi-input PSBT spend for homogenous input asset IDs: https://github.com/lightninglabs/taproot-assets/pull/741
EDIT: moved work from 741 to PR: https://github.com/lightninglabs/taproot-assets/pull/743
I've narrowed down the scope of this issue to homogeneous input asset IDs. I'll create another issue to capture other sorts of inputs on Monday. cc @dstadulis
Does that sound correct to you @guggero ?
Yes, that sounds correct. But as you've found out in the meantime there are probably other TODOs in there that need to be addressed. I'll take a look at the PR today.
Currently, this RPC endpoint formulates a shipment request using a single input from the virtual package only. The endpoint should be extended to support multi input virtual packets.