taproot-assets: [bug]: Proof file not transmitted upon confirmation for asset transfer

Background

I minted a normal (--emission_enabled) asset on the SENDER node. I synced RECEIVER node to the universe, created an address and sent funds from the SENDER node. Upon confirmation, both nodes sync to the universe, but proof files do not seem to get transmitted, and the RECEIVER does not show the assets in tapcli assets list or tapcli assets balance

Your environment

    "version": "0.3.0-alpha.rc2 commit=v0.3.0-alpha.rc2-36-gb489d04",
    "lnd_version": "0.17.0-beta",
    "network": "testnet3",

any other relevant environment details

Steps to reproduce

mint normal asset with emission_enabled (tapcli assets mint --type normal --name leocoin --supply 21000 --enable_emission)
sync receiver to universe
receiver makes address (tapcli2 addrs new --asset_id f2bdc9a75c4269eefc06bfb3762bb47964614aa612800cabe16eee4ca63a3c13 --amt 21)
sender sends coins (tapcli assets send --addr taptb1qqqsqqspqqzzpu4aexn4csnfam7qd0anwc4mg7tyv992vy5qpj47zmhwfjnr50qnq5ssx424cy357lfll77gdmx3r2um33phj7d6yx76rv5w5admfknujvenqcssy5czsf4akh3y6yhsn6mp3t5rpt7tfrat9znegl9q52z52ldfnv28pqss9qaejy86wuuaf203n0c6nnvnhxeqmh0uxa6qanmnfr2twjsaeel4pgq32rpkw4hxjan9wfek2unsvvaz7tm5v4ehgmn9wsh82mnfwejhyum99ekxjemgw3hxjmn89enxjmnpde3k2w33xqcrywgedu59a

Expected behavior

Once the transaction is confirmed I expect the sender to transmit their proofs to the recipient, who then knows about the assets.

Actual behavior

No sync of proofs appear to happen.

Logs of both sender and receiver:

sender_logs.txt receiver_logs.txt

About this issue

Original URL
State: open
Created 8 months ago
Comments: 31 (18 by maintainers)

Commits related to this issue

tapgarden: re-try proof courier on restart We didn't re-try using a proof courier to receive an asset after a restart of the daemon. This commit fixes #597. — committed to lightninglabs/taproot-assets by guggero 7 months ago
tapgarden: re-try proof courier on restart We didn't re-try using a proof courier to receive an asset after a restart of the daemon. This commit fixes #597. — committed to lightninglabs/taproot-assets by guggero 7 months ago
tapgarden: re-try proof courier on restart We didn't re-try using a proof courier to receive an asset after a restart of the daemon. This commit fixes #597. — committed to lightninglabs/taproot-assets by guggero 7 months ago
tapgarden: re-try proof courier on restart We didn't re-try using a proof courier to receive an asset after a restart of the daemon. This commit fixes #597. — committed to lightninglabs/taproot-assets by guggero 7 months ago
tapgarden: re-try proof courier on restart We didn't re-try using a proof courier to receive an asset after a restart of the daemon. This commit fixes #597. — committed to lightninglabs/taproot-assets by guggero 7 months ago

Most upvoted comments

Finally got to taking a closer look. So the proof was successfully uploaded to the universe by the sender. And I figured out why the receiver isn’t trying to pull it anymore. I’ll create a fix momentarily.

guggero on Dec 11, 2023

That mean though that all invoices submitted to the done have to be generated with proofcourieraddr=hashmail://mailbox.terminal.lightning.today:443 correct ?

Yes, that’s correct. If you’re using gRPC or REST to generate the address, you can also use the proof_courier_addr field, then you don’t need to start the whole daemon that way. We should definitely also add that field to the CLI.

guggero on Oct 19, 2023

@snow884 you can run your recipient daemon with --proofcourieraddr=hashmail://mailbox.terminal.lightning.today:443 to use the old proof courier method which shouldn’t have that issue. You’ll need to generate new receive addresses though, as the courier URI is encoded in the taproot asset address.

guggero on Oct 19, 2023