[bug]: Not all transfer proofs generated

[youngzhenhao]

Background

Only a portion of proofs is generated locally after SendAsset to 12 addresses, this is also true after 6 blocks have been generated in bitcoin mainnet.

Bitcoin of asset's this UTXO has actually been spent, but asset's this UTXO is still existing, can not be used, and no output index 0's asset UTXO available.

Your environment

litd: 0.13.3-alpha
lnd: v0.18.2-beta
tapd: 0.4.1-alpha
network: mainnet
system: Linux 4.19.157
lnd use neutrino

• any other relevant environment details

Steps to reproduce

1. Create a new instance of the lightning-terminal daemon and run it.
2. Unlock lnd and wait it synced to chain.
3. Call SendAsset of taprpc to send assets to 12 addresses are from different tapd.
4. Wait several new block generates.
5. Check proof files of transfer in directory.

Expected behavior

All proof file with output index 0 to 12 are generated in the {tapddir}\data\mainnet\proofs\{asset_id}\.

Actual behavior

Only proof file with output index 0 was generated in the {tapddir}\data\mainnet\proofs\{asset_id}.

Logs here

Proof file with index 0 here

The same thing happened two weeks ago, in one of the previous transfers, until now, only proof files with output indexes 0,1,2 were generated after SendAsset to other 12 addresses.

Expectation

1. What would cause only a portion of proof files be generated?
2. How to make asset's this invalid UTXO usable?
3. How to use the existing data to regenerate all the proof files?

[guggero]

I see this:

2024-10-31 09:12:07.415 [ERR] FRTR: Error evaluating state (SendStateStoreProofs): error verifying proof: error verifying proofs: invalid exclusion proof: invalid taproot proof: derived_keys=([]asset.SerializedKey) (len=2 cap=2) {
 (asset.SerializedKey) (len=33 cap=33) {
  00000000  02 0a f8 5f f8 96 d8 2a  0e ea 2f 33 1a 57 ed cc  |..._...*../3.W..|
  00000010  2f 76 08 36 01 1f 65 81  70 71 01 44 ef a6 67 ba  |/v.6..e.pq.D..g.|
  00000020  9a                                                |.|
 },
 (asset.SerializedKey) (len=33 cap=33) {
  00000000  02 3f 8a 95 bc 22 76 e5  39 ff a8 bb 38 f4 9d 47  |.?..."v.9...8..G|
  00000010  1d 02 c2 c1 ad 19 0b 55  6e fc 3e 6f ae e3 e8 e9  |.......Un.>o....|
  00000020  8e                                                |.|
 }
}
, expected_key=1082ad76c8eab2bcd3c515d87b3d3d2fc83eb8395664a91d1cb852d52182d267

So some proof wasn't created correctly... I'll investigate.

[guggero]

@youngzhenhao I did take a closer look and it seems like the one proof (for index 0) that was generated is valid. So something must be up with index 1 and later. But those proofs aren't on the disk yet, only in the SQLite database. Do you think it would be possible for you to send me a copy of your database? You can either reach me by e-mail (see my GitHub profile), keybase or our Slack server.

If that's problematic, I can also send you a query you can run to just extract some of the invalid proofs from the DB. Let me know what works best for you.

[youngzhenhao]

@guggero Sure, db file here