Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug]: AddrEventStatus fails to populate ADDR_EVENT_STATUS_TRANSACTION_DETECTED during receive scenario #905

Open
vanditshah99 opened this issue May 17, 2024 · 6 comments
Labels
bug Something isn't working needs triage

Comments

@vanditshah99
Copy link

vanditshah99 commented May 17, 2024

When querying addrsReceives for a tapdAddrs, we are receiving empty address events for address, This might happen when sender takes time to send the proof of holding assets, but in this case the sender and receiver are on same taproot node.

The issue was said to be fixed in 0.3.3 but still we are facing this issue with our addresses.

For example we have an address

taptb1qqqsqqspqqzzqxqnazzfqmmctgyl5sfcwayx6hamcv0zn965xt6nwvmhw5wkskp3qcssyrclfz62jch8nznpeyu0jhvd4y39wpsg8pmksas6f23qn8g620a3pqssx37effe5q36azqtcmp29cnqdp9qpv6k6qxgmtcn30hlk9x4y083dpgqszrpkw4hxjan9wfek2unsvvaz7tm5v4ehgmn9wsh82mnfwejhyum99ekxjemgw3hxjmn89enxjmnpde3k2w33xqcrywg8edygu

Send API that we hit

tapcli -n testnet assets send --addr taptb1qqqsqqspqqzzqxqnazzfqmmctgyl5sfcwayx6hamcv0zn965xt6nwvmhw5wkskp3qcssyrclfz62jch8nznpeyu0jhvd4y39wpsg8pmksas6f23qn8g620a3pqssx37effe5q36azqtcmp29cnqdp9qpv6k6qxgmtcn30hlk9x4y083dpgqszrpkw4hxjan9wfek2unsvvaz7tm5v4ehgmn9wsh82mnfwejhyum99ekxjemgw3hxjmn89enxjmnpde3k2w33xqcrywg8edygu

