[alexg]

Can you show me your rpcbind config?

[alexg]

Hello,

Thank you for your interest in the plugins and for paying for membership.

You don’t have access because the VATIN you entered cannot be verified on VIES. Please check again the VATIN you entered. Without it, I would have to pay for the tax on user payments.

If you do not have a valid VATIN, let me know. I can cancel your membership and refund your payment so that you can sign up with a non-business plan.

Please let me know either here or over email how you want to proceed.

with regards

[alexg]

See here for the root cause of this issue.

[alexg]

Hello,

Thank you for your detailed response.

The error code I asked for is 28 (curl timeout). This is the root cause of this issue, and also of the problems you report in this other thread. Here’s what happened:

Currently the scalability of all the blockchains is being stress-tested due to the current market conditions. First Bitcoin, then Ethereum, and now it seems many cryptonote chains are also being affected. This is reflected mostly in network congestion and high fees.

Recently someone had the same problem with Monero. The command that issues a transaction takes longer than 30 seconds to complete. Therefore, the curl call from the plugin to the wallet never gets back the TXID.

I am guessing that this is due to network congestion. Another possibility is that, cryptonote transactions wait for more transactions to occur on the network, to do coinjoins and ensure anonymity. If there are too few transactions on the network, this may also be a reason why transaction execution is slow. The NimbusCoin developers should know more about this.

Normally the plugin expects this situation:
– A withdrawal is first marked as succeeded (done) on the DB.
– Then the transaction is attempted on the wallet
– Finally the plugin receives the result of the transaction. If successful, the TXID is updated on the DB. If the wallet responds with an error, the withdrawal is marked as failed.

This is so as to ensure that, if the PHP thread running the withdrawals cron somehow crashes, the withdrawal is not re-attempted.

However in this case, the adapter responds with an Exception, due to an HTTP timeout coming from curl. The plugin thinks that the wallet did not execute the transaction, and reattempts it. The wallet continues to reattempt the transaction, and this is how a double spend occurs.

Several things need to be done here:

– Since the wallet takes so long to place the transaction, you should increase the HTTP timeout beyond 30 seconds in the coin adapter settings. Go to Wallets -> Adapters -> (Your adapter) -> Settings -> HTTP adapter settings -> HTTP request timeout (seconds).
– You should also increase the PHP execution timeout accordingly. How long the wallet needs to perform a transaction is beyond my control.
– It’s a good idea to set the withdrawal attempts to 1 as extra safety. See Wallets -> Cron job -> Max retries for failed withdrawals.

I will soon release a patch that will mitigate this risk. I am still evaluating the correct course of action, but basically, if there is a timeout, the plugin should assume that the transaction is succeeded, not failed. Better to err on the safe side! Then, in case of a timeout, the user balance will be updated correctly. The only problem will then be that the TXID will not be recorded in the DB, but this can be fixed.

In any case, since the wallet takes longer than 30 seconds to place a transaction and respond with a TXID, you should let withdrawals run for 60 seconds, or however long it takes.

I will contact you again here on this thread once I release the aforementioned patch.

with regards

[alexg]

Hello,

Users with an account on your site can deposit funds to their account. These funds are now in your site’s hot wallets, but users still have access to it, so that they can withdraw it again. The plugin’s ledger keeps a copy of these transactions on your MySQL DB so that the user accounts are debited on deposits and credited on withdrawals.

Once users have a balance, they can go to your WooCommerce store and purchase goods. On checkout, they choose which crypto balance to use. Since you have already set up exchange rates, the plugin knows the exchange rate between each crypto coin and your store’s base currency. So the price of each product can be estimated in the various cryptocurrencies on your site. A user will only be able to select a cryptocurrency if they hold enough balance to pay for the entire cart.

On checkout, the funds are transferred internally, (i.e. via off-chain transaction that only exists on your DB) to your designated shop owner account. You set what this user account is in the payment gateway’s settings page. You will likely want this to be your admin account. This account can then withdraw funds to an external wallet, such as an exchange, where you can sell your crypto for fiat.

