Minimum confirmation adapter setting, and wallet rescan

[Anonymous]

Hello. How do I set minimum confirmations in the XMR adapter? I don’t see an option for that in lastest XMR adapter setting.

Also, is there a way to rescan the monero wallet. I’m having trouble getting the wallet to see a TXID. Transaction remains pending.

Thank you.

[alexg]

Hello,

It’s not possible to set the minimum confirmations count via the coin adapter settings for the Monero/Cryptonote adapter.

The adapter discovers incoming transactions via the get_transfers API: https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_transfers

If, for a transaction, confirmations > suggested_confirmations_threshold, then the transaction is considered “done”, otherwise it’s “pending”.

The block height scanned is saved in a transient that resets every 8 hours, so that the chain is re-scanned often.

Please tell me the following:

1. When you go to Wallets -> Transactions, do you see the transaction in a pending state, or does the transaction not appear at all?

2. When you go to Wallets -> Adapters, what is the Block Height for the Monero adapter?

3. Did you use a payment ID in the transaction? As always, the plugin will check the address and payment id, if any, and see if it matches an (address,payment_id) in the user deposit addresses set (Wallets -> Deposit Addresses screen). If there is no exact match, you will not see the transaction in the Wallets -> Transactions screen.

Let me know. Thanks.

[Anonymous]