{
    "transfer": {
        "transfer_timestamp": "1715943359",
        "anchor_tx_hash": "8994ea933100dfd0074596e9c4d01bf924c855c269ca58b6d4cbcc0313c390c7",
        "anchor_tx_height_hint": 2815999,
        "anchor_tx_chain_fees": "11312",
        "inputs": [
            {
                "anchor_point": "c0b6979ca0f43154d31f7e04cd02ab8363ec5cd149429e71dad9b5b46bdf6e3d:0",
                "asset_id": "1813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d685831",
                "script_key": "02aa471ac90f91ed0e0ad331a19651926e0d0cd834def1d660302cd038ed687efb",
                "amount": "40000"
            }
        ],
        "outputs": [
            {
                "anchor": {
                    "outpoint": "c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489:0",
                    "value": "1000",
                    "internal_key": "02ba3ae77a3258f5569918896cadfa2f9abffc664571e18b4ddbeed70242d3abc3",
                    "taproot_asset_root": "c234b0e9b89d300489ce6f5b3ffa44c21dc8088a052f082a909889424db370ac",
                    "merkle_root": "c234b0e9b89d300489ce6f5b3ffa44c21dc8088a052f082a909889424db370ac",
                    "tapscript_sibling": "",
                    "num_passive_assets": 0
                },
                "script_key": "02d24c5f8a35dfda1a363dfdf3b90ed0a0dae674655727bb73ba2e39d221845827",
                "script_key_is_local": true,
                "amount": "39999",
                "new_proof_blob": "5441505000040000000002243d6edf6bb4b5d9da719e4249d15cec6383ab02cd047e1fd35431f4a09c97b6c0000000000450000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000096e88000000000000000006fd016302000000000102c85bfe5cb2befdcfa6441f969ee06883ac907bed82b6ad3bd502acadbbe152490000000000ffffffff3d6edf6bb4b5d9da719e4249d15cec6383ab02cd047e1fd35431f4a09c97b6c000000000000000000003e803000000000000225120eddf834c20d52afc9bef2cc8a01404ea5af75da0c0441e100106ee9e43691e87e8030000000000002251203e770ce31f86493aa512c2eade81f98da652501f0f28085757cb4a62574f8f24372a2400000000002251204db29a527d39f965abfc92faa6895de13ed7ea6cbc110028c6dc5a84b6c464d501402f2ba8705c12a4bca2869faa8c05c0d425bcbdb349d09b4a2004b095cb39d1656a7d313329a04343187509b0b96e8c5f77a0d7c8653bbd71d160effd408d64f101407010da8f2a3f53609abfaee080499b4c1ed8c8b62bbe34af7d947ac03a69f9284240d6252fdcb8e8ab0f3fa7dd8ea2086f7217c4bc9fabb60a22caf9f2327632000000000801000afd015b000100024e8e3714a1a50369f375bb184027eb776171806acc29c7419ef83e8bf8a4552b35000000020455534454000000000000000000000000000000000000000000000000000000000000000000000000000401000603fd9c3f0bad01ab01653d6edf6bb4b5d9da719e4249d15cec6383ab02cd047e1fd35431f4a09c97b6c0000000001813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d68583102aa471ac90f91ed0e0ad331a19651926e0d0cd834def1d660302cd038ed687efb034201407177fc4738599cb4d274013d599c4ca3b78a36f5a97f9b8603bc52d2bc66e69886141ef5932da76cb9eefd405b415c2dca48ab0eede6e73a1075de6feb1652990d287ff6f4dcc9e504f914d62be1b67548c0f56b08fd208c0ace9fc584972b1d63d70000000000009c400e020000102102d24c5f8a35dfda1a363dfdf3b90ed0a0dae674655727bb73ba2e39d2218458270c9f000400000000022102ba3ae77a3258f5569918896cadfa2f9abffc664571e18b4ddbeed70242d3abc30374014900010002201813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d68583104220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0df802c700040000000102210347d94a7340475d10178d8545c4c0d0940166ada0191b5e2717dff629aa479e2d039c017100010002201813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d685831044a0001e03d4bea06496ec839eceb48e95140d1c84ae499b1f30f961a948eadc19339530000000000000001fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff2e000400000002022102a79eca84802ae7bb5e9b21f50ca06356f4c9a9e4b5f438c2ac9466513d5d58e00503040101160400000000",
                "split_commit_root_hash": "7ff6f4dcc9e504f914d62be1b67548c0f56b08fd208c0ace9fc584972b1d63d7",
                "output_type": "OUTPUT_TYPE_SPLIT_ROOT",
                "asset_version": "ASSET_VERSION_V0"
            },
            {
                "anchor": {
                    "outpoint": "c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489:1",
                    "value": "1000",
                    "internal_key": "0347d94a7340475d10178d8545c4c0d0940166ada0191b5e2717dff629aa479e2d",
                    "taproot_asset_root": "b59aea1f7eae40bd9978c6d89795bb9cf8a895a01db50248b3a7a36dcd334e45",
                    "merkle_root": "b59aea1f7eae40bd9978c6d89795bb9cf8a895a01db50248b3a7a36dcd334e45",
                    "tapscript_sibling": "",
                    "num_passive_assets": 0
                },
                "script_key": "020f1f48b4a962e798a61c938f95d8da922570608387768761a4aa2099d1a53fb1",
                "script_key_is_local": true,
                "amount": "1",
                "new_proof_blob": "5441505000040000000002243d6edf6bb4b5d9da719e4249d15cec6383ab02cd047e1fd35431f4a09c97b6c0000000000450000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000096e88000000000000000006fd016302000000000102c85bfe5cb2befdcfa6441f969ee06883ac907bed82b6ad3bd502acadbbe152490000000000ffffffff3d6edf6bb4b5d9da719e4249d15cec6383ab02cd047e1fd35431f4a09c97b6c000000000000000000003e803000000000000225120eddf834c20d52afc9bef2cc8a01404ea5af75da0c0441e100106ee9e43691e87e8030000000000002251203e770ce31f86493aa512c2eade81f98da652501f0f28085757cb4a62574f8f24372a2400000000002251204db29a527d39f965abfc92faa6895de13ed7ea6cbc110028c6dc5a84b6c464d501402f2ba8705c12a4bca2869faa8c05c0d425bcbdb349d09b4a2004b095cb39d1656a7d313329a04343187509b0b96e8c5f77a0d7c8653bbd71d160effd408d64f101407010da8f2a3f53609abfaee080499b4c1ed8c8b62bbe34af7d947ac03a69f9284240d6252fdcb8e8ab0f3fa7dd8ea2086f7217c4bc9fabb60a22caf9f2327632000000000801000afd029c000100024e8e3714a1a50369f375bb184027eb776171806acc29c7419ef83e8bf8a4552b35000000020455534454000000000000000000000000000000000000000000000000000000000000000000000000000401000601010bfd021801fd02140165000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005fd01a94a000161571c24c8191f09c959fd59e3971f527608e9cbf1c1ea4e39c04e698ee6fa490000000000009c3ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7fd015b000100024e8e3714a1a50369f375bb184027eb776171806acc29c7419ef83e8bf8a4552b35000000020455534454000000000000000000000000000000000000000000000000000000000000000000000000000401000603fd9c3f0bad01ab01653d6edf6bb4b5d9da719e4249d15cec6383ab02cd047e1fd35431f4a09c97b6c0000000001813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d68583102aa471ac90f91ed0e0ad331a19651926e0d0cd834def1d660302cd038ed687efb034201407177fc4738599cb4d274013d599c4ca3b78a36f5a97f9b8603bc52d2bc66e69886141ef5932da76cb9eefd405b415c2dca48ab0eede6e73a1075de6feb1652990d287ff6f4dcc9e504f914d62be1b67548c0f56b08fd208c0ace9fc584972b1d63d70000000000009c400e020000102102d24c5f8a35dfda1a363dfdf3b90ed0a0dae674655727bb73ba2e39d2218458270e0200001021020f1f48b4a962e798a61c938f95d8da922570608387768761a4aa2099d1a53fb10c9f00040000000102210347d94a7340475d10178d8545c4c0d0940166ada0191b5e2717dff629aa479e2d0374014900010002201813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d68583104220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0df802c7000400000000022102ba3ae77a3258f5569918896cadfa2f9abffc664571e18b4ddbeed70242d3abc3039c017100010002201813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d685831044a0001023cda11a6b0bc79d98d4bb18c7fc3c261e1d325f02a1607acf05991fb1fc8dd0000000000009c3ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff2e000400000002022102a79eca84802ae7bb5e9b21f50ca06356f4c9a9e4b5f438c2ac9466513d5d58e005030401010f9f000400000000022102ba3ae77a3258f5569918896cadfa2f9abffc664571e18b4ddbeed70242d3abc30374014900010002201813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d68583104220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff160400000000",
                "split_commit_root_hash": "",
                "output_type": "OUTPUT_TYPE_SIMPLE",
                "asset_version": "ASSET_VERSION_V0"
            }
        ]
    }
}