Hope this is clear.

If you plan on using this gateway, take the time to study the entire homepage for the extension. See also “how does the user pay?” in the FAQ section.

Please let me know if you have any more questions. If your question is about something else, please open a new thread.

with regards

[alexg]

It is Litecoin, I entered credentials using rpcuser/rpcpassword, and I have double check and they are correct.

[alexg]

Hello,

Please tell me the following:

1. You mentioned that “This is for only one coin (this where i have a lot of problems with)”. Do you mean that you also use other coins based on turtlecoin that work fine, and only NimbusCoin has this issue? Or are your other coins based on another coin adapter?

2. You mentioned that “transaction goes through the chain”. How did you determine this? Did you check using the wallet cli?

3. If you increase the HTTP timeout for the coin adapter does this help with the withdrawals? You can specify the HTTP timeout for your adapter at Wallets -> (your turtlecoin adapter) -> “HTTP Adapter Settings” -> “HTTP request timeout (seconds)”

4. In the withdrawal failure email, next to the message “Failed to perform withdrawal due to: phpcurl could not communicate with NimboCoin wallet.”, was there any error code or not?

Thank you.

with regards

[alexg]

Hello,

OK, this discussion is getting somewhat confusing for me, so please allow me to summarize the points I am not sure about. Please try to answer all of the questions carefully in as much detail as possible so I can understand.

1. You mentioned that a user has 1250 coins from the faucet and has never deposited funds. You mentioned also that his wallet file showed over 10 million coins. Can you please explain what you mean by this? The wallet file is there to back the balances of all users, not just one user. Can you please summarize, from the beginning, why you believe that there is a problem with this user’s balance? Why do you think that this user has performed a withdrawal, if there is no withdrawal in the plugin’s ledger? Could it be that the withdrawals you see in the hot wallet are from other users?

2. When you issued a curl API call to the /transactions/hash endpoint, you got back details on a specific blockchain transaction. This is unrelated to any user balances. Could this be a withdrawal initiated by another user?

3. Furthermore, as mentioned before, the available balance will be less that the user balance, if the user has pending outgoing transactions, or if the user has placed orders on the exchange. Is this the case for your user? Did you check?

4. I have mentioned that there is no one-to-one correlation between address balances on the blockchain and user balances, because of off-chain transactions. Can you please confirm if you understand this, or if you want me to explain it further?

5. Can you please explain what you meant by “because this withdraw i did in a “separate” wallet files, restored with keys to try something out”?

6. Are you only experiencing issues with withdrawals from one user? Do other users have no problems with withdrawals? Did withdrawals succeed in your integration/test environment or during development of your site?

To summarize, unfortunately I do not know if I can help you in this situation. There are too many moving parts here.

What I would do in your situation would be this:

– Stop hacking the database and restore the DB backup.
– Move all the funds out of the hot wallet.
– Remove the empty wallet file (but keep it somewhere safe just in case!).
– Let the adapter create a new wallet file for the site.
– Move the funds into the base address of this new wallet file. Do not use any user deposit addresses for this.
– Click on Wallets -> Adapters -> (your adapter) -> Renew deposit addresses.
– Refrain from performing other transactions with this wallet file. Only move funds to and from the cold storage wallet if needed.

This should ensure no more problems from now on. If you encounter an issue with withdrawals after doing this, do not edit the database, and notify me immediately. Let’s solve one issue at a time, so we know what we’re doing.

with regards

[alexg]

Hello,

There are no other situations that I know of where bitcoin would respond with 403.

Can you please be more specific? What did you try?

1. Did you enter credentials using rpcuser/rpcpassword or using rpcauth?

2. Did you enter an rpcbind config? If so, did you specify the network class as mentioned above?

Let me know.

with regards

[alexg]

