Jojatekok, thanks, very good client  let me ask - Russian translation is possible? i can help if you want to do it  Every language is possible with the help of the community  Just visit https://www.transifex.com/organization/jojatekok/dashboard/monero-client, register, and then click on the green 'Translate' button! The next release will be localization-related too, keep watching for it!  |
|
|
|
nope  I try many times - no trasfer/transaction Hmmmm, interesting... Could you please try again and then send me the log of the daemon and the wallet in PM by copying them from (Menu) -> Help -> Debug window -> Consoles? (If you are paranoid about your wallet's data like TX IDs, then replace long (at least 50 character) strings with "[hidden]".)I have a working version of Monero Client implementing RPC support for the wallet as a test, but simplewallet.exe's JSON RPC does not support all the features (for example, payment IDs, which are extremely important) that the terminal do. I would like to ask the wallet developers to find a solution for this ASAP: The daemon supports running the RPC simultaneously with the console, but the wallet does not. Thank You!  payment id is implemented in rpc. i have it working in alpha kivy gui wallet... You're totally right, I was a bit tired at the time of writing that post. I meant deterministic wallets for example |
|
|
|
nope I try many times - no trasfer/transaction Hmmmm, interesting... Could you please try again and then send me the log of the daemon and the wallet in PM by copying them from (Menu) -> Help -> Debug window -> Consoles? (If you are paranoid about your wallet's data like TX IDs, then replace long (at least 50 character) strings with "[hidden]".)I have a working version of Monero Client implementing RPC support for the wallet as a test, but simplewallet.exe's JSON RPC does not support all the features (for example, payment IDs, which are extremely important) that the terminal do. I would like to ask the wallet developers to find a solution for this ASAP: The daemon supports running the RPC simultaneously with the console, but the wallet does not. Thank You! |
|
|
|
can't trasfer xmr with this client:
I set address, amount, payment ID, mix_count=0
push "Send" and nothing...
Actually, it should work except in very few cases (it doesn't show any message after clicking the Send button, but clears the list of recipients). One of those is the daemon being busy (for example, while saving the blockchain). With the wallet RPC that is going to be used in the future (but it isn't good enough to use yet), I will be able to detect failed transfers. In the current version (v0.23.0), the transaction history is not shown due to a bug which is going to be fixed with several other issues discovered during a massive code inspection. Please use v0.22.0 if the lack of TX history annoys you. I am working hard to resolve all the issues as soon as possible, and will continue to implement features too. I downloaded new client 0.24.0 but I have same situation - exactly as you sad - it doesn't show any message after clicking the Send button, but clears the address and amount fields, only payment ID shows up. If I do transfer from command line without your client (just from Resources folder) - all is good, and then I can see that transaction in 0.24.0 Thank you for your work! Not showing a message after sending a transaction is not a bug. It works just flawlessly then (see your transaction history ). Those kind of notifications are still yet to be implemented, but currently, I'm working on an improvement for process handling. |
|
|
|
Monero Client v0.24.0 has been released!https://github.com/Jojatekok/monero-client/releasesWith numerous bug fixes and performance tweaks, this release of the Client is very special. It should fix most of the bugs which may occur with previous versions. Also, new translations are added: Thank You for everyone participating in the localization project! Shortly, here is what to expect from v0.24.0: - Fixed the Transactions tab
- Fixed the weird scroll behavior of the Send coins tab
- Fixed a crash which occured when double-clicking a contact in the Address book
- Improved the management of processes
- And many other improvements including UI fine-tuning
I had literally checked every single line of code, and fixed the errors I noticed. The only remaining bug should be the stop of simplewallet after a new wallet's creation (although the generating algorithm still works, the Client has to be restarted straight after it).
|
|
|
|
can't trasfer xmr with this client:
I set address, amount, payment ID, mix_count=0
push "Send" and nothing...
Actually, it should work except in very few cases (it doesn't show any message after clicking the Send button, but clears the list of recipients). One of those is the daemon being busy (for example, while saving the blockchain). With the wallet RPC that is going to be used in the future (but it isn't good enough to use yet), I will be able to detect failed transfers. In the current version (v0.23.0), the transaction history is not shown due to a bug which is going to be fixed with several other issues discovered during a massive code inspection. Please use v0.22.0 if the lack of TX history annoys you. I am working hard to resolve all the issues as soon as possible, and will continue to implement features too. |
|
|
|
The code inspection I mentioned has really been necessary: I have fixed numerous bugs (including the one spotted in v0.23.0 which made the transaction history empty), and improved the performance of the application, making it ready for more exciting features to be added. Is there an advantage to having 64K connections? or would it be better to stop making connections at a hard coded number. maybe overhead resources are small so an extra few thousand connections it not a problem.
BTW it password protection is working for me and I can use the client now.
Thank you also for doing the code audit. making sure it's clean now is a very good idea and should make troubleshooting later easier.
We need to limit max connections in the daemon in future versions, the daemon is very promiscuous and bandwidth intensive unfortunately. Yeah, limiting the amount of connections is the job of bitmonerod's developers. (I would suggest a limit of 64 ingoing + 64 outgoing connections.)Could you please update us about the bounty's exact deadline (not just only a day, but GMT/UTC hour), and tell us how will the entries be rated? EDIT #1: After the code audit, Monero Client will also consume less RAM EDIT #2: Little features like these may come with the next release  |
|
|
|
EDIT #2: A new release (v0.23.0) is out, and can be directly downloaded for Windows x64 from here. Great work, though I ran into this and I don't know how could I limit the number of connections:  Whoa, that's very interesting! I never expected that the number of connections would reach 256 or more, which is the limit of the numeric type I store them in (byte). I will raise the maximum to ushort then, which allows 65535 connections to be handled. As I have already stated before, feature development is going to be paused as long as I perform an audit on the current codebase. I have already fixed some things which no one has ever noticed before. |
|
|
|
thanks  also someone have "bitmonero-qt" binary for windows? i need it qt better than dotnet By today's measures of performance and compatibility, Qt is unquestionably better than the Microsoft .NET Framework. But on the other side, the .NET client has been coded from scratch, considering every factor which matters in order to function properly without any freezes. (I have not yet seen a Qt-based wallet which did not have hang-ups.) The code backend which Qt uses is far more difficult to understand and use than C#'s. If someone ever had an experience with C++ (I did), they know that even creating a new window can be a pain. In .NET, this process is far more efficient. On today's PCs (and I'm not talking about a supersonic gamer rig), the performance loss of 2D applications in C# is negligible. Also, WPF introduced the use of DirectX which makes your graphics card accelerate the rendering of the application (Qt doesn't have that). In conclusion, applications coded in WPF will get faster and faster eventually by time. (You can even start thinking about the pros of DirectX 12, including the performance boost which AMD's Mantle promised before.)About the compatibility, the drawback is that only WinForms applications can be ported to Linux and Mac OS X. But not in the future! C# is a young language compared to other C-derivatives. Microsoft had announced in april that they are working on .NET Native which may provide performance close to C++ applications, but with the ultimate feature set and extensibility of C#. It may also mean a step to multiplatform applications too. EDIT #1: Progress report (without comments):   EDIT #2: A new release (v0.23.0) is out, and can be directly downloaded for Windows x64 from here. As there were a lot of new features added in the past few days, I decided that the next step should be an audit on the code I wrote. This can take sereval hours, and I also need to take breaks before doing it. An audit like this can be considered as a long-term "investment": it may not seem necessary for the users, but it's critical for development. I have opened translations for anyone who wants to help contributing to the project. If your language is not yet available, but You want it to be implemented, then don't hesitate to notify me here or in PM. |
|
|
|
My current wallet is password protected. is there a way to unprotect it so I can try the moneroclient GUI?
I don't want to use a new wallet as I'm mining on address in my current wallet.
I haven't heard about a way of unprotecting Monero wallets yet (although, this will need further investigation). Today, I started implementing support for passphrases, so You will be able to use my Client soon. |
|
|
|
Jojatekok,
Looking good… I tested the following.
Generated address looks as it should in the GUI. It copies to clipboard with no issues and the QR code also scans showing the correct address. The save as function also works fine.
I tested with a few coins and sent 1 to bittrex using payment ID and sent one back to my other wallet. I also did this with a fully synced blockchain.
The first attempt sending to the exchange with payment ID failed and in the logs it just said daemon was busy. I waited about 10 minutes and it didn’t seem to attempt a resend so I tried again and it worked fine. I noticed that if you watch the wallet log there will be times where it will come back as daemon busy when it tries to refresh.
If possible you might want to make any errors like that popup in a window if it occurs during a send or is it supposed to attempt a resend? Likewise a popup for a successful send would be informative as well. The format of the send with payment id in the logs looked fine. It’s just the daemon was busy.
I was going to test the multiple recipient feature but noticed there was only one entry for the payment ID option. Since I was sending to the exchange (needed payment id) and to my other wallet I wasn’t sure which recipient the ID would be used for. I would assume it would be the first but didn’t want to take a chance. So basically I figure you would want each recipient to have it’s own payment ID field instead of just one at the bottom?
When the refresh runs successfully the GUI does update the wallet amount and the transactions correctly.
I also like the fact that we can specify locations for the resources. By default I was able to load this onto a USB stick and run it with no issues. The wallet saved on the USB in the directory it was supposed to. Now maybe in the future an option could be added to direct the location of the blockchain to USB? Not sure if it’s possible, the daemon itself would need to support that correct?
Keep up the great work. I’ll definitely keep providing feedback on it.
Everything you have mentioned above is already planned, and even the relocation of the blockchain is possible (if I recall correctly). The lack of support for multiple payment IDs is because of how simplewallet.exe takes arguments (transactions with different payment IDs must be sent separately by the current state). The most important thing to implement now is the ability to protect wallets by custom passwords. Thank you again for the review, I'll try to keep everyone up to date with my updates. EDIT: I have just spotted a bug which occurs when the wallet file is placed in the same directory as the Client. It has already been fixed, and will be available in the next release. |
|
|
|
Yeah no problem. The good news is that using the correctly formatted address from the log worked. I had sent a small amount from a different wallet and received it no problem. Went from unconfirmed to confirmed with no issues that I could see. I'll be sure to post more if I find anything.
I have fixed the bug, and made sure that this cannot happen in the future: All the outputs which contain strings are now parsed by a case-ignorant RegEx, thus, the original casing is maintained for every string. EDIT:A new mandatory update for Monero Client is available!(You can download it here ) Until the x86 versions of bitmonerod and simplewallet are not fixed, I will not provide separate packages for them. Anyway, the Client itself does not even differ by platform, only the software resources do. |
|
|
|
Jojatekok,
I starting testing receiving and sending with a small amount. Here's something funky I'm seeing. I tried to do a test send to the wallet that was generated by the gui wallet. There seems to be an issue with the way the address is shown through the GUI. Below is an example. Notice the difference compared to the address in the logs. Anyways I was getting an invalid address when trying to send to the wallet until I realized and just pulled it from the log.
Address copied from GUI: 42bjjr1ncvcge6pkn7fhzysmuydvlwxt2luxoswuajdbcfheil1bntszhy3kehecbzy9ypb8m4vqevm msjgqvwsa3jnvjdl (Invalid when sending to address)
Address copied from Log: 42BJJR1ncVCGe6pkn7FhzYSmuyDVLwXt2LuXoSwuAjdBcFheiL1BNtsZHy3KEHecBZY9YPb8M4VQEVM MsjgqVWsA3jNVJdL (Valid when sending to address)
It just looks like when viewed in the gui there are no caps in the address like in the log.
I tried sending to the address I pulled from the log and was able to successfully send to the GUI and have it show up.
YIKES! That's a huge fault I made, and I am very sorry about it. This post is being written from a mobile, but I know exactly what the cause of the bug is: my process wrapper of simplewallet still doesn't use the RPC client, thus, it reads outputs from the command line. The catch about this is that is that the output gets converted to lowercase before being passed to the filters which detect types of operations. I forgot to use the normal-cased string as an output after filtering... (Shame on me for testing only the sending of coins without ensuring the reliability of the receive address's validity )I am very greatful about the community helping the development by submitting these kind of bug reports and translations. I'll try to issue a new release ASAP (tomorrow?) with this urgent fix implemented, along with support for QR codes, and multiple recipient support for sending coins. As it had been mentioned above, the stability of GUI wallets can only be as good as bitmonerod's and simplewallet's. I am aiming for perfection with Monero Client, so if anyone encounters even the littlest annoyance, please report it to me! |
|
|
|
I tried out the x64 version and have to say you have done a great job on this. The only thing that isn't working for me is the "Encrypt Wallet" option. I click on it and nothing happens. I tried to load my already existing "mining" wallet and it wouldn't load since it was already password protected. The log just said wrong password. Do you have any plans on making it so the GUI will ask for a password for an already protected wallet that's being loaded? Thank You for the report! That's not a bug, but a yet-to-be-implemented feature. As a compensation, here is a teaser shot of an other upcoming feature:  I know that it doesn't look perfect, but there is reason that I haven't released it yet |
|
|
|
I have been working very hard in the past days in order to make everything ready for the first test version of the WPF Monero Client to be deployed for the public. The next few releases will not have a changelog, as I will focus on the development instead. (Commits tell about most of the changes anyway.) I am proudly announcing that the application is now ready for testing. Please report any bugs or annoyances you occur, so I can fix them ASAP. Here is the link for the downloads:https://github.com/Jojatekok/monero-client/releasesI noticed that the x86 version of bitmonerod.exe is buggy for me, so I recommend everyone to use the x64 architecture if possible. Please note that the slow shutdown is due to saving the blockchain and wallet data. The option for disabling these steps will be implemented in the near future, as all the data are saved every 2nd minute.Translators are still needed in order to reach everyone in the world with Monero's innovations. PM me for more details if You are interested! nice work.. the win64 build stops after a few seconds tough - just tell me if you need any logs. what i dont like: monerod has a very nice rpc-wallet interface. even bitcoin tries to seperate wallet and daemon: why did you take the other direction? Well, the x64 crash after a few seconds is weird. I would happily see some logs to analyze the problem. I have not chosen not to implement the RPC for the wallet, but have not started implementing it yet. Currently, I am adding support for generating QR codes, then I'll be insanely busy adding miner support. As I have already mentioned, there are a lot of features to add, including many which are not even mentioned as ideas for Bitcoin Core. Stay tuned for more updates!  |
|
|
|
I have been working very hard in the past days in order to make everything ready for the first test version of the WPF Monero Client to be deployed for the public. The next few releases will not have a changelog, as I will focus on the development instead. (Commits tell about most of the changes anyway.) I am proudly announcing that the application is now ready for testing. Please report any bugs or annoyances you occur, so I can fix them ASAP. Here is the link for the downloads:https://github.com/Jojatekok/monero-client/releasesI noticed that the x86 version of bitmonerod.exe is buggy for me, so I recommend everyone to use the x64 architecture if possible. Please note that the slow shutdown is due to saving the blockchain and wallet data. The option for disabling these steps will be implemented in the near future, as all the data are saved every 2nd minute.Translators are still needed in order to reach everyone in the world with Monero's innovations. PM me for more details if You are interested! |
|
|
|
Hooray! The time has come again to announce something which is worth to mention Today, I am happily introducing the use of job objects in Monero Client. This means that on a sudden crash of the Client which makes the main process killed terminates the subprocesses, including bitmonerod.exe and simplewallet.exe. TL;DR: No more ghost processes wooooohoo! |
|
|
|
I am looking for people who are willing to translate the WPF Client for the currency of future! The time has finally come for this announcement, as the core functions of my GUI implementation are already working flawlessly. Luckily, anyone can translate the project easily through the web without any kind of knowledge related to programming. You will need to register first, and then request a translation of the desired language. https://www.transifex.com/projects/p/monero-client/resource/resources-resx/Thank You for your contribution! |
|
|
|
As I have promised before, here are some teasers from the upcoming 'Options' feature: A lot more interesting features are on the whitepaper (which is only existent in my head) already, and I will keep some of them as a secret until their deployment. The RPC API's functions should really be improved though, as I will not be able to step further in stability and reliability whether the condition of reducing the amount of those BUSY messages isn't met: We need functionality without syncing the entire blockchain!Remember: None of the altcoins' GUI wallets will ever be as featureful as Monero's Looking sharp! Keep up the fine work. No rush, would prefer a well-built GUI in the next months to a rushed, potentially XMR damaging piece of software tomorrow. Really does look good. Thank You! By the way, your comment is very ironic, because I've randomly encountered a black cat on the street today, on the 13th of Friday  (As you can see, I'm not a photographer, but my excuse could be rushing home to improve Monero Client ) |
|
|
|
|
Show Posts