Here are the logs while the send occurs

2024-05-17 10:55:57.403 [INF] FRTR: Received to send request to 1 addrs: [TapAddr{id=1813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d685831, amount=1, script_key=020f1f48b4a962e798a61c938f95d8da922570608387768761a4aa2099d1a53fb1}]
2024-05-17 10:55:57.403 [INF] FRTR: ChainPorter executing state: SendStateVirtualCommitmentSelect
2024-05-17 10:55:58.631 [INF] FRTR: Identified 39 eligible asset inputs for send of 1 to 1813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d685831
2024-05-17 10:55:58.665 [INF] FRTR: Selected 1 asset inputs for send of 1 to 1813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d685831
2024-05-17 10:55:58.851 [DBG] TAPD: Deriving new key for fam_family=212
2024-05-17 10:55:58.880 [DBG] TAPD: Deriving new key for fam_family=212
2024-05-17 10:55:58.920 [INF] FRTR: ChainPorter executing state: SendStateVirtualSign
2024-05-17 10:55:58.920 [INF] FRTR: Generating Taproot Asset witnesses for send to: 020f1f48b4a962e798a61c938f95d8da922570608387768761a4aa2099d1a53fb1
2024-05-17 10:55:58.929 [INF] FRTR: ChainPorter executing state: SendStateAnchorSign
2024-05-17 10:55:58.946 [INF] FRTR: sending with fee rate: 44448 sat/kb
2024-05-17 10:55:58.947 [INF] FRTR: Constructing new Taproot Asset commitments for send to: 020f1f48b4a962e798a61c938f95d8da922570608387768761a4aa2099d1a53fb1
2024-05-17 10:55:59.039 [INF] FRTR: Received funded PSBT packet
2024-05-17 10:55:59.040 [INF] FRTR: Adjusting send pkt by delta of 2600 from 8712 sats to 11312 sats
2024-05-17 10:55:59.040 [DBG] FRTR: Signing PSBT
2024-05-17 10:55:59.045 [DBG] FRTR: Got signed PSBT
2024-05-17 10:55:59.046 [INF] FRTR: PSBT absolute fee: 11312 sats
2024-05-17 10:55:59.046 [INF] FRTR: ChainPorter executing state: SendStateLogCommit
2024-05-17 10:55:59.090 [INF] FRTR: Committing pending parcel to disk
2024-05-17 10:55:59.155 [INF] FRTR: ChainPorter executing state: SendStateBroadcast
2024-05-17 10:55:59.193 [INF] FRTR: Broadcasting new transfer tx, txid=c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489
2024-05-17 10:55:59.272 [INF] FRTR: Outbound parcel with txid c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489 now pending (num_inputs=1, num_outputs=2), delivering notification
2024-05-17 10:55:59.272 [INF] FRTR: ChainPorter executing state: SendStateWaitTxConf
2024-05-17 10:55:59.272 [INF] FRTR: Waiting for confirmation of transfer_txid=c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489