What you are describing is the expected behavior. If you place a new done withdrawal, then that will affect the user’s balance AND available balance.

I think there is a misunderstanding here, so let me explain what the available balance is:

If you enter a new transaction (categories deposit,withdraw,move,trade) in the done state for a user, it will affect the user balance. The available balance is simply the user balance minus any funds locked in pending outgoing transactions (pending withdrawals and/or pending internal transfers to other users), or in open orders if you are using the exchange extension: For example, say the user has 10 coins. Now the user has placed a pending withdrawal of 1 coin, and has placed a sell order for another 2 coins in a market, so now the available balance will be 7 coins. If later, the exchange order is cancelled, and the withdrawal fails or is cancelled, then the user’s balance will stay at 10, and the user’s available balance will again be 10 coins. Instead, if the withdrawal succeeds and the order gets filled, the users balance will become 7 coins and the available balance will stay at 7. Hope this is clearer.

My suggestion is this:

1. First determine what the problem is: Do you think that a withdrawal or other transaction was not recorded in the plugin’s ledger? If so, why was that? Was there a crash? Don’t try to fix a problem you don’t understand because you can make it worse.

2. Once you determine what information is missing from the database and why, only then edit the database.

I don’t know what happened on your system. First determine what transactions you think the user did, and which ones are missing and why. If you can do that, I can tell you how to reinsert the data to the DB.

with regards

[alexg]

it is still not working

[alexg]

This means that the password you entered in the coin adapter settings does not match the one in your conf file.

In Bitcoin there are two ways to specify RPC API credentials: rpcauth/rpcpassword, and rpcauth. Use one or the other, but not both. Check that the password you’ve entered in the coin adapter settings matches the password in your wallet config.

A common problem is if your password contains the = character. This cannot be used with rpcpassword, as the = character is used as a separator between key and value in the .conf file. The simplest solution is not to use a password with the = character.

Also check that the IP in your rpcallowip clause in in CIDR notation, i.e. it should have something in it specifying the network class (see here).

[alexg]

Yes, of course. You are adding a withdrawal transaction that removes from the user’s balance.

If your balance is negative, it means that this is not the only problem with your database.

Can you start over?

[alexg]

Yes, this looks like it’s expected behavior.

The transaction with the tag acr_burn_128 belongs to user_id 540, and the transaction with the tag acr_burn_8 belongs to user 1 (the admin).

When you call the filter, if you don’t specify a user_id, it uses the current user id (see here). The filter always retrieves transactions for a specific user. This is explained in this phpDoc line.

If you do the following call, you will see the other transaction:

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

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

Hope this helps. Let me know if you have any further questions.

with regards

[alexg]

If this is a test or integration system, it’s much easier to start from scratch.

The second problem is likely tied to the first one: If a user withdrew some funds and this is now not reflected in the DB, then of course the hot wallet balance would be less than the total of user balances. Another likelihood is if the withdrawal fee that you set in the plugin is less than the actual transaction fee paid. Again, just delete everything and start from scratch.

If you know exactly which withdrawal is missing, and you are sure that this is your only problem, then sure, you can insert it into the DB using an insert statement. It would look something like:

INSERT INTO wp_wallets_txs(category,account,address,txid,symbol,amount,fee,status,created_time,updated_time)
VALUES('withdraw',$user_id,$address,$txid,$symbol,$amount,$withdrawal_fee,'done',NOW(),NOW());

where you’d replace all the $variables with the actual values for that transaction.

What I’d do is this:

1. Keep a backup of the DB.

2. Try inserting the withdrawal manually.

3. If things look good, great.

4. If not, start again with a new wallet. Delete all rows in the transactions table and addresses table with symbol equal to your coin’s symbol. Only deposit funds using user deposit addresses. Only withdraw funds using the plugin. If you do this, there won’t be any inconsistencies.

Let me know if you need further help with this.

with regards

[Author]

Posts