This is fucking awesome... NOT A SINGLE SOUL asked how to change the password. Any help please?
Currently, it's not possible (from the core assemblies of Monero) to change the password of accounts. |
|
|
|
It seems that we're currently experiencing an exponential growth right now... There may be good news on the horizon!  |
|
|
|
I've started to work on a cross-platform GUI about a month ago. This task involves code rewriting from scratch, thus, improving the performance and reliability of my client. More information coming soon...  |
|
|
|
|
Greetings everyone!
I'm delighted to announce that I've been working on a cross-platform GUI in the past few weeks. Hopefully, I can complete the feature set as soon as possible, and release a new client which is written from scratch.
|
|
|
|
One other thought: Is there some way we can come up with to *manually* initialize account.bin, maybe without having to go through the GUI? Essentially, we need to break the problem into parts to narrow down the issue and find a solution. Is there some sort of simplified script that we can come up with to reproduce the issue that we can present to the devs?
I think that the problem is probably with the initial accout file syncing. If you don't sync - and then save - your account straight after its creation, it gets corrupted (if I recall correctly). |
|
|
|
|
I've just encountered the bug you've been experiencing: It's happening when sending the RPC command transfer_split to simplewallet. I'm almost sure now that it's a core bug, and cannot be fixed by altering Monero API .NET. Smaller transactions work fine, but larger quantities simply cannot be sent (this is probably due to the automatic TX fee implementation).
EDIT: In console mode, it turns out that simplewallet loses the connection with the remote daemon in some minutes...
|
|
|
|
I haven't been able to reproduce the freezing issue yet in the Debug build, but I've noticed a new issue.
I created a brand new account on a new machine with Monero Client .NET to test transfers. I immediately set it to connect with node.moneroclub.com, and restarted the client. The problem is, the account would then remain stuck initializing *forever*, even though it was connected to and up to date with node.moneroclub.com.
So, I tried moving this new account file back to my regular machine, and the exact same thing happened. My old account would load just fine with node.moneroclub.com, but the new account file would not initialize.
Next, I tried running the daemon locally with the new account file, downloading the remaining blocks of the blockchain, and then it *did* initialize the wallet.
Afterthat, subsequent loading of the new account file with node.moneroclub.com would *then* initialize just fine.
Is there something stored in AccountData that requires loading the entire blockchain *locally* first before it will initialize properly with a remote daemon?
No, there isn't, at all. Thank You for reporting, I've also encountered this issue - for the first time - 2 days ago. I haven't inspected the source of the bug yet, as I have many more tasks to cope with regarding the client (which may take a few weeks). I think that this may be the simplewallet application's failure, but I wouldn't really like to blame it until we are completely sure about it... |
|
|
|
lol, I did. Btw, what are you using to compile this? If it can be done in Visual Studio Express 2013 for Desktop, I can help you debug the freezing issue with the current code.
I use VS 2013 Ultimate, but you may also use the Express version, just be sure to add NuGet references manually! (See the project's packages.config file)FYI, When I first open up the solution from scratch, NuGet actually prompts me to restore the missing packages from my online package sources. Once those are downloaded, it compiles. After copying over the Resources folder from a working copy over to the debug directory, it just works TM. That was easy. I'll try sending some moneroj to myself, and see if I can reproduce the freezing. Thanks for your effort, I hope that you can sort out the problem soon enough. Good luck! |
|
|
|
lol, I did. Btw, what are you using to compile this? If it can be done in Visual Studio Express 2013 for Desktop, I can help you debug the freezing issue with the current code.
I use VS 2013 Ultimate, but you may also use the Express version, just be sure to add NuGet references manually! (See the project's packages.config file) |
|
|
|
Are you sure it isn't something more closely associated with the GUI code itself, and how you have it parsing things, that is locking it up when clicking the send button? I actually didn't do enough sends in the previous versions to be able to tell -- I was just receiving the funds with the wallet and leaving the Moneroj there.
As I have already mentioned, I'm working on something quite big, and hope that it will fix your problem... (It's a long task to do, though... ) |
|
|
|
Thank you for adding the API specification, it will definitely be helpul for developers, and thus, for end-users. |
|
|
|
Update: I tested it running the daemon locally, sending you ~3 Moneroj at a mix in of 0, and it sent the first transaction. I tried sending you ~3 more, and it froze on this second transaction. This, along with my previous post, seems to rule out both a mix in issue, and any issue of using a remote daemon. What should we test next to figure out the true cause?
I've written a private message to you in order to let us discuss the issue in details. I've been working hard to analyze your case, but sadly, I could not find the cause of the issue. I used WireShark to analyze the packets sent by Monero Client v0.39.0-rc.3 vs v0.41.1: I can conclude that there was no significant change except adding the Accept-Encoding header, which - according to the core developers - does not affect the behavior of communication. Did you also experience the freezing RPC in older versions? P.S.: Right now, I'm working on a great code rewrite, which could take 2 months or 2 weeks (it all depends on my enthusiasm ). |
|
|
|
Update: I tested it running the daemon locally, sending you ~3 Moneroj at a mix in of 0, and it sent the first transaction. I tried sending you ~3 more, and it froze on this second transaction. This, along with my previous post, seems to rule out both a mix in issue, and any issue of using a remote daemon. What should we test next to figure out the true cause?
I've written a private message to you in order to let us discuss the issue in details. |
|
|
|
People, forget Darkcoin. I think this comparision is turning very annoying.
Monero has to care about more its own issues, like GUI wallet, SPV wallet (in my experience, it's impossible to run bitmonerod because it eats a lot of CPU and more than 2 GB of RAM), eventual CryptoNote issues, media attention, etc.
Wasting time with comparision against Darkcoin won't make Monero a success. No doubt Monero is one of the best coins launched in 2014. But fighting with Darkcoin right now is a bad idea, it will just expose Monero's currently weakness. What makes Monero a great is not comparisions, but its technology about privacy and its talented developers.
except that I'm running bitmonerod with 98 megs of RAM  I don't think anyone mentioned we should fight with Darkcoin. I just think we end up explaining the differences betwixt the coins. Just trying to syncronize...  You may want to try Monero Client .NET with a remote daemon Guide: https://bitcointalk.org/index.php?topic=683365.msg10418211#msg10418211 |
|
|
|
Wow, I just tested it, and I don't know how, but that *finally* solved the slow balance and transaction loading! It loads these almost immediately now!
However, it *doesn't* seem to have solved the freezing issue on the second transaction. I just tried sending you $3 worth of Moneroj, split into two transactions. The first one went through. The second one froze, exactly the same as before. I'll leave it open to see if it eventually crashes. Btw, I'm using a mix count of 1, if that matters.
Edit: I let it sit for almost two hours, and it never crashed, so I forced closed simplewallet, and that caused the GUI to crash.
Thanks for your feedback and donation! Today, I was working on the API more than on the GUI, and I have only tested TXes with a mix count of 0. As sending 0 mixin transactions consecutively worked fine for me, I suspect that the fault may be in the core application, or I just simply handle the mix count parameter wrong. I'll continue hunting for this bug tomorrow, and will also speak about the case to the core developers if necessary. |
|
|
|
Jojatekok, I'm now using http://node.moneroclub.com with port set to 8880, and it seems to be working. So, I thought I'd try sending you a tip. First shot, I accidentally tipped you around 4 cents worth of Moneroj, which did go through, though! So, I then tried to send you a little more, and, after clicking Send, the client locked up (but didn't crash), and the Send button became stuck, highlighted in blue, and the entire UI was unresponsive, but still would paint. Looking at the simplewallet log, the RPC outputs for both transactions were there, but the second transaction's outputs never concluded with "Transaction successfully sent" -- it seems to have just become stuck before that. I'm also not seeing any CPU activity from either simplewallet or MoneroClient. I may have to kill the processes manually, it seems. Edit: after waiting about 45 minutes, MoneroClient finally crashed with the following crash log: One or more errors occurred.
at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
at Jojatekok.MoneroAPI.RpcUtilities.RpcWebClient.PostString(String host, UInt16 port, String relativeUrl, String postData)
at Jojatekok.MoneroAPI.RpcUtilities.RpcWebClient.HttpPostData[T](String host, UInt16 port, String command, JsonRpcRequest jsonRpcRequest)
at Jojatekok.MoneroAPI.RpcManagers.BaseRpcManager.HttpPostData[T](String command, JsonRpcRequest jsonRpcRequest)
at Jojatekok.MoneroAPI.RpcManagers.DaemonRpcManager.QueryNetworkInformation()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireNextTimers()
Thank you very much for the support! I've just tried sending 3 transactions (2 with a payment ID, and one without any additional information) in a row from my client, and it seemed to be working perfectly: all of them have arrived. But after waiting for a little while, Visual Studio's debugger has notified me that the object responsible for storing the list of transactions was modified from a wrong thread (not the main one), thus, resulting in a crash. Shortly, this was just a side-effect of the migration to the separated API, but I've resolved it already. Other than that, your crash seems to be related to the RPC communication, as I've set network timeouts for RPC requests to infinite (in order not to experience crashes when trying to save the blockchain, as it takes more than 100 seconds to do so)... EDIT: v0.41.1 is out now, it should resolve some issues! |
|
|
|
Light wallet, with full functionality   Breaking news!(No, it's not yet another ordinary release ) has just been released! With the separation of my API and GUI integration of Monero Core's RPC functions, I was able to successfully distinct process and network communication management, thus, resulting in a long-anticipated feature added to the client. Let me present the changelog of today's new release: - Added a way to use remote processes: From now, you are not obeyed to host your own daemon instance, but can rely on an open node. This results in a much lower overall memory footprint on your system, thus, the application should cause no more losses in computing performance
How to use a remote daemon?
- First, you need to look for an open node which can be used as a reliable remote server (for example: node.moneroclub.com:8880)
- After that, open Monero Client .NET, and then select Settings -> Options -> Network from the menu
- Paste the information of the selected node as seen on the image below:
- Enabled the usage of proxies
- Balances in the 'Send coins' tab are now selectable
- Fixed a bug which prevented the account data files from saving
Please consider donating to one of the addresses in my signature if you like this update or want to support further development. |
|
|
|
Breaking news!(No, it's not yet another ordinary release ) Monero Client v0.41.0 has just been released! With the separation of my API and GUI integration of Monero Core's RPC functions, I was able to successfully distinct process and network communication management, thus, resulting in a long-anticipated feature added to the client. Let me present the changelog of today's new release: - Added a way to use remote processes: From now, you are not obeyed to host your own daemon instance, but can rely on an open node. This results in a much lower overall memory footprint on your system, thus, the application should cause no more losses in computing performance
How to use a remote daemon?
- First, you need to look for an open node which can be used as a reliable remote server (for example: node.moneroclub.com:8880)
- After that, open Monero Client .NET, and then select Settings -> Options -> Network from the menu
- Paste the information of the selected node as seen on the image below:
- Enabled the usage of proxies
- Balances in the 'Send coins' tab are now selectable
- Fixed a bug which prevented the account data files from saving
Please consider donating to one of the addresses in my signature if you like this update or want to support further development. |
|
|
|
I have begun coding a script (with database) that should include all basic functions required to accept monero (deposit/purchase,withdraw/transfer,check balance). While doing this I can also document the functions. I'm using the available pre-built libraries for development, it seems some parameters I need to make it scalable are currently not included in those, or maybe I'm missing something (asking on irc). Once these issues are resolved I'll continue development. To get an idea, this is what it looks like currently (and incomplete) Click here to view a demonstration image![/img]
Feel free to give suggestions.
Hi, I almost never post on this forum but I wanted to say that this effort is crucial and hugely appreciated, TheKoziTwo. As soon as this guide is published I think we'll see a significant increase in implementation, from shapeshifter.io to cryptsy to marketplace and auction sites to niche sites, etc etc. Since it seems you're coding an entire example application and waiting for ideal circumstances, I wonder if someone could offer an impromptu diy guide on how to communicate with the monero daemon from a server-side scripting language, the way it's currently done on Poloniex etc., for people like me (self-taught programmers, say, who don't want to wait on core development to get this economy started). It could be as simple as "google how to do this, this, and this, put them all together, oh, and I recommend this great book on best security practices while you're at it", or even "You idiot! Don't you know anything? Just put ____ in ____ and write a ____ script". That would be a starting point and I can find my way from there. Here is my perspective This project allows developers to flawalessly access the functionailty of Monero applications through the Core assemblies' RPC services. As the software is open-source, everyone can contribute, achieving the best performance and reliability for end-users. Why is this API necessary?It makes the implementation of Monero extremely easy for merchants, wallet builders, and all the other developers who are interested in working with (or accepting) Monero. Also, the core developers can concentrate more on the internals (instead of spending time on the official GUI client), which means that the currency should advance faster. Is it cross-platform?The first 3 releases of the API were only made for desktop PCs running Microsoft .NET Framework 4.5 or higher, thus, resulting in a smaller userbase than wanted. Since v3, the project has been split into 2 subprojects, one which is responsible for communicating with the daemon and the account manager's RPC channel, and one which can manage the required processes on PC. What kind of platforms can utilize the power of Monero API .NET, then?Basically every device which has support for running the Microsoft .NET Portable Framework v4, and more: Microsoft is planning to provide native (C++) compilation of C# assemblies very soon, and this process can be even faster since .NET Core has been made open-source. The project can run on PCs (Windows; Mac and Linux with Mono .NET), mobile phones (Windows Phone; Android and iOS with Xamarin), and even on video game consoles like Xbox. How does it work?As I have already mentioned above, the project consists of 2 parts: MoneroAPI, and MoneroAPI.Extensions. The first one is built as a PCL (portable class library) and is multiplatform, while the extensions are desktop-only and contain functions for hosting a full node. Basically, MoneroAPI is preferable for lightweight, client-only applications, and MoneroAPI.Extensions adds support for hosting the Monero Core processes with ease. There is a demo project included in the GitHub repository for a more technical explanation.
Please consider donating to one of the addresses in my signature if you like this project or want to support its development. |
|
|
|
|
Show Posts
![Click here to view a demonstration image![/img]Feel free to give suggestions.](https://i.imgur.com/1T9kDbo.png){kind=link}