Hello. Thanks for your reply. This is a withdraw XMR transaction. The transaction was successful (the funds showed up on the other end). However, the transaction status reported failed in Wallets > Transactions. When using the JSON API (https://example.com/wallets/api3/notify/XMR/wallet/e0c829f453ca26ba81d21ed96871e85bedf9f83acdc95b10937da2d9526f62c4) returns {“result”:”success”}

1. I can see the transaction in the list as pending until the retry limit is reached and then it goes to fail and no TXID is reported even though the funds did in fact send properly.

2. Going to Adapters page reports the latest top block 2294442

3. Payment ID was not used

Be aware that I’ve been messing with my monero Daemon and monero-wallet-rpc stop, starting, restarting and also canceling transactions on the Wallet > Transactions page. So I’m probably introducing some weird gremlins.

Hope you are staying sane during the global psyop.

[Anonymous]

Also, my XMR adpater is sending funds to the wrong user. If a user requests new xmr address and they send funds to that address, a different user is credited with the funds!

I think I should start over!

[Anonymous]

also, i want to make it clear that your plugin worked fine until i started messing with things that certainly should never be messed with on a production server. i understand u are planning a major update.

[Anonymous]

I’m sorry for all these words.

I’ve done some additional testing. After selecting Create deposit addresses now for all users on XMR adapter setting.

This fixed the wrong user/address issues.
I was able to send and receive to the wallet.
However, on wallets > transaction page I’m still having issues showing confirmation count on outbound transactions.

I’m seeing this occasionally in my monero rpc log:
Error calling gettransactions daemon RPC: r 1, status <error>

I don’t know if that’s related to my issue of missing confirm counts on withdraws.

[alexg]

Hello,

I hadn’t understood yesterday that this was a withdrawal, I thought it was a deposit. Answering to your posts in order:

As you may or may not know, the plugin cannot “withdraw” to an address that is also a deposit address for another user. For this reason, if it detects such a situation, it does an internal off-chain transfer instead. I’m not sure if this is what you were trying to do. Since your transaction appeared on the blockchain, this was likely not the case.

You are correct that you should be testing in an integration server before letting actual users use a feature. Even if I never make any mistakes (and I do), there can always be issues with integration.

It sounds like the deposit addresses were not consistent. If by recreating user addresses part of the issue was fixed, that’s good news.

The error Error calling gettransactions daemon RPC: r 1, status <error> is not something I know about. I quickly googled the error. Other users are getting the same error when they use older clients. Are you on Monero 0.17? I am testing with the 0.17 release, built from commit-ish 25670398b.

Yes, I am working on a complete rewrite of the entire codebase, partly because I want to move to more rigorous unit, and integration, testing. This is an effort I started on August and will likely take until the coming summer. Hopefully after this, there will be much less issues/defects. Before the next bullrun the plugin will definitely be ready for sustainable growth in quality and in its user base. If you have questions about this transition, you can post them at the migration forum.

Yesterday I had the Monero testnet chain fully synced, and today I will test again withdrawals on the Monero adapter. I will look for any situation where a withdrawal is executed without that fact being reflected in the plugin’s ledger. I will get back to you.

Please confirm that you are using Monero v0.17.

[alexg]

Additionally, set the number of retries to 1 for withdrawals until we figure this out. You don’t want any withdrawals executed 3 times instead of 1.

[alexg]

Hello,

After running some tests on testnet, I believe I may have an answer for you.

When the withdrawal is attempted, the plugin must do an RPC call to the wallet. The wallet then proceeds to sign the transaction, and then responds to the plugin with a TXID.

In my tests, transaction signing took too long (longer than 30 sec in one instance) and therefore the WordPress thread that waited for the TXID died before it could get it and save it to the DB.

Of course whether this happens will depend a lot on what network you’re running on (mainnet might be even slower than testnet) and will also depend on your server and possibly disk seek speed (mechanical vs SSD). In any case, this is what I observed.

You can go to the coin adapter settings and set the max HTTP timeout to 60, or even 120 seconds (default is 30). You would also have to increase the PHP timeout and all other server timeouts so that your WordPress request runs more than 30 seconds, too. I believe if you do increase the limits to 1 or 2 minutes (60 to 120 seconds), monero withdrawals will be processed correctly.

I also noticed a bug that I will be fixing soon, in the coin adapter settings, if you leave the password field blank and hit save, the password is deleted from the db, so if you go there and change the HTTP timeout, you’ll have to reenter your password at this time.

Hope this helps. Please let me know if you had success with this method or not.

with regards

[Anonymous]

The withdraw is to a different wallet. Not user-user internal transaction. I’m using latest 17.1.9

additional testing:

Setting retry attempts to 1 – transaction is successful. However adapter sends error: Your withdrawal request has FAILED permanently. (Also tried retry attempts on 2 and 3.)

Last error message: Could not execute withdrawal: Could not communicate with Monero wallet. Error 28: Operation timed out after 29999 milliseconds with 0 bytes received.

However, the transaction builds and sends through the RPC no problem.

The main issue here: the user balance does not reflect the withdraw, but the funds are sent from the wallet.

I don’t know if this is on XMR side or Adapter side. I’m using latest 17.1.9

[alexg]

OK, this makes sense.

The error Error 28: Operation timed out after 29999 milliseconds with 0 bytes received. is consistent with what I report in my previous post.

[Anonymous]

Thank you. Setting the http timeout to 256 did fix the failed transaction issue.
Outbound XMR transactions are successful and now assigned a TXID in the transaction list, however, confirmation count remains zero on wallets > transaction and user front end.

This is only for outbound transactions.
Inbound transactions show correct confirm count.

I tried a couple different Monero Daemon connections with no effect on missing confirm count for withdraws at wallet > transactions

Thanks again for your help.

[alexg]

OK thank you for the update.

I can confirm that the confirmation count of outgoing withdrawals does not update, at least not right away. The status is shown as “done” but the confirmation count stays at zero. This doesn’t cause any real issue with user balances, since the transaction is considered “done”.

I will investigate, and then I will prepare a patch to the adapter to fix this issue, and a few other minor ones, such as the one with the password that I mentioned earlier.

I will notify you again here.

with regards

[alexg]

Hello,

I have uploaded version 1.1.0 of the Monero coin adapter with several improvements that you can read about in CHANGELOG.html.

Withdrawals will now continue to update their confirmation counts in the plugin, even after being marked as “done”, for about another 1000 blocks. After that, the confirmations will update less often.

You can update your coin adapter now.

with regards

[Anonymous]

Tested and working. Thanks!

[Author]

Posts