And they've now quietly changed that to:

RAID only protects against drive failure, if the database was deleted from the server then it would have been deleted from all drives at the same time. If this was a dedicated server (rather than a virtual server) then the correct course would have been to switch the server off immediately upon discovering the deletion so that there was a chance of data recovery, but then switching off the server would also be the correct way forward upon detecting the hack as well.

From reading the various things said by the team I think these were a set of virtual servers probably on a shared provider (a mistake), what backups they might have had were minimal (a mistake), credentials seem to have been managed poorly (a mistake) the hack wasn't dealt with very well (a mistake).

Whilst I don't see enough evidence to call it an exit scam, there seems to be plenty of evidence of incompetence in how things were run and have been handled (why no announcement on twitter).

If things were setup correctly the hackers would have been unable to delete the backups and there would be a full audit trail on a separate server that couldn't have been altered, both simple things to achieve, both things that seem to be lacking.

So to summarise:

After many hours last week of one to one help trying to get the wallet running on your chosen platform during which you ignored what you were being asked to do several times you then state there's a glitch in the EverGreenCoin wallet which means you can't resize the window, an issue that no one else has seen. I suspect that this is probably more an issue with your laptop (I suspect your laptop is in reality a netbook which tend to have limited screen resolutions).

After being asked a few questions you decide to rage quit stating saying you've been attacked. I see no such attack just a few questions trying to clarify where the issue might lie. There could have been some frustration about the way you stated there was a bug and the little information you provided about it and maybe some of the questions could have been worded a bit better better but I don't see anything insulting. There are many places an issue like that might be and from what else has been said I think the issue is more in your choice of hardware than anything else.

Your posts last night where you suggest there's another bug is similar. The only detail you appear to have provided is a single poor screenshot with a caption from you saying "it does not respond". There's no detail of what your trying to do and nothing about the system it's running on.

