Yes, they very quietly merged in the changes that I made to fix the freezing.

I don't care at all about any personal recognition (I actually prefer to stay under the radar), but it might have been nice for them to recognize that this was a community effort. Really, what is a coin without building a community? My intention was to help the community around this coin by fixing the freezing.

I'm sorry, but I don't have a Mac to compile my modified non-freezing wallet for you. Maybe you could try using Wine to run the Windows wallet on your Mac?

Yes, that's what I was referring to above. I will probably take a look at that next to see what can be done there.

I noticed the devs have merged my code into their github repo, so it looks like the next official version of the wallet will probably have my changes included.

Here you go!

https://github.com/modzer0hax/CoinonatX/releases/download/2.0.3.3-modz1/CoinonatX-win32.zip

Guys,

I have completed my first modified version of the wallet without the freezing issue. I am NOT the dev of this coin, but this code is based on the dev's latest updated code. My modifications move the masternode list updating code off to another thread so it doesn't hang the GUI while updating. There are still a few other occasional freezes in the GUI (I've noticed especially when syncing for a while) - I may take a stab at those later. In this case, I was specifically targeting the freezing up for 20+ seconds every 30 seconds or so that made the wallet very frustrating to use.

Compiled Windows 64-bit wallet: https://github.com/modzer0hax/CoinonatX/releases/download/2.0.3.3-modz1/CoinonatX-win64.zip
Compiled Windows 32-bit wallet: https://github.com/modzer0hax/CoinonatX/releases/download/2.0.3.3-modz1/CoinonatX-win32.zip
Source on github: https://github.com/modzer0hax/CoinonatX

Disclaimer: I can assure you I've added no malicious code, but if you're worried about that then don't use this or review the source and compile it yourself. Make sure you have backups, etc. etc. and treat this as pre-release code. I'm not responsible if it ruins your wallet, corrupts your files, steals your wife, and all that.

I hope this will be helpful to someone.

Hi,

One of the changes made in several files:


to


has the potential to cause crashes, because now the pointer is uninitialized. An example of code that uses pfMissingInputs is AcceptableInputs() in main.cpp:


Since the value passed is uninitialized, it could contain a non-zero value, causing the above if statement to be true, which would result in dereferencing a bad pointer when trying to set it to false. This would cause the application to crash.

I understand why you changed from setting it to false, as that was incorrect too (it's a pointer, not a boolean). It should be initialized to NULL instead of leaving it uninitialized.

EDIT: I've compiled the Linux wallet myself and it consistently crashes with segfaults. Debugging shows it dies on line 768 of main.cpp, which is the code I mentioned above. This is a real problem; please don't leave pfMissingInputs uninitialized.

The freezing issue is related to updating the masternode list tab in the wallet GUI. The code that does this is in the same place as the code that draws the GUI, so the GUI freezes while the masternode list is updated. The Windows and Linux wallets use the same code, so they'll have the same problem. Other similar coins (such as Crave) do this as well, so I'm not sure why it's not a problem for them... the updating code is nearly identical, but it completes so much faster with those other coins that you don't notice any hangups in the GUI. There is some blockchain code involved in there, and it could be that the algorithm this coin is using is slower than other coins or not optimized. I gave up digging into that part of it since I just don't have enough knowledge in that area.

I played around with moving that code off to a separate thread so it's not mixed with the GUI code. I had some success - the GUI no longer hangs up. There are still a few issues though, and I haven't had time to get back to the code to finish it up, as I've been busy with other coins and life in general. I hope to get back to it soon, because I'd like to see this stupid problem fixed as well.

Anyone wanting to run a masternode is better off using the command line coinonatxd. I do this on Linux and it works fine, although the rewards aren't great at all, as others have noted.

I'm not a dev of this coin or associated with them in any way... just a programmer who decided to take a look into things since the devs haven't.

Always interested in a new masternode coin. I'd be up for running a node if I can get enough coins.

Got my airdrop! Thanks!!

Thanks for letting us know. And, even though I wasn't able to get in on this, thank you for providing this service to the community.

I have also taken a look at the code myself over the last few days. The lag is caused by the list of masternodes being updated on the UI thread, so the UI freezes until the update is complete. It's very poor design to have long-running operations like that on the UI thread for this exact reason. I removed the lag completely by removing the calculation of the masternode rank in the list. But then, of course, there's no rank listed.

My real problem with fixing this properly is that I've compared the CoinonatX code extensively to other code based on the same original code. Crave, for example. All the masternode update code is nearly identical, and the updates also happen on the UI thread in Crave. But for some reason I haven't been able to trace yet, the Crave code completes much faster so there's no noticeable lag in the UI (it's still poor design).

I may work on moving the masternode list update code off the UI thread if the devs don't show some sign of caring about the wallet soon. I have a little money invested in this coin, so I'm motivated to do what I can for the project before the price drops completely to zero.

Hi guys,

Wallet issues aside, is anyone having trouble getting masternode payments? I'm running a masternode on a Linux VPS and as you can see here, I've only gotten one little payment of about 2.74 XCXT.

I was running a previous masternode, but forgot and left staking on in my Windows wallet, which stopped the masternode when it started staking and no longer had collateral (I assume). I just deleted the masternode, created a new one and set things up from scratch on the VPS. I don't see how that could have an effect on payments now, but I was getting a few more regular payments on that first attempt.

Thanks in advance to anyone with any ideas.

I would like 1 seat please.


BTC address (quoted https://bitcointalk.org/index.php?topic=996318.msg23524782#msg23524782):

Also signed with my VIVO receiving address for good measure:

Thank you.

I can confirm that VMware (ESXi and Workstation) and VirtualBox both expose AES-NI to the guest, as I mine XMR in VMs under both of those using xmr-stak-cpu in Linux guests.

annual 5% ... means per year. That's about 0.014% paid daily.

lol $500 for a graphics card
lol $3000 for a mining rig
lol $2500 for bitcoin, a completely virtual thing
lol $any_price for any_thing

See how silly and valueless your comment looks now?

You need 2.2, the latest development version. I'm running it on Ubuntu and it works fine. https://github.com/tpruvot/ccminer

Yes. I've been mining it in Linux with both AMD and Nvidia cards, using sgminer and ccminer.

sgminer sources with skunk algo: https://github.com/signatumd/gpuminer-source
ccminer sources with skunk algo: https://github.com/tpruvot/ccminer

ccminer source, now with skunk algo: https://github.com/tpruvot/ccminer/
I compiled it myself on Linux and have been mining with it.