Moved: Negative balance after withdrawal

[Anonymous]

I notice user balance going to the negative when sending MAX amount available.

[alexg]

Hello,

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.

Thank you.

with regards

[Anonymous]

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.

[Anonymous]

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.

[alexg]

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 uq_tx_idx.

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 (id),
UNIQUE KEY uq_tx_idx (txid,address,symbol),
KEY account_idx (account),
KEY blogid_idx (blog_id)

Let me know. Thank you.

[Anonymous]

| xx_wallets_txs | CREATE TABLExx_wallets_txs` (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
blog_id bigint(20) NOT NULL DEFAULT ‘1’ COMMENT ‘useful in multisite installs only if plugin is not network activated’,
category enum(‘deposit’,’move’,’withdraw’,’trade’) NOT NULL COMMENT ‘type of transaction’,
tags varchar(255) NOT NULL DEFAULT ” COMMENT ‘space separated list of tags, slugs, etc that further describe the type of transaction’,
account bigint(20) unsigned NOT NULL COMMENT ‘xx_users.ID’,
other_account bigint(20) unsigned DEFAULT NULL COMMENT ‘xx_users.ID when category==move’,
address varchar(120) NOT NULL DEFAULT ” COMMENT ‘blockchain address when category==deposit or category==withdraw’,
extra varchar(120) NOT NULL DEFAULT ” COMMENT ‘extra info required by some coins such as XMR’,
txid varchar(120) DEFAULT NULL COMMENT ‘blockchain transaction id’,
symbol varchar(10) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL COMMENT ‘coin symbol (e.g. BTC for Bitcoin)’,
amount decimal(20,10) NOT NULL COMMENT ‘amount plus any fees deducted from account’,
fee decimal(20,10) NOT NULL DEFAULT ‘0.0000000000’ COMMENT ‘fees deducted from account’,
comment text COMMENT ‘transaction comment’,
created_time datetime NOT NULL COMMENT ‘when transaction was entered into the system in GMT’,
updated_time datetime NOT NULL COMMENT ‘when transaction was last updated in GMT (e.g. for update to confirmations count)’,
confirmations mediumint(8) unsigned DEFAULT ‘0’ COMMENT ‘amount of confirmations received from blockchain, or null for category IN (move,trade)’,
status enum(‘unconfirmed’,’pending’,’done’,’failed’,’cancelled’) NOT NULL DEFAULT ‘unconfirmed’ COMMENT ‘state of transaction’,
retries tinyint(3) unsigned NOT NULL DEFAULT ‘1’ COMMENT ‘retries left before a pending transaction status becomes failed’,
admin_confirm tinyint(1) NOT NULL DEFAULT ‘0’ COMMENT ‘1 if an admin has confirmed this transaction’,
user_confirm tinyint(1) NOT NULL DEFAULT ‘0’ COMMENT ‘1 if the user has confirmed this transaction over email’,
nonce char(32) DEFAULT NULL COMMENT ‘nonce for user to confirm via emailed link’,
PRIMARY KEY (id),
UNIQUE KEY uq_tx_idx (txid,address,symbol),
KEY account_idx (account),
KEY blogid_idx (blog_id)
) ENGINE=InnoDB AUTO_INCREMENT=888 DEFAULT CHARSET=latin1 |
`

[Anonymous]

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.

[alexg]

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 pending.

2. The first withdrawal was attempted by a cron job. For safety, when a withdrawal is attempted, it is first marked as done and then if it fails it is marked as failed.

3. After 1 minute, or due to manual trigger, a second cron job started executing the second withdrawal. The second withdrawal was marked as done and 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 done state.

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 regards

[alexg]

Hello,

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.

With version 1.1.1 this 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 regards

[Anonymous]

Tested and working. Thank you.

[Author]

Posts