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.

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

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.

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