It gets stuck at waiting for confirmation, but never receives one

As of now we no universe synced except the default one of testnet i.e

{
    "servers": [
        {
            "host": "testnet.universe.lightning.finance:10029",
            "id": 1
        }
    ]
}

This is the response of get info call

{
    "version": "0.3.3-alpha commit=v0.3.3",
    "lnd_version": "0.17.0-beta",
    "network": "testnet3",
    "lnd_identity_pubkey": "02ac55f686b46ae6fc60924fe2115b1a7b64d4d71c0de2265a1ef0136d680b1c61",
    "node_alias": "SpeedDev2",
    "block_height": 2815999,
    "block_hash": "000000000000000ad8e51b5de58522386504453a9e9ec742ec8f5da872568f1e",
    "sync_to_chain": true
}

We are trying to build a multi-tenancy layer on our tapd node, so sender and receiver would ideally be on our same tapd instance.

Edit with a new example as TRACE logs

Tapd Address : taptb1qqqsqqspqqzzqxqnazzfqmmctgyl5sfcwayx6hamcv0zn965xt6nwvmhw5wkskp3qcss9pnwg5vmwzczxvvjju5p5ksj9c7dupqpwm2jyszs06wxcwtjd9v6pqssxmkn5uqhs22ktsy9yuyl4npgme5cqzqcnzty29gxwug0zmn4u60spgplms6spsm82mnfwejhyum9wfcxxw309a6x2um5dejhgtn4de5hvetjwdjjumrfva58gmnfdenjuenfdeskucm98gcnqvpj8y37gkl4

Logs from the console
New Text Document (2).txt

[@dstadulis Edit: Added code markdown for readability]

@vanditshah99 vanditshah99 added bug Something isn't working needs triage labels May 17, 2024
@Roasbeef
Copy link
Member

Roasbeef commented May 17, 2024

Looks like your transaction has confirmed since the issue was created: https://mempool.space/testnet/tx/c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489

Do you see the receive flow advance now?

