[alexg]

I don’t know. First check the points 2, 3, 4, 9, and 10 above and state clearly what you found on each step, so I know what’s going on.

thank you

[alexg]

Hello,

Even though you say that you have received some deposits and not others, I would still tell you to check this troubleshooting article:

HOWTO: Debug an incoming deposit (CoinPayments adapter)

You can skip checks 1, 5, 6, 7, 8, and 11 which are not relevant to you, since you already had some deposits work. See the checks numbered 2, 3, 4, 9, and 10.

Since there are two deposits that were not confirmed by coinpayments at the time, you wouldn’t see them yet in the plugin’s ledger. This is as expected.

Most likely your friend paid fees that were too low for the current congestion in the Bitcoin network. If the transactions are still not confirmed (CoinPayments requires 2 confirmations for Bitcoin) then maybe your friend can do a replace-by-fee.

TL;DR You should check to see if these two transactions that appear stuck in CoinPayments correspond to your friend’s deposits.

Hope this helps.

with regards

[alexg]

When you get a chance to test with the unmodified exchange, focus on the following:

1. Did you place a limit order or market order? Market orders will not execute unless the entire order can be matched against existing open limit orders.

2. Check the orderbook after placing the order. Also check the user history. Click the refresh button to make sure the data is fresh.

Hope this helps.

with regards

[alexg]

Hello,

I have tested the situation you describe with USD_BTC on my end and the exchange appears to function correctly.

In your example, user A has placed an ask order for 10 BTC at a price of $10, with a total order amount of $100.

User B has $1000 in their balance. The current USD_BTC price is $10. User B clicks on the “max” button in the limit buy form, and then clicks on “limit buy btc”. Α bid order is placed on the orderbook for 100BTC at the same price, i.e. for a total of $1000. The order from user A is filled. User B gives $100 to user A. User A gives 10 BTC to user B. The orderbook now has an unfilled bid order for 90 BTC at a price of $10, for a total of $900.

To inspect the orderbook, see the shortcodes: [wallets_exchange_bids] and [wallets_exchange_asks].

Please check a couple of things:

1. Is it possible that, when creating the markets, you mixed up the base and the quote currencies?

https://www.investopedia.com/terms/q/quotecurrency.asp
https://www.investopedia.com/terms/b/basecurrency.asp

The ordering is different from that of most exchanges, for historical reasons that are hard to change right now. “Buy” means buy the quote currency by paying its value in the base currency, and “Sell” means sell the quote currency and get its value in the base currency.

So let me know if you are certain that you’ve set the base and quote coins correctly. I tested with a “USD_BTC” market.

2. Additionally, I see that you are using modified templates. What other code is modified? What version is your copy of the exchange based on? The latest version is 1.3.7.

I can try to help, but it’s very hard to provide support without knowing what was modified (See FAQ under “I want to do changes to the plugin’s code.”)

3. Is it possible for you to test if this occurs with the unmodified exchange 1.3.7?

with regards

[alexg]

Hello,

I have seen this before with various Bitcoin forks.

Some wallets expect a string while others a float. For this reason, the plugin first tries to withdraw first by specifying the amount as a float. If the result code is 500 the plugin retries the withdrawal by issuing the amount as a string. See here:

https://github.com/dashed-slug/wallets/blob/5.0.14/includes/coin-adapter-rpc.php#L507-L547

For some reason this did not work with your MMC wallet.

Please let me know which coin this is (there are several with this ticker symbol). I can then try to reproduce the issue with that wallet and see what the problem is. If you have a github link to the wallet please also provide this, and the commitish or tag or wallet version that you are using.

with regards

Alex

[alexg]

Hello,

Unfortunately no.

However, you could write a PHP script that assigns a particular user role to people with such a condition (and removes the user role to people without the condition).

You can run your script and then perform the airdrop to that user role.

To determine user balances via PHP code, use the wallets_api_balance filter:

https://wallets-phpdoc.dashed-slug.net/classes/Dashed_Slug_Wallets_PHP_API.html#method_api_balance_filter

Hope this helps.

Let me know if you need further advice on how to do this.

with regards

[alexg]

That’s great news. Thanks for letting us know.

Just be careful. Anyone in that IP range can theoretically connect to your wallet, if they also have your RPC password.

with regards

[alexg]

I fixed with rpcallowip=45.87.80.*

[alexg]

It isn’t working, even after I reboot the server

[alexg]

Hello,

There is no rpcbind statement in your config. Add the following:
rpcbind=a.b.c.d
where a.b.c.d is the public internet IP of your wallet server.

Also, I believe that the rpcallowip statements must be in CIDR notation. Try:

rpcallowip=127.0.0.1/8
rpcallowip=45.87.80.226/24
rpcallowip=45.87.80.240/24
rpcallowip=45.87.80.254/24

with regards

[alexg]

rpcuser=xxxx
rpcpassword=xxxx
rpcallowip=127.0.0.1
rpcallowip=45.87.80.226
rpcallowip=45.87.80.240
rpcallowip=45.87.80.254
rpcport=9332
server=1
daemon=1
txindex=1
listen=1

[alexg]

@Donfury1 Hello, I’m sorry, I don’t understand your question. Are you asking how to load the current exchange rates into the plugin? Please explain in more detail what you want to know. Thanks!

[alexg]

If the available balance is negative, but the user balance is positive or zero, then all is good.

As mentioned above, simply cancel any pending outgoing transactions for that user. And also cancel any exchange orders for that user. The user can place these transactions again.

I have now uploaded version 5.0.14 of Bitcoin and Altcoin Wallets and version 1.1.2 of the Monero coin adapter. With this patch, if a withdrawal fails due to a phpcurl timeout, the withdrawal is marked as done even if there is no available TXID. This will prevent any more double-spends.

Again, my apologies for this issue with withdrawals. It is something that I could not have tested for, because the issue was caused partly by network conditions that were not present when I tested the adapter, and because I only tested on Monero and TurtleCoin. Since withdrawals were repeated, more funds have been sent to the user than they should. I sincerely hope that this did not result in loss of too many funds 🙁

If you have a suggestion for the UI, please open a new thread about it. I no longer accept any feature requests/suggestions, only defects. But if it’s something easy I may be able to do it for the next version. And if not, then I can instruct you on how to edit the template files.

with regards

[alexg]

Hello Patrik,

OK then, makes sense. You don’t have an EU VATIN because of brexit. The tax-free plans are only for EU businesses, where tax can be paid in the business’s home country instead.

You don’t have to pay the difference in price this time (it’s a very small amount) but I’m editing your subscription to correct this. If you encounter any more problems with accessing the plugins, please let me know.

with regards

P.S. As a sidenote, you mentioned that you want to setup the plugin today. You should not have the expectation that you will be able to set everything up in one day. This is a complex plugin and a lot of issues can delay your setup. If you are working for a client, you may want to communicate this to them. If you do encounter issues, please contact me on the forum or over email.

[alexg]

Hello,

To find which DB withdrawals match to which transactions, you can look at the times and amounts. Hope it’s not too much work.

I have not been able to develop the patch due to too much workload right now. It will be out before the end of the week, as this is kind of important!

with regards

[Author]

Posts