Forum Replies Created
-
AuthorPosts
-
February 15, 2021 at 8:48 am in reply to: Minimum confirmation adapter setting, and wallet rescan #9990alexgKeymaster
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.
with regards
alexgKeymasterHello,
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
8332
by 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 regards
alexgKeymasterGiving Interest to people who save money in the wallet.
February 12, 2021 at 5:44 pm in reply to: Minimum confirmation adapter setting, and wallet rescan #9980alexgKeymasterOK, this makes sense.
The error
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 #9978alexgKeymasterHello,
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.
with regards
February 12, 2021 at 9:45 am in reply to: Minimum confirmation adapter setting, and wallet rescan #9977alexgKeymasterAdditionally, set the number of retries to 1 for withdrawals until we figure this out. You don’t want any withdrawals executed 3 times instead of 1.
February 12, 2021 at 9:34 am in reply to: Minimum confirmation adapter setting, and wallet rescan #9976alexgKeymasterHello,
I hadn’t understood yesterday that this was a withdrawal, I thought it was a deposit. Answering to your posts in order:
As you may or may not know, the plugin cannot “withdraw” to an address that is also a deposit address for another user. For this reason, if it detects such a situation, it does an internal off-chain transfer instead. I’m not sure if this is what you were trying to do. Since your transaction appeared on the blockchain, this was likely not the case.
You are correct that you should be testing in an integration server before letting actual users use a feature. Even if I never make any mistakes (and I do), there can always be issues with integration.
It sounds like the deposit addresses were not consistent. If by recreating user addresses part of the issue was fixed, that’s good news.
The error
Error calling gettransactions daemon RPC: r 1, status <error>
is not something I know about. I quickly googled the error. Other users are getting the same error when they use older clients. Are you on Monero0.17
? I am testing with the 0.17 release, built from commit-ish25670398b
.Yes, I am working on a complete rewrite of the entire codebase, partly because I want to move to more rigorous unit, and integration, testing. This is an effort I started on August and will likely take until the coming summer. Hopefully after this, there will be much less issues/defects. Before the next bullrun the plugin will definitely be ready for sustainable growth in quality and in its user base. If you have questions about this transition, you can post them at the migration forum.
Yesterday I had the Monero testnet chain fully synced, and today I will test again withdrawals on the Monero adapter. I will look for any situation where a withdrawal is executed without that fact being reflected in the plugin’s ledger. I will get back to you.
Please confirm that you are using Monero
v0.17
.alexgKeymasterHello,
I created an account on your site and checked the chart. Two issues:
1. You are still using the static template. Did you try the dynamic one, as suggested above?
2. Your theme is causing a JavaScript error. This causes the UI to stop working. If you can, fix the error in your theme. Otherwise you’d have to use another theme.
February 11, 2021 at 9:59 am in reply to: Minimum confirmation adapter setting, and wallet rescan #9965alexgKeymasterHello,
It’s not possible to set the minimum confirmations count via the coin adapter settings for the Monero/Cryptonote adapter.
The adapter discovers incoming transactions via the
get_transfers
API: https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_transfersIf, for a transaction,
confirmations
>suggested_confirmations_threshold
, then the transaction is considered “done”, otherwise it’s “pending”.The block height scanned is saved in a transient that resets every 8 hours, so that the chain is re-scanned often.
Please tell me the following:
1. When you go to Wallets -> Transactions, do you see the transaction in a pending state, or does the transaction not appear at all?
2. When you go to Wallets -> Adapters, what is the Block Height for the Monero adapter?
3. Did you use a payment ID in the transaction? As always, the plugin will check the address and payment id, if any, and see if it matches an (address,payment_id) in the user deposit addresses set (Wallets -> Deposit Addresses screen). If there is no exact match, you will not see the transaction in the Wallets -> Transactions screen.
Let me know. Thanks.
February 11, 2021 at 8:28 am in reply to: I made a deposit into a wallet of a new user I created and it did not show up… #9961alexgKeymasterHello, this is correct.
You can only filter by user and by category, but not by deposit address.
Unfortunately that feature is not available.
alexgKeymasterIf you are using the static template, then there will be no requests. The data is loaded once from the server.
Like I mentioned in the other issue you posted, try
[wallets_exchange_chart]
with no arguments. This will load the dynamic template which refreshes via the JSON-API.(Don’t forget to add a
[wallets_exchange_market]
or[wallets_exchange_market template="dropdown"]
in the same page, so that a market is always selected.)with regards
alexgKeymasterHave you tried simply
[wallets_exchange_chart]
with no arguments? In my tests the chart adapts to the available width.alexgKeymasterHello,
Are you referring to the chart? (
wallets_exchange_chart]
shortcode)The chart is redrawn on window resize. From
wallets-exchange.js
:// resize all charts whenever window resizes $( window ).resize( function( e ) { $( '.dashed-slug-wallets-exchange.chart .chart-container').each( function( i, el ) { drawChart( el ); } ); } );
Not sure if this is what you mean?
alexgKeymasterHello,
Thank you for the interest in the exchange extension.
I see that the HTML output for the plugin’s UIs are minified/tidied. This is cool, but the plugin relies on HTML comments to function.
If you can, allow HTML comments in your minifier plugin. If there is no such option in the plugin, disable the minifier althogether and try again. If you are unsure which plugin does HTML minifying, try disabling other plugins until you find it.
There may be other issues with your site, or not, but this is definitely something that would cause issues.
The good news is that your JSON API is working fine.
Please let me know if you found how to not remove HTML comments from the output, and whether you encountered any other issues.
with regards
alexgKeymasterError on console:
Uncaught ReferenceError: Unable to process binding “css: function(){return {‘green-foreground’:percent_change_24 > 0,’red-foreground’:percent_change_24 < 0,’selected-market’:market == $root.selectedMarket(),’base-fiat’:base_fiat,’quote-fiat’:quote_fiat,’base-crypto’:base_crypto,’quote-crypto’:quote_crypto} }”
Message: percent_change_24 is not defined
at css (eval at parseBindingsString (knockout-latest.min.js:74), <anonymous>:3:83)
at update (knockout-latest.min.js:99)
at a.$.l (knockout-latest.min.js:79)
at Function.yd (knockout-latest.min.js:55)
at Function.zd (knockout-latest.min.js:55)
at Function.ha (knockout-latest.min.js:54)
at Object.a.o.a.$ (knockout-latest.min.js:52)
at knockout-latest.min.js:79
at Object.D (knockout-latest.min.js:11)
at p (knockout-latest.min.js:78) -
AuthorPosts