@dstadulis
Copy link
Collaborator

@vinditshah99 what's the behavior that's expected?

Tracking the actions, expected behavior on tapd side would be: tapd reports that an tap address holds assets once the sending transaction has confirmed on chain. Issue was created about 5 hours before confirmation

@vanditshah99
Copy link
Author

@dstadulis @Roasbeef The issue here is whenever the transaction is done, the inital state ADDR_EVENT_STATUS_TRANSACTION_DETECTED and ADDR_EVENT_STATUS_TRANSACTION_CONFIRMED are not obtained from the node,
https://lightning.engineering/api-docs/api/taproot-assets/taproot-assets/addr-receives/index.html

https://mempool.space/testnet/tx/c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489
This has populated AddrEvents, but I don't know what took so much time to populate the event,

tapcli -n testnet addrs receives --addr taptb1qqqsqqspqqzzqxqnazzfqmmctgyl5sfcwayx6hamcv0zn965xt6nwvmhw5wkskp3qcssyrclfz62jch8nznpeyu0jhvd4y39wpsg8pmksas6f23qn8g620a3pqssx37effe5q36azqtcmp29cnqdp9qpv6k6qxgmtcn30hlk9x4y083dpgqszrpkw4hxjan9wfek2unsvvaz7tm5v4ehgmn9wsh82mnfwejhyum99ekxjemgw3hxjmn89enxjmnpde3k2w33xqcrywg8edygu
{
    "events": [
        {
            "creation_time_unix_seconds": "1715944491",
            "addr": {
                "encoded": "taptb1qqqsqqspqqzzqxqnazzfqmmctgyl5sfcwayx6hamcv0zn965xt6nwvmhw5wkskp3qcssyrclfz62jch8nznpeyu0jhvd4y39wpsg8pmksas6f23qn8g620a3pqssx37effe5q36azqtcmp29cnqdp9qpv6k6qxgmtcn30hlk9x4y083dpgqszrpkw4hxjan9wfek2unsvvaz7tm5v4ehgmn9wsh82mnfwejhyum99ekxjemgw3hxjmn89enxjmnpde3k2w33xqcrywg8edygu",
                "asset_id": "1813e884906f785a09fa413877486d5fbbc31e29975432f5373377751d685831",
                "asset_type": "NORMAL",
                "amount": "1",
                "group_key": "",
                "script_key": "020f1f48b4a962e798a61c938f95d8da922570608387768761a4aa2099d1a53fb1",
                "internal_key": "0347d94a7340475d10178d8545c4c0d0940166ada0191b5e2717dff629aa479e2d",
                "tapscript_sibling": "",
                "taproot_output_key": "3e770ce31f86493aa512c2eade81f98da652501f0f28085757cb4a62574f8f24",
                "proof_courier_addr": "universerpc://testnet.universe.lightning.finance:10029",
                "asset_version": "ASSET_VERSION_V0"
            },
            "status": "ADDR_EVENT_STATUS_COMPLETED",
            "outpoint": "c790c31303cccbd4b658ca69c255c824f91bd0c4e9964507d0df003193ea9489:1",
            "utxo_amt_sat": "1000",
            "taproot_sibling": "",
            "confirmation_height": 2816000,
            "has_proof": true
        }
    ]
}

Also, for the following address, which is stated with trace log in above comment.

taptb1qqqsqqspqqzzqxqnazzfqmmctgyl5sfcwayx6hamcv0zn965xt6nwvmhw5wkskp3qcss9pnwg5vmwzczxvvjju5p5ksj9c7dupqpwm2jyszs06wxcwtjd9v6pqssxmkn5uqhs22ktsy9yuyl4npgme5cqzqcnzty29gxwug0zmn4u60spgplms6spsm82mnfwejhyum9wfcxxw309a6x2um5dejhgtn4de5hvetjwdjjumrfva58gmnfdenjuenfdeskucm98gcnqvpj8y37gkl4

When we query addrs receive we get following result :

