February 17, 2021 at 6:31 pm #10010
I notice user balance going to the negative when sending MAX amount available.February 18, 2021 at 7:08 am #10014
This sounds worrying. I need a lot more details please.
I have moved your post to a new thread, as it’s likely not directly related to the previous issue with withdrawal timeouts and the underlying coin adapter.
Normally the user balance is checked both at the time a withdrawal is submitted, and later when it’s executed.
Please tell me the following:
1. What was the balance before and after?
2. What was the withdrawal amount and fee? (You can get these from the transactions list admin screen)
3. Were there other transactions executed? It’s likely that there were stale withdrawals from the previous issue, that got executed later for some reason.
4. Can you reproduce the issue with a new user account? I’d like to rule out the possibility that this is somehow related to the issue with withdrawals hitting the timeout.
If the balance is negative by a very very small amount, this could be a floating point error, and this is one of the types of errors that will be fixed with wallets6, which uses only integers internally. If the amount was larger, we’ll have to look into this.
If you can provide step-by-step instructions for how to reproduce the issue, please do.
with regardsFebruary 18, 2021 at 11:56 am #10017
I used the send-to-user form to move .1 xmr to a new user account. No problem.
I sent MAX available .1 xmr from new user wallet to external wallet.
One transaction was sent. Another transaction was created but did not send. See attached images.
Both transaction were assigned same TXID
Fee for successful transaction was: XMR 0.000011180000
I have fixed fee for withdraw set at XMR 0.00001700
One transaction was successful for the correct amount: 0.099983 XMR
I set retry limit to ONE in adapter
I’ve tried withdraw twice with new user accounts with the same result.
Attachments:You must be logged in to view attached files.February 18, 2021 at 2:04 pm #10022
I understand the fixed fee is different from the actual fee charged by the network. But the second transaction shows my fixed fee amount so I suppose it is relevant.February 19, 2021 at 7:11 am #10023
I think I see what’s going on here.
You have two transactions with the same triplet of (TXID, symbol, and address).
Normally there is a unique constraint on these columns on the DB. The constraint’s name is
It’s possible that you are missing this constraint, if you transferred the database via export/import.
What I find strange is that normally the plugin would warn you about this in the admin screens. Did you ever see such a notice in the admin screens?
Can you please go to your MySQL console and type the following?
SHOW CREATE TABLE wp_wallets_txs;
The indices on the table should look like this:
PRIMARY KEY (
Let me know. Thank you.February 19, 2021 at 5:45 pm #10027
| xx_wallets_txs | CREATE TABLExx_wallets_txs` (
idint(10) unsigned NOT NULL AUTO_INCREMENT,
blog_idbigint(20) NOT NULL DEFAULT ‘1’ COMMENT ‘useful in multisite installs only if plugin is not network activated’,
categoryenum(‘deposit’,’move’,’withdraw’,’trade’) NOT NULL COMMENT ‘type of transaction’,
tagsvarchar(255) NOT NULL DEFAULT ” COMMENT ‘space separated list of tags, slugs, etc that further describe the type of transaction’,
accountbigint(20) unsigned NOT NULL COMMENT ‘xx_users.ID’,
other_accountbigint(20) unsigned DEFAULT NULL COMMENT ‘xx_users.ID when category==move’,
addressvarchar(120) NOT NULL DEFAULT ” COMMENT ‘blockchain address when category==deposit or category==withdraw’,
extravarchar(120) NOT NULL DEFAULT ” COMMENT ‘extra info required by some coins such as XMR’,
txidvarchar(120) DEFAULT NULL COMMENT ‘blockchain transaction id’,
symbolvarchar(10) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL COMMENT ‘coin symbol (e.g. BTC for Bitcoin)’,
amountdecimal(20,10) NOT NULL COMMENT ‘amount plus any fees deducted from account’,
feedecimal(20,10) NOT NULL DEFAULT ‘0.0000000000’ COMMENT ‘fees deducted from account’,
commenttext COMMENT ‘transaction comment’,
created_timedatetime NOT NULL COMMENT ‘when transaction was entered into the system in GMT’,
updated_timedatetime NOT NULL COMMENT ‘when transaction was last updated in GMT (e.g. for update to confirmations count)’,
confirmationsmediumint(8) unsigned DEFAULT ‘0’ COMMENT ‘amount of confirmations received from blockchain, or null for category IN (move,trade)’,
statusenum(‘unconfirmed’,’pending’,’done’,’failed’,’cancelled’) NOT NULL DEFAULT ‘unconfirmed’ COMMENT ‘state of transaction’,
retriestinyint(3) unsigned NOT NULL DEFAULT ‘1’ COMMENT ‘retries left before a pending transaction status becomes failed’,
admin_confirmtinyint(1) NOT NULL DEFAULT ‘0’ COMMENT ‘1 if an admin has confirmed this transaction’,
user_confirmtinyint(1) NOT NULL DEFAULT ‘0’ COMMENT ‘1 if the user has confirmed this transaction over email’,
noncechar(32) DEFAULT NULL COMMENT ‘nonce for user to confirm via emailed link’,
PRIMARY KEY (
) ENGINE=InnoDB AUTO_INCREMENT=888 DEFAULT CHARSET=latin1 |
`February 19, 2021 at 7:05 pm #10028
the database was not imported through the tool. I did rescan the xmr wallet preceding this issue. But I’m not sure if they are related. I successfully performed a withdraw using the same steps as described before your latest update. But I’m not sure if that is related to my issue.February 22, 2021 at 8:50 am #10039
My mistake, this has nothing to do with the DB constraint. The two withdrawals have the same TXID but are to different addresses. This is obviously wrong. What I think happened is this: 1. You issued two withdrawals. Both became
2. The first withdrawal was attempted by a cron job. For safety, when a withdrawal is attempted, it is first marked as
doneand then if it fails it is marked as
3. After 1 minute, or due to manual trigger, a second cron job started executing the second withdrawal. The second withdrawal was marked as
doneand was then attempted.
4. The first withdrawal succeeded and its TXID was marked in the database. 5. The cron job for the second withdrawal timed out. The DB entry remained in a
6. The second withdrawal failed possibly due to lack of funds in the hot wallet. In short, this is a double-spend due to a race condition. I have not yet understood why the two entries would get the same TXID. Fortunately the upcoming wallets6 has better prevention to ensure that two cron jobs do not run concurrently. My aim now is to patch such issues with the old codebase for as long as necessary, until the better architectural design of wallets6 is online. I will now release a patch to the monero coin adapter that prevents this situation from happening again. I think the safest way is to lock withdrawals before each withdrawal and only unlock them after the withdrawal succeeds or fails. The lock can be implemented as a transient, so that in case of a timeout or other crash, the lock will eventually be released after a reasonable amount of time (e.g. 5 minutes). Thank you for identifying this issue, as double-spends are always very serious issues!
I will post again here when I release the relevant patch. I aim to release a fix to this serious issue, either today or very soon.
with regardsFebruary 23, 2021 at 8:06 am #10050
OK, found the bug. This was not as complex as I previously thought, and had nothing to do with race conditions.
Previously, withdrawals could appear doubled. Fortunately, this would NOT have resulted in actual funds being lost from the hot wallet.
However, the bug would make user balances appear less than they should, because withdrawals would appear doubled in the plugins ledger.
1.1.1this cannot happen any more. I have tested deposits and withdrawals again and everything looks good. I do not believe you will experience any more problems with this coin adapter.
If you need to correct the plugin’s ledger, here’s how to do this: For each TXID, there are two withdrawals. The first one (the one with the lower ID) is the correct one. The second one (the one with the higher ID) is a withdrawal to another address in your hot wallet. This can be safely deleted.
Again thanks for your help and your patience while I worked on this issue.
with regardsFebruary 24, 2021 at 1:07 am #10054
Tested and working. Thank you.
- You must be logged in to reply to this topic.