this does NOT work in rhel based systems and rhela based vps systems and rhel based servers - for the reasons explained above 8bit ..
Bullshit.
the code itself is missing a few steps - such as zerocoin folder and an executable in the leveldb folder ...
Geez, chmod +x leveldb/build...
mkdir obj
?
Geez...
Are you here since yesterday?
for the average user - those steps just simply dont work ... dont believe me? ... setup a free tier server on aws ( amazon web services ) using rhel ( or even ubuntu ) and try ... it just wont work ...
Linux rule #1 - do not run untrusted binaries. You are not trusted binary provider and nooone sober will use your binary. Compilation is easy. If it is not easy for someone, there are hundreds of tutorials of classic coin compilation. MTR has no single new feature other than hundreds other coins. Don't give a ***, please.
some vps systems are 'basic' servers which have basic plans ... this means they are not only hdd space limited ( a simple 20GB space would suffice though ) - but also RAM limited ... most only have 2GB of RAM ... not enough to compile mtr or a number of other coins ... this results in a myriad of errors ( let alone g++ errors ) ... how are the average users supposed to know this? ...
512 MB is enough to compile MTR daemon. Even 128 MB with enough, however it will take ages and will require enabling swap (if possible, Digitalocean allows it) or tweaking ggc-min-expand and ggc-min-heapsize gcc options (you don't know them, do you?).
im actually quite interested to know what 8bit is all about ... will be reading up on the coin this week ...
I have already explained why putting more nodes will not make this network more secure against 51%, I am also pissed off of "dev" (not you) making of those nodes kinda project. This is so extremely unbelieveble... Me and I guess few other people have MTR deamons running of VPSes for many months and you guys show a complicated process of compiling it... RIDICULOUS.
first ...
bullshit? ... really? ...
its obvious you have NOT tried to compile in a redhat based environment ...
until you do - dont put down anyone that actually HAS done the work and KNOWS what these systems are and are not capable of ...
im adding this just for your information as to what happens when you compile ( after fixing all the other things you need to fix ) under centos 7 x64 ... the daemon gets compiled and when you execute it ( ./MasterTraderd ) - the result is ALWAYS this below - due to the missing secp256k cryptographic curve from the redhat openssl implementation ...
-------
************************
EXCEPTION: 9key_error
CKey::CKey() : EC_KEY_new_by_curve_name failed
MasterTrader in AppInit()
terminate called after throwing an instance of 'key_error'
what(): CKey::CKey() : EC_KEY_new_by_curve_name failed
Aborted
[root@test src]#
-------
second ...
you are missing the most crucial folder - its not JUST obj/ but obj/zerocoin/ ...
otherwise its just wasting your time trying to compile ...
hence the reason why i forked the original code (
https://github.com/chrysophylax69/MTR-Update/ ) which has all the broken 'bits' and i created my 'test' git (
https://github.com/chrysophylax69/mastertrader/ ) and 'fixed' and updated that repo instead ...
and if you mean was i born yesterday? ... no - of course not ... im a veteran in this industry mate ... and have no issue saying what i see also
...
third ...
i totally agree with you that you should NOT download and install / run untrusted binaries ...
so who is distributing any binaries? ...
as far as untrusted goes - i can assure you that my 'hero member' status here on bct is not a consequence of filling the threads with crap and trash - quite the opposite ... trust is built - and ANYONE that has had dealings with me directly can vouch for the trustworthiness of my dealings AND work ...
but once again - you are barking up the wrong tree again 8bit ... my 'work' has NOT been about how simple or not it is to compile ...
fourth ...
512MB MAY be enough IF you have a swap file active on a vps - which most DONT ...
a static build will only compile in a 4-8GB RAM environment - unless you have a decent swapfile ...
fifth ...
it is NOT about a 51% attack or anything of the like ... nor is it about how compilcated / difficult a node is or isnt able to be compiled ... nor is it about whether it was a project that mastertrader777 ( rich ) wanted to establish about setting up nodes or not ... you have got it ALL wrong 8bit ...
you seem to be running with the batton - but in the wrong direction ...
again 8bit - this is NOT about what can or cant be done - whether its tweaking heap size or not - and it certainly WASNT what i was working on ...
you are making it sound like its a straight compile that ANYONE can do ... that is most certainly NOT true ... this is NOT a straight compile from the MTR-Update as this git repo is BROKEN ... yes - i could have forked and fixed and made a pull request - but i didnt as i wanted to get the compile running under a SPECIFIC operating system AND under specific parameters ... but again - what you are arguing about is NOT what i was working on ...
even if the master code DID compile - it just will not work in centos - full stop! ...
the secp256k issue is WELL DOCUMENTED in bitcointalk - litecointalk - and REDHAT threads ... have a look ...
this is why redhat have only JUST implemented this ecc curve into the fedora 22 release - and ONLY from that release into fedora 23 ... none of the servers ( centos - scientific linux - or any other rhel distro ) have it currently implemented ... these distros can compile - but will NOT run any coin that relies on this specific ecc curve ... its that simple ... try compiling and running bitcoin on it with out the secp256k ecc implementation on a centos server ... you CANT ... unless there are very specific things you do and install as a prerequisite ...
hence what i WAS working on ... and the main reason WHY i created a static binary as opposed to a dynamic one ...
the binary is in use NOW - and when the granite instructions are complete - i will start work on the mastertrader instructions on how to compile a static binary ( conversion of a few things from the granite documentation ) - for those that WANT the instructions ... this is obviously not for everyone ...
this work that ive been doing is to SIMPLIFY the procedure for the EVERYDAY person - not the ones who already know how to - like you 8bit ...
how many EVERYDAY user knows how to setup a vps - with a swapfile - with the changes to the code - at the same time as solving the ecc issues for redhat vps systems - AND have it compiled - THEN run and create a conf file that WILL stake 24 /7 on the vps? ...
not many i will wager you ...
i find it increasingly presumptuous of you to think that the average user is that technically savvy that they can resolve compilation issues ... actually - that is really starting to amaze me ... i think you have the skillset to become someone of value in this community ( and other communities ) - as you prove to be of someone with a great deal of knowledge regarding code and coin infrastructure ... more than i do i would bet - but your vendetta against mt777 is blurring your vision of what is being done here ...
this is something that has now been done to allow those who WANT to have centos 7 x64 running - or already have centos 7 x64 running - AND want to compile a daemon for mtr that actually works on a multiplatform level ... ie - once they compile it ( static ) they can use it on other systems of theirs even if the systems are not exactly the same ... yes - their OWN systems so they dont have a trust issue with getting binaries from untrusted sources ...
anyway - i am back in the office and i am actually quite pleased that you take such a keen interest in the workings of mastertradercoin ...
i work on a few different coins - but obviously focus on my own coin - granite ...
#crysx