tapcli -n testnet addrs receives --addr taptb1qqqsqqspqqzzqxqnazzfqmmctgyl5sfcwayx6hamcv0zn965xt6nwvmhw5wkskp3qcss9pnwg5vmwzczxvvjju5p5ksj9c7dupqpwm2jyszs06wxcwtjd9v6pqssxmkn5uqhs22ktsy9yuyl4npgme5cqzqcnzty29gxwug0zmn4u60spgplms6spsm82mnfwejhyum9wfcxxw309a6x2um5dejhgtn4de5hvetjwdjjumrfva58gmnfdenjuenfdeskucm98gcnqvpj8y37gkl4
{
    "events": []
}

On mempool we can notice the transaction is confirmed but it AddrReceive Event is not populated.

https://mempool.space/testnet/tx/fd62a4cafc765399e8003452ca3b774ad1761bf6d4da03dbed1121d317d32a92

@vanditshah99
Copy link
Author

Also, one thing to mention here is another observation that we did on our end to check LND's Api of listonchainTxns,

We separated two Nodes, say Node1 and Node2 for Tapd and also two different LND runs for both of it.
Node 2 syncs the universe of Node 1,

Now node 2 generates an tapd address to receives an asset, Node 1 pays it, the above behaviour is replicated that we don't receive an AddrsReceiveEvent for Node 2's address

But when we hit lncli command for Node 2 (Receiver) by grepping transaction hash, we don't get any result for it

lncli -n testnet listchaintxns --start_height 2816528
{
    "transactions":  []
}

But for Node 1 (Sender), we get the result for this,
lncli -n testnet listchaintxns --start_height 2816528

{
    "transactions":  [
        {
            "tx_hash":  "c016430a433649d95c19f7a352d8c788fa66bc6a63b18961bd70e0fa5d499e55",
            "amount":  "-15366",
            "num_confirmations":  0,
            "block_hash":  "",
            "block_height":  0,
            "time_stamp":  "1716201536",
            "total_fees":  "14366",
            "dest_addresses":  [
                "tb1pksw4ad7gjck7f0ysf6rp3t3wvw74w7kjxgdm6psetdhe3ystyc5s99hxqz",
                "tb1ph2l4mdmmcfz09yk72ugfw5rdmyn7362y49z7zrjz72ftra8qkhssre4hy3",
                "tb1p5q93e6xu87ea6a6tueu8wqj23magmqxruhd3yv823vq5m44dxhqq9xdxnw"
            ],
            "output_details":  [
                {
                    "output_type":  "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
                    "address":  "tb1pksw4ad7gjck7f0ysf6rp3t3wvw74w7kjxgdm6psetdhe3ystyc5s99hxqz",
                    "pk_script":  "5120b41d5eb7c8962de4bc904e8618ae2e63bd577ad2321bbd06195b6f98920b2629",
                    "output_index":  "0",
                    "amount":  "1000",
                    "is_our_address":  true
                },
                {
                    "output_type":  "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
                    "address":  "tb1ph2l4mdmmcfz09yk72ugfw5rdmyn7362y49z7zrjz72ftra8qkhssre4hy3",
                    "pk_script":  "5120babf5db77bc244f292de571097506dd927e8e944a945e10e42f292b1f4e0b5e1",
                    "output_index":  "1",
                    "amount":  "1000",
                    "is_our_address":  false
                },
                {
                    "output_type":  "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
                    "address":  "tb1p5q93e6xu87ea6a6tueu8wqj23magmqxruhd3yv823vq5m44dxhqq9xdxnw",
                    "pk_script":  "5120a00b1ce8dc3fb3dd774be67877024a8efa8d80c3e5db1230ea8b014dd6ad35c0",
                    "output_index":  "2",
                    "amount":  "1991800",
                    "is_our_address":  true
                }
            ],
            "raw_tx_hex":  "020000000001032c85d6e61cac7e96e9988169ad39ecb48190d08ad2875a4381b1182c7be733c40000000000ffffffff1f8bc2303053a0109ec963f3c49ed5cea65e9d3032b3f5809f24542d9dbd7ffd0000000000000000004832a7bd6f467fa3abf61a5b7fbd602a7fcb109243c6880b079a5c7e5417d6a900000000000000000003e803000000000000225120b41d5eb7c8962de4bc904e8618ae2e63bd577ad2321bbd06195b6f98920b2629e803000000000000225120babf5db77bc244f292de571097506dd927e8e944a945e10e42f292b1f4e0b5e178641e0000000000225120a00b1ce8dc3fb3dd774be67877024a8efa8d80c3e5db1230ea8b014dd6ad35c00140967ef7426ecec7824665cff5fd0c6d4ad90b22d129a45997872f83b014e546c4f2a81c6303a7e7508b6c1f191925ba95e89bf9114486256eda89b67f6afecd7101403ed52a942cc644477a699d81b079259d36037279ff0309a29ed564cc5f32de17b6bc025d3e983077f9249e04249a080e44160d8366cfcd8bd25ccb2df975b79c0140694f04f81eb7f95e29a4e4dc2d670b93a6f570b7c89f36aab8be8045f11d05797cd6cfce3f358cd08ff00ee0c196ade4889860bb9dced7f848d7f233d37dc58500000000",
            "label":  "tapd-asset-minting",
            "previous_outpoints":  [
                {
                    "outpoint":  "c433e77b2c18b181435a87d28ad09081b4ec39ad698198e9967eac1ce6d6852c:0",
                    "is_our_output":  true
                },
                {
                    "outpoint":  "fd7fbd9d2d54249f80f5b332309d5ea6ced59ec4f363c99e10a0533030c28b1f:0",
                    "is_our_output":  true
                },
                {
                    "outpoint":  "a9d617547e5c9a070b88c6439210cb7f2a60bd7f5b1af6aba37f466fbda73248:0",
                    "is_our_output":  true
                }
            ]
        }
    ]
}

