Forum Replies Created
February 23, 2021 at 8:28 am in reply to: Buy/sell Bitcoin against fiat (Poner un compra y venta de bitcoins) #10052
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.
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.
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.
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.
Please let me know if you have any more questions.
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.
- This reply was modified 1 day, 18 hours ago by alexg. Reason: turns out this was not the issue
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.
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.
Do you have two subscriptions?
If so, email me with the details.
You can also cancel a PayPal recurring payment by yourself from here.
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_BTCmarket. 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.
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 regardsFebruary 16, 2021 at 8:52 am in reply to: Minimum confirmation adapter setting, and wallet rescan #9999
I have uploaded version
1.1.0of the Monero coin adapter with several improvements that you can read about in
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.
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 regardsFebruary 15, 2021 at 8:48 am in reply to: Minimum confirmation adapter setting, and wallet rescan #9990
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.
Apologies if the instructions were unclear.
I meant that you need ssh access to the server where you are installing Bitcoin core, not to the router.
The only situation where you’d have to do something with your router, would be if you were attempting to connect to a Bitcoin core wallet located in your home/residential network, from an external webserver that runs WordPress. In that situation, you would have to use NAT (Network address translation) to forward incoming RPC-API connections (TCP port
8332by default) from WordPress to your local wallet machine. In most routers you can do this via the web interface, and how you do it will depend on your router model.
Please let me know if you have any more questions about installation/configuration.
with regardsFebruary 12, 2021 at 5:44 pm in reply to: Minimum confirmation adapter setting, and wallet rescan #9980
OK, this makes sense.
Error 28: Operation timed out after 29999 milliseconds with 0 bytes received.is consistent with what I report in my previous post.February 12, 2021 at 5:11 pm in reply to: Minimum confirmation adapter setting, and wallet rescan #9978
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.