Scan TXS stuck on newer version about monero-ts HOT 19 OPEN

Worth checking the logs, but guessing it's this refresh call here that's taking a while:

https://github.com/monero-project/monero/blob/cc73fe71162d564ffda8e549b79a350bca53c454/src/wallet/wallet2.cpp#L1925-L1927

In order to make sure the wallet's blockchain state is in a correct state after the call to scan_tx, it syncs starting from that tx (block 2214401) to chain tip (2510617 as of this writing). As noted in that TODO, could either use fast_refresh for that purpose with some refactoring, or just allow updating the wallet's blockchain state to be handled on next refresh loop

from monero-ts.

@woodser Can you please check this up?!

from monero-ts.

I've confirmed it's hanging on wallet2's scan_tx with the above code.

The same behavior is seen using monero-wallet-rpc, so it appears to be an issue in upstream monero-project.

@j-berman Maybe you know why calling scan_tx could hang when called with 2c4dacb50197ae631da53a4f5fd8baca44386e8e53fe1c7d348db5d3e88133b2 with the above test wallet?

These commits stand out as possible culprits since they changed the scan_txs function:

commit b51f4a9244a6aa537306ec041b7a918175e86989
Author: j-berman <[email protected]>
Date:   Tue Jul 18 16:06:01 2023 -0700

    scan_tx: fix custom comparator for == case; fixes #8951
    
    Co-authored-by: woodser <[email protected]>

commit 65e13dbef1c3a4cc036919203eec2052a121f034
Author: j-berman <[email protected]>
Date:   Fri Sep 9 20:34:18 2022 -0600

    wallet2: fix rescanning tx via scan_tx
    
    - Detach & re-process txs >= lowest scan height
    - ensures that if a user calls scan_tx(tx1) after scanning tx2,
    the wallet correctly processes tx1 and tx2
    - if a user provides a tx with a height higher than the wallet's
    last scanned height, the wallet will scan starting from that tx's
    height
    - scan_tx requires trusted daemon iff need to re-process existing
    txs: in addition to querying a daemon for txids, if a user
    provides a txid of a tx with height *lower* than any *already*
    scanned txs in the wallet, then the wallet will also query the
    daemon for all the *higher* txs as well. This is likely
    unexpected behavior to a caller, and so to protect a caller from
    revealing txid's to an untrusted daemon in an unexpected way,
    require the daemon be trusted.

from monero-ts.

@sharifzadesina I recommend opening an issue in monero-project describing the problem, since it appears to originate there.

from monero-ts.

it just stuck and then returns [0, 0]

After calling scanTxs, the wallet has the referenced transaction, so that's correct.

Returning [0, 0] from getNumBlocksToUnlock is also correct since it represents the number of blocks until the next and last funds unlock.

So I think the only question is why does scanTxs() take so long.

from monero-ts.

To confirm that's the issue and/or a temp workaround if it is the issue, you could also grab a tx hash from a recent block and include that in the array to scan_txs

from monero-ts.

Calling createWalletFull with a restoreHeight set to the current chain tip should also prevent this issue, and I think is a fairly reasonable solution here

edit: this might need an additional call to sync the wallet before calling scan_txs to work correctly though (shouldn't be necessary)

from monero-ts.

@woodser Why [0,0] is a valid response?! in v0.7.12, it returns the valid response without any problem.
Is something in monero-project changed since 0.7.12?!

from monero-ts.

@j-berman the transaction I used to test, was new when writing this issue, but it is not new now.
Also, for newer transactions, it also takes too long and wrong responses. but in 0.7.12, everything just works fine.

from monero-ts.

The monero-project's scan_tx in 0.7.12 was broken in different ways unfortunately which is why the feature was modified in the monero-project (and subsequently updated in monero-ts). I'm not sure what the expected syncRange should be, but calling createWalletFull with restoreHeight set to the current chain tip should yield your expected behavior

from monero-ts.

@j-berman it should be [2214401, 2214401] (the block transaction is in the block 2214401), in v0.7.12, it shows the valid block number.
I also tried setting restoreHeight to the current block height, but it didn't work.

from monero-ts.

getNumBlocksToUnlock() should return [0, 0] if the balance is fully unlocked, which is the case scanning this transaction, so that should be correct.

From the documentation: @return {Promise<number[]>} the number of blocks until the next and last funds unlock in elements 0 and 1, respectively, or undefined if no balance. If all funds are unlocked, there are 0 blocks left.

from monero-ts.

@woodser The problem is, the money is not unlocked yet, because the wallet is not synced yet, I am getting the block range, to sync those blocks and unlock the money.

from monero-ts.

From j-berman's comment, scan_tx is calling refresh which syncs to the chain tip, so that would explain the [0, 0] result now, because the wallet is synced after that.

from monero-ts.

@woodser Hmmm, so why it doesn't work when I set the restoreHeight to the latest block height?!

Just tested right now, please you can also check, set restoreHeight to the latest testnet block height, it still returns [0, 0].

from monero-ts.

Even if you set the restore height to the current height, then when you scan the tx, the wallet knows the funds are fully unlocked at the current height, so [0, 0] is correct.

from monero-ts.

@woodser So the workaround is to set the height to "0", but prevent scan_tx from calling refresh?

from monero-ts.

I don't know that there is a workaround, aside from modifying scan_tx to avoid the refresh call. Something needs changed with this todo.

I'd recommend opening an issue on monero-project to address the todo.

from monero-ts.

@woodser Please if you don't mind add more info on the issue, because I don't have enough knowledge of the internal Monero library.

from monero-ts.