itest: spend assets after sweeping from force close

[guggero]

Depends on lightninglabs/taproot-assets#1103.

Demonstrates the issue in lightninglabs/taproot-assets#1099, and that the fix works.

[jharveyb]

Locally I observe a different (probably related?) error:

litd_custom_channels_test.go:1429: 
        	Error Trace:	/home/jhb/lightning-terminal/itest/litd_custom_channels_test.go:1429
        	            				/home/jhb/lightning-terminal/itest/test_harness.go:103
        	            				/home/jhb/lightning-terminal/itest/litd_test.go:100
        	Error:      	Received unexpected error:
        	            	rpc error: code = Unknown desc = unable to sign and commit virtual packet: unable to generate Taproot Asset witness data: invalid split commitment proof

AFAICT, the sweep TX by Dave is performing a full-value self-send, which gets broadcast, verified by Dave correctly, and imported into his node. The script key is detected as local and known.

On coin selection, the input is detected as not having a split commitment, but during signing tapd fails on generating a witness. I suspect the sweep output is being stored incorrectly s.t. the split root is set incorrectly, causing the split leaf proof for the send to be invalid.

[jharveyb]

AFAICT this is the point of failure:

https://github.com/lightninglabs/taproot-assets/blob/e893dee87e9d8f0de53b8ee9e2527add80df6491/vm/vm.go#L314

From debug sesssions it looks like the split proof verify is failing on the new split root.

[Roasbeef]

AFAICT, the sweep TX by Dave is performing a full-value self-send, which gets broadcast, verified by Dave correctly, and imported into his node. The script key is detected as local and known.

I suspect the sweep output is being stored incorrectly s.t. the split root is set incorrectly, causing the split leaf proof for the send to be invalid.

Isn't this contradictory? If it's a full value send, then there's no split commitment needed, unless the asset created is stored incorrectly, referencing a split in the witness when non is required?

[Roasbeef]

Pushed a fix for the added assertion. Also have a fix for the underlying issue as well, PR inc there.