Reading through the last weeks worth of telegram and discord chat is seems your mostly interested in hype and raising the price rather than any of the goals EverGreenCoin actually has. Other than a possible minimal donation to the tree planting efforts I don't see that you've given anything back to the community (you've even been suggested how to find out what you could do to help). Given the amount of time you've taken from various members of the community the only person who appears to have been offensive to anyone else is you (I'm not going to repeat what could be considered verbal abuse and/or name calling).

Anyway the whole history of what's happened in the last 10 days is available for anyone to see on telegram and discord and they can make their own minds up. Personally I think the community generally come over as trying their best to help you and the only person who comes off looking bad is you!

There was some discussion of this a few months ago (around page 40-42) which included links to what I've done so far on the wiki - The software page I linked to initially are still valid although I've started re-organising some of it so other pages might not exist.

You, or anyone else is welcome to contribute to that documentation or even contribute fixes or a .spec file to the main github (I know Steven is generally happy to receive pull requests).

In the case of Fedora 28 I know Steven spent a lot of time with matteo96 a few days ago trying to get it working finally with success, it looks like the latest boost libraries broke something so this will likely also affect Ubuntu and then Debian at some point in the future (I think there are now some patches in the tree to fix that although I've not looked at that in detail).

In terms of discussion of the codebase, most of that happens on Discord

Currently for a small number of users (I'm a Fedora user as well) it's not really worth building packages for Linux Platforms (particularly as there's such a large variety if we were to also try and do package builds for Ubuntu/Debian/Raspbian etc. Linux Packages are something I'd like to do at some point (RPM and DEB) but there are other things that are more important first.

I've taken the original wiki documentation we had for building the command line version on a variety of Linuxes (include Fedora27) and (hopefully) made it easier to read as well as updating it for different versions of the code (currently tested 1.7.3 and 1.8 QT and Command line on Fedora 27).

It looks like there might be a couple of other bits to add for Fedora 28 (seeing the discussion last night) which I'll work on and try and integrate into that documentation, (un)fortunately Fedora tends to be very close to the bleeding edge (but usually well tested) so we see the issues of updated packages before they make it through to the Debian and Ubuntu world.

The updated wiki page with all this is on https://wiki.evergreencoin.org/wiki/Software/Fedora

Yes, but that's not necessarily a bad thing. I'm sure I read a great article about it a few months ago but I'm not sure where (and don't think I bookmarked it).

The real issue is if the inflation/growth is too high (as is the case with a few cryptos - there are a few at 100% or more), new coins will devalue the existing coins and only encourages people to hoard coins. If your not staking them your coins will effectively decrease in value.

With EverGreenCoin the rate of growth is relatively low (currently maximum of 7% but as already mentioned it's going to be lower overall). At a rate like that the value of each individual coin shouldn't be affected by new coins being created because the new coins created a day is relatively low.

To add to that, from the discord discussion there might be other locations as well so when we get to the 3rd, 4th etc. wells India and Bangladesh aren't the only options.

However I think India for the 2nd well works well with the reasons Steven as laid out above.

Do you have a note of what the block height reached in this was and what versions of wallet and libraries you used to create it ?

I've been attempting to use this for the Stake Boxes Image and keep getting stuck - that might help in tracking down where the issue is.

We now have a mostly complete Raspberry Pi image for the Stake Boxes.

This is based on the most recent Raspbian Lite image and includes wallet version v1.7.3.1.

I've got a test image available for anyone that wants to test and feed back how well it works (or doesn't). Hopefully we'll have a fully tested release available soon.

If you're interested in testing then I'd highly recommend joining us on discord and in particular the #solar-staker channel.

Ok so there might be some truth in that... although my experience is different.

At the moment I'm only trying to build the command line version (evergreencoind). I'll probably try QT on Fedora first and see how that goes.

OpenSSL hasn't been an issue, on newer distributions there are issues where they bundle openssl 1.1, but these distributions mostly have the 1.0 headers as well in a different package.

So far with a minor change to the current makefile.unix and a static libdb4.8 (to be compatible with Mac/Windows wallets) I can get an evergreencoind that works. Building like this does result in a set of extra warnings like:

This is because I removed -std=c++14 from xCXXFLAGS (the change to makefile.unix) mentioned above as the bundled gcc4.8.5 is too old to support the C++14 standard.

The alternative is to install a newer G++ (easy to do using the Software Collections), however this leads to a conflict with the bundled boost libraries due to the different C++ standards.

Most of my build process is on the wiki starting from https://wiki.evergreencoin.org/wiki/Software#Building

Now to finish tidying the wiki with what's been tested and what works (or not) and think about QT.

I've not tried the QT wallet on Fedora 27 x64, but didn't have many problems with the daemon. There was one thing the broke the build where Fedora was on a newer library than Ubuntu/Debian but that only needed a simple fix we've now added to the code base.

I'm planning to have a go on CentOS and also building the QT wallet on both CentOS and Fedora over the next few days. I also want to look at sorting out some of the wiki pages about building the different variations.

If you were coping the old binaries over then that's liable to fail as you're unlikely to find the right compatible libraries (windows tends to keep every possible library version around now which is partly why it grows so huge).


If it worked on mint, then it should have worked as easily on Ubuntu or Debian. Without knowing what errors you had on CentOS/Fedora it's hard to suggest what the issue might have been, this also means if there's an issue in the code or instructions then it's not going to get fixed.

Providing some useful error messages etc could have meant you could have got help and you would have helped the community with potential fixes. From me building the daemon on fedora (which tends to be ahead on package versions than debian and its derivatives) we've already found one patch for the code which will benefit debian/ubuntu/mint at some point in the future when they update their package versions.

The binaries inside the container are still architecture specific so would need rebuilding, however if you choose the right base it shouldn't be hard to rebuild for a new platform. I started doing some of this looking at how to distribute the solar staker web interface.

You would need to rebuild stuff between the VM and Pi's as they're different CPU architectures (so binaries from one won't run on the other). If you've got the build rules setup though it shouldn't be hard to rebuild on the Pi once you've got something that works.

For a similar operating system it might make slightly more sense to use a Debian VM rather than Ubuntu if you're targeting Raspbian, although the differences are probably minimal

For the lottery setup I'd be somewhat concerned if it's running a desktop based setup with desktop apps - that just increases the attack vectors for the system. Having managed a few internet accessible systems over the years (web servers and others) and also having dealt with various compromised systems (usually not ones I've setup) I know the importance of securing things.

Certainly for the wallet daemon Fedora and Ubuntu should just work (I've even run it on some more esoteric setups) and there are some notes on the Wiki (Some bits need moving around so I'll link directly later).

I've not tried the QT wallet (the command line daemon works well enough for most of my needs) but I'd have thought it should build relatively easily on most systems. If you're having issues then it would make sense to provide the errors and ask for help either here or on Discord. If you've got useful build notes then it might help to add them on the wiki.

One of my longer term goals is to build various packages for installing the EGC daemon and QT wallet. Initially as a way of supporting the solar stake boxes but also for deployment to my own systems. I'm also aware that targetting flatpak might be useful as that could cover distribution of the QT wallet to a variety of desktop based systems.

(stripped all except a couple of packages for brevity)

The 1.53 versions look to be installed from CentOS, the others have come from somewhere else.


That may just be a case of needing the relevant -devel libraries. I've only build the deamon portion on Debian/Ubuntu/Fedora, I've not tried CentOS but it should probably work.

The assumption is that this is what's running the lottery as that seems to be down.



Depending on what this system is doing then I'd potentially suggest not running a gui/Desktop based system. If it's accessible over the internet as webserver / minecraft server etc. then adding a gui adds a lot of extra potential exploit routes you need to ensure is protected.

Personally depending on use I'd look at one of Fedora/CentOS/Ubuntu/Debian.

Shows as clean for me (just downloaded from the EGC site) and tested.
https://www.virustotal.com/#/file/60b61b5ee7c2694fdf7ca0172892e99af3b1c564baf8535aa433aa82ff43f4f5/detection

The 64Bit version shows a couple of "not-a-virus:RiskTool.Win32.BitCoinMiner.iqux" but considering the wallet has some mining logic built in that's not exactly an issue.
https://www.virustotal.com/#/file/a7417af6bfb3437af807b9825f9a05b74601126791c53b6607ebfa2f937894cd/detection

if it's headless why build the QT version of EGC, the daemon form might be more useful and has fewer dependencies.

why didn't you use the system libraries, if you built the libraries from source then that could easily be your issue.


rpm -qa and grep can show you the installed packages, ldd might show what libraries you're linking against. Having EGC looking for boost 1.57 suggests something odd in your setup as that's not the version bundled in CentOS. If you're running a website this is probably stuff you should know...

What OS is running on that system. Use of yum makes it look like an older Fedora/RHEL based system.

That error makes it look like either a significant update to the boost libraries happened or they got removed. Maybe try looking to see what boost packages are currently installed.

Regardless of the intention I'm not sure that this type of post is good, particularly from the person that's supposed to be running a fair and impartial lottery.

If you're looking up the balances of those entering the lottery that starts to cast doubt on it's fairness and impartiality. Whilst I doubt you're using that information to fix the lottery outcome when operating a competition like this any doubt from players and/or the authorities could cause you serious harm.

A second issue with trying to make assumptions based on the rich list is there's not necessarily a correlation between wallets and people. My own stash of EGC is currently split between 4 wallets, two of which I don't have any control over. If I sent coins from one of those wallets (an Exchange) then it might appear that I have a huge bag of EGC (certainly in the top 100 if not the top 10) even though the coins I personally control is a vastly smaller number (well under 1% of that particular address).