taproot-assets
taproot-assets copied to clipboard
lightninglabs
[bug]: `AddrEventStatus` fails to populate `ADDR_EVENT_STATUS_TRANSACTION_DETECTED` during receive scenario
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]
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?
@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
@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
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
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
@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