So if LND is not able to get the updates(probably from bitcoind), tapd won't be able to get the update
The transaction hash which I am referring to is

https://mempool.space/testnet/tx/c016430a433649d95c19f7a352d8c788fa66bc6a63b18961bd70e0fa5d499e55

@dstadulis dstadulis changed the title [bug]: Issue with proof import where sender and receiver belong to the same node [bug]: AddrEventStatus fails to populate ADDR_EVENT_STATUS_TRANSACTION_DETECTED during receive scenario May 20, 2024
@dstadulis
Copy link
Collaborator

The additional information is helpful, @vanditshah99 ! Thank you.

Would you add the tapd versions which observed this dysfunction?

tapcli getinfo                       # version of `tapd`, `lnd`, and network
uname -mrsv                          # operating system 
bitcoind --version || btcd --version # version of `btcd`, `bitcoind`, or other backend

@vanditshah99
Copy link
Author

@dstadulis @Roasbeef Hope this helps!

Tapd Getinfo Call

{
    "version":  "0.3.3-alpha.rc3 commit=v0.3.3-alpha.rc3",
    "lnd_version":  "0.17.0-beta",
    "network":  "testnet3",
    "lnd_identity_pubkey":  "0306b095fc3142ae3d79e2e43df1df72729017a96a7c7a10b3d89ebfdf7d5508ab",
    "node_alias":  "SpeedDev3",
    "block_height":  2816687,
    "block_hash":  "00000000ec3b5d8fcca6ae8d3d5e0e30c079e7997a55a4ed9a62f254f215ed14",
    "sync_to_chain":  true
}

Tapd Server Uname

Linux 6.5.0-1018-aws #18~22.04.1-Ubuntu SMP Fri Apr  5 17:44:33 UTC 2024 x86_64

Bitcoin Version

Bitcoin Core version v23.0.0

Bitcond Server Uname

Linux 5.13.0-1031-aws #35~20.04.1-Ubuntu SMP Mon Jun 13 22:30:30 UTC 2022 x86_64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs triage
Projects
None yet
Development

No branches or pull requests

3 participants