[alexg]

If you submit a withdrawal request via the JSON-API or PHP-API, then a new withdrawal row will be entered in the DB in an unconfirmed state. The cron job will then progress it to a pending state. If the adapter is unlocked and if the hot wallet has enough unlocked funds, and if the available user balance is sufficient, then the withdrawal will be executed by a cron job. It will get the done or failed state.

Why do you need to enter to the DB a withdrawal that has already occurred?

If a withdrawal has already occurred on your hot wallet, independently from the plugin, this cannot be safely mapped to a user balance. This is because only the plugin knows how much balance a user has, and what portion of it is not locked into exchange orders or other pending transactions. Primarily due to the internal transfers and exchange trades features, you cannot expect a user’s balance to correspond to a particular blockchain address.

The only deposits and withdrawals that should occur on your hot wallet besides user transactions are the cold storage transactions. That is, you can safely do transactions to control the percentage of online reserves, and these are not reflected in the DB. Do not do any other transactions with the wallet attached to the plugin.

It sounds like you are trying to hack the db in a way that will result in lost funds.

Please describe in more detail what you are trying to do and I will be able to provide guidance on whether what you are doing is safe and whether there is a better way.

[alexg]

Hello,

I’m not sure why you get back an empty array.

I tried to recreate your example and it works fine.

I first placed an internal transfer:

do_action('wallets_api_move', array(
	'symbol' => 'ARMS',
	'amount' => 5,
	'from_user_id' => 1,
	'to_user_id' => 2,
	'fee' => 0,
	'comment' => 'Cash out of ARMS Rewards to 2ACoin (ARMS)!',
	'skip_confirm' => true,
	'tags' => 'acr_burn acr_burn_128',
));

Then I tried to retrieve it in a similar way to yours:

$args = array(
	'symbol' => 'ARMS',
	'categories' => array('move'),
	'tags' => array('acr_burn'),
);

apply_filters('wallets_api_transactions', array(), $args);

The result contains the transfer, as you can see in the attached screenshots.

The PHP API by default retrieves transactions owned by the current user. This is why in my test I get the send part of the transaction (credit) but not the receive part (debit). If you were calling the PHP code from another user account, you would have to specify a user_id argument to wallets_api_transactions. This will get you the transactions belonging to a specific user. See the docs for this.

Can you try the exact code I pasted above, to see what happens? I ran both snippets from the same account, (user_id 1), with an ARMS balance.

Let me know what you found.

with regards

P.S. As a sidenote, you don’t need to dump debug data to the frontend, because your debug output can break your HTML. A cleaner way to inspect your debug prints is to write to the debug logs using error_log(). Or simply use WP-Console, I find it very useful for these types of tests.

Attachments:

You must be logged in to view attached files.

[alexg]

Hello,

OK. If I understood the problem correctly: Can you just replace all the wrong ticker symbols in the db with the right one?

Hopefully you are doing these experiments on a dev/integration server and not production. Simply delete all transactions and addresses for these two ticker symbols and start again.

If you are in a production environment, keep a backup of the entire DB state.

Then, substitute all symbol columns in the addresses table and transactions tables. I guess that something like the following should work:

UPDATE wp_wallets_txs SET symbol='NEW' WHERE symbol='OLD';
UPDATE wp_wallets_adds SET symbol='NEW' WHERE symbol='OLD';

Hopefully you won’t get too many collisions on the unique constraints.

Let me know if this helps. If not, restore your backup and we’ll try something else.

with regards

P.S. I have moved your query to a new thread as it is unrelated to the previous thread.

[alexg]

Hello,

The recommended way to insert a new withdrawal using PHP is via the PHP API.

You also have the option to place a withdrawal via the JSON-API. If calling from the frontend, you can directly call the API. The login cookie in your browser will provide authentication. If you are calling from elsewhere, you need to have the user’s bearer token (you can get the bearer token from the user’s profile or from a get_nonces call while logged in with cookies. See the documentation for details.

If you want to directly insert a withdrawal into the DB you can also do this, but know that the SQL tables are going to be removed in wallets6, which will be out in a few months.

The PHP-API and JSON-API are currently being re-engineered for the new design and will remain, marked deprecated, for a long time, to allow a smooth transition to the new architecture. In fact, part of the reason that development is taking so long is because I am doing a test-driven re-development of these two APIs to ensure compatibility.

with regards

[alexg]

Hello,

The exchange plugin is not really suitable for selling crypto with fiat, or for token sales. It’s more appropriate for creating a crypto market between your custom coin and a more well-known crypto such as Bitcoin or Ethereum.

If you are trying to sell crypto for fiat money, you will encounter two problems:

1. Only bank transfers are allowed via the Fiat coin adapter extension. This may be OK with you or not, depending on your business plan.

2. The Exchange extension needs someone to provide liquidity at the currently accepted prices. If the price of the asset you’re selling changes, you must update your orders. You can do this either manually, or preferably via the JSON-API. To do this via the Exchange’s JSON-API requires you to develop custom code.

Having said this: The UI for end users does not have to be complicated. You can use the following shortcode: [wallets_exchange_market_order]. For more details, see the following post: https://www.dashed-slug.net/exchange-swap-ui-plus-theme-templating/

General guidelines for how to setup the Exchange are here: https://www.dashed-slug.net/howto-setup-a-cryptocurrency-exchange-on-wordpress/

Hope this helps. Let me know if you have more questions.

with regards

P.S. In the future, could you please post in English? I ask you this for the benefit of others reading this forum, and also because auto-translate is never perfect.

[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

[alexg]

Hello,

If you are using a full node wallet as a backend, then yes, you can import a private key to your wallet.

Doing so will add any balance on that address to your hot wallet balance. (It will not affect any user balances, as there is no 1-1 correspondence between user balances and any addresses on your wallet.)

How you import private keys has nothing to do with the plugin. Consult the documentation of your wallet.

If your wallet is a Bitcoin core fork, then instructions on how to import a WIF private key using the importprivkey command are here and here.

Please let me know if you have any more questions.

with regards

[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]

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.

[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

[alexg]

Hello,

Do you have two subscriptions?

If so, email me with the details.

You can also cancel a PayPal recurring payment by yourself from here.

with regards

[alexg]

Hello,

Thank you for spotting this.

The static templates were not accepting ticker symbols with dots in them. This is now fixed in version 1.3.7 of the Exchange extension.

As a sidenote:

The format for markets is BASE_QUOTE, not QUOTE_BASE as is usual in other exchanges.

The reason for this is historical. When I started the exchange, only Poloniex and Bittrex was around, and I copied the notation as used in Bittrex at the time. So, if you want to create a market where Bitcoin is traded against the dollar, that would be a USDT.ERC20_BTC market. Not the other way around.

It’s important to get the ordering right, because the semantics of “bid (buy)” and “ask (sell)” refer to buying or selling the quote currency against the base currency.

with regards

[alexg]

Hello,

The Exchange extension has its own JSON-API, similar to that of the parent plugin.

If you get the bundle download for the exchange, you will find the documentation in there.

See the section in the PDF file under the heading “JSON-API”.

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

[alexg]

Hello,

Thank you for the suggestion.

The plugin is not directly compatible with staking rewards from PoS wallets. This is because there is no 1-1 correlation between user balances and anything in the hot wallet itself.

You can use the Airdrop extension to define a recurring airdrop. A recurring airdrop is one that is executed at regular intervals (such as every day/week/etc). The airdrop amount can be a fixed amount or a percentage of a user balance, and you can specify the airdrop to apply to all users or to a specific user role only.

Hope this helps. Please let me know if you have any more questions about this.

with regards

[Author]

Posts