-
Notifications
You must be signed in to change notification settings - Fork 106
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
Comments
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,
{
"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.
When we query addrs receive we get following result :
{
"events": []
} On mempool we can notice the transaction is confirmed but it AddrReceive Event is not populated.
|
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. 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
{
"transactions": []
} But for Node 1 (Sender), we get the result for this, {
"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
|
AddrEventStatus
fails to populate ADDR_EVENT_STATUS_TRANSACTION_DETECTED
during receive scenario
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
Bitcoin Version
Bitcond Server Uname
|
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
Send API that we hit
Here are the logs while the send occurs
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
This is the response of get info call
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]
The text was updated successfully, but these errors were encountered: