### A ChainWorks Industries (CWI) Project - Granite | Simple Solid Stable | GRN

[chrysophylax]

Hi all, as the great reward is almost upon us I have a question. I'm not quite a fool, but I'm not wise in the ways of crypto and hashing either. I've been mining GRN with just my CPU and cgminger. It's really just a hit and miss deal from what I can tell. I get about one share at 55kh every three blocks or so. I really would like to work on the reward block, so can y'all offer any advise to improve my hashing before then? Thanks in advance.

I think you must buy several gpus. You can't compete with your cpu.

as with most 'large' size aglos that are mined - x11 is usually the domain of gpu mining - and above ( there is rumour - though no real proof as yet of asics ) ...

you can continue to mine with cpu - but as logocreator mentioned - it will be difficult for a cpu to mine and make any real gains ...

the bonus block will hit somewhere - as there are those mining on the official pool ( including myself on http://grn-pool.granitecoin.com/ ) as well as other pools available like yiimp - and aikapool - and coinking to name a couple ...

steakcloud have implemented the mining via algo system - and i wanted to announce that once all testing was done - but i may as well now ...

http://pool.steakcloud.com/ will mine any algo they have available - and you can payout in granite if you have asics or gpu miners for the sha256 - scrypt - x11 algos ...

though form of mining will NOT hit the bonus block - as it does not mine directly ... it mines other coins in their algo list - and is traded to payout in granite ... this is a good thing for the granite ecosystem - as it means trading becomes more frequent and allows more people to access granite via other means of mining other than just mining x11 algo ...

as for you situation ... have a look at various cpu miners ( like the one i 'supposed' to be helping with - but keep running out of time ) that optimize the cpu mining as much as they can - but with the advent of gpu / asic mining - cpu mining x11 will yield the least coin for you processing power ...

if you have video cards available for mining - whether nvidia or amd - then we can talk a different lingo altogether ...

pm me your address and ill start you off with some grn that i can donate to you ...

have a great time mining ...

remember that grn-pool has NO fees - block finder BONUS - and pool BONUS as well ... so whenever anyone finds blocks on there - you will take a share of it also ... all paid through the pool fund ...

if you need links to a few of the miners - let us know which you will be mining with - and we can point you to some and help as best we can with them ...

my apologies for the lack of updates and lack of time - as im moving twice in the span of 8 weeks - starting yesterday ... so very little time to do much at all ...

but ill be back when ive settled at least a little in the next two weeks ...

i hope this helps ...

not far off from the bonus block ... someone is bound to hit it somewhere ... pool and solominer alike have good chances ...

#crysx

[Bawaler]

Hi,
I have two amd64 compilation enviroments which have been capable to compile all the wallets this far but I'm facing connection issues in the wallet. Tried this with another computer and got stuck with same issue :/

Code:

~/wallets/granitecoin# ./granited getinfo
error: couldn't connect to server

My config path is

Code:

~/.GraniteCoin/GraniteCoin.conf

And it looks like this from inside

Code:

server=1
daemon=1
gen=0
rpcthreads=8
rpcallowip=127.0.0.1
rpcuser=
rpcpassword=
rpcport=21776
port=21777
addnode=seednode1.granitecoin.com
addnode=seednode2.granitecoin.com
addnode=seednode3.granitecoin.com
addnode=149.202.49.98
addnode=149.202.49.99
addnode=51.254.100.104
addnode=51.254.100.105
addnode=51.254.100.106
addnode=51.254.119.96
addnode=51.254.119.97
addnode=51.254.130.94
addnode=51.254.130.95
addnode=51.254.130.96
addnode=51.254.130.97
addnode=51.254.130.98
addnode=51.254.131.0

Is the configuration file kind of correct? Removed the user credentials from the paste.

Tried also adding nodes on run but no success.
Might it be use of BDB5.3 cause that I'm unable to get connections when I compile latest source from dev's github? I've tried to compile with all USE_UPNP= modes 1,0,-.
I'm compiling granited amd64 and it drops some DB related errors, but bypasses them. The daemon itself initializes itself making wallet file and folders to datadir.
Some coins do have autotools so at configuration part before making I could put a --with-incompatible-bdb -parameter to get rid of BDB related errors in compilation, I tried to do own configure file with autotools but the configurations does not work out of the box and takes some time to finish it as a working one.
Any other solutions than using autotools? I'd like to compile my own wallets. The reason on Linux is because there's BDB and GLIBC library version differences and some wallets which are compiled as static and used in system which have other version of BDB than the wallet is compiled with and because of that the risk of wallet getting corrupt at random point is very high. I've faced it one time on production use and that made me learn. Also, on Windows especially because there is much trojans and similar in those. Third reason is I'd like to choose the version of OpenSSL because some wallets might have bugs.

Thanks in advance

[chrysophylax]

Hi,
I have two amd64 compilation enviroments which have been capable to compile all the wallets this far but I'm facing connection issues in the wallet. Tried this with another computer and got stuck with same issue :/

Code:

~/wallets/granitecoin# ./granited getinfo
error: couldn't connect to server

My config path is

Code:

~/.GraniteCoin/GraniteCoin.conf

And it looks like this from inside

Code:

server=1
daemon=1
gen=0
rpcthreads=8
rpcallowip=127.0.0.1
rpcuser=
rpcpassword=
rpcport=21776
port=21777
addnode=seednode1.granitecoin.com
addnode=seednode2.granitecoin.com
addnode=seednode3.granitecoin.com
addnode=149.202.49.98
addnode=149.202.49.99
addnode=51.254.100.104
addnode=51.254.100.105
addnode=51.254.100.106
addnode=51.254.119.96
addnode=51.254.119.97
addnode=51.254.130.94
addnode=51.254.130.95
addnode=51.254.130.96
addnode=51.254.130.97
addnode=51.254.130.98
addnode=51.254.131.0

Is the configuration file kind of correct? Removed the user credentials from the paste.

Tried also adding nodes on run but no success.
Might it be use of BDB5.3 cause that I'm unable to get connections when I compile latest source from dev's github? I've tried to compile with all USE_UPNP= modes 1,0,-.
I'm compiling granited amd64 and it drops some DB related errors, but bypasses them. The daemon itself initializes itself making wallet file and folders to datadir.
Some coins do have autotools so at configuration part before making I could put a --with-incompatible-bdb -parameter to get rid of BDB related errors in compilation, I tried to do own configure file with autotools but the configurations does not work out of the box and takes some time to finish it as a working one.
Any other solutions than using autotools? I'd like to compile my own wallets. The reason on Linux is because there's BDB and GLIBC library version differences and some wallets which are compiled as static and used in system which have other version of BDB than the wallet is compiled with and because of that the risk of wallet getting corrupt at random point is very high. I've faced it one time on production use and that made me learn. Also, on Windows especially because there is much trojans and similar in those. Third reason is I'd like to choose the version of OpenSSL because some wallets might have bugs.

Thanks in advance

hi bawaler ...

tanx for letting us know ...

the latest build is compiling but failing to run - as i have experienced this currently with a number of coins that ive been 'helping' with - and it seems now granite is affected by it ...

the latest update to boost and openssl and bdb as a combination are causing a database issue with the creation of the peers.dat file ... and even if you get to that level of file creation - the daemon ( or wallet ) crashes and goes no further ...

the debug.log will show exactly that issue ( tail -f ~/<user>/.GraniteCoin/debug.log ) - and we are working on it at the moment ... there seem to be a few changes that have been made to the updates of both boost and bdb in the latest versions which are causing this ... and we are trying to locate the affected areas in the granite code ...

again - this issue has been now seen in a few other coins also - and fixes have been looked at and we are working on getting the fix into the current code of granite at the moment ...

there is only a few blocks left to the last bonus block - where 100krgn will be minted in this one block - so if you are mining and hit the block on any of the pools - they can hold the coins until we can organize a fix ...

what linux are you using? ... maybe i can send you a precompiled wallet or daemon for the time being ... as this issue is a very recent one ( and one we were not expecting ) a workaround / fix will help - but we are already looking at a full rebase ( and have been planning on it for the last two months now ) to advance the codebase for granite for its future growth ...

i cannot see you have done wrong in your setup - in fact its a good setup ...

the only nodes you require are the three seednodes normally ( if you have the older version of the wallet - the seednodes are now hardcoded into the current codebase ) - they are currently running and fully functional ( and fast ) ...

tanx for bringing this to our attention - and we will come back with a fix soon ...

let me know if i can help you further ... as i do have other versions compiled ( ubuntu daemon - fedora 23 x64 qt5 wallet - centos 7 x64 static daemon ) that ARE functional at the moment ...

#crysx

[chrysophylax]

the 100kgrn block just went off - and was hit by a lucky miner ...

what looks like a solominer - congrats on the massive hit and injection of 100,000grn ...

https://chainz.cryptoid.info/grn/address.dws?GNuvcSjFNwCf4aoEvzeZ7T8xnfQyCL44pH.htm ... great work - who ever you are ...

as of block 262800 - the halving starts and now 50grn per block is the block reward ...

https://chainz.cryptoid.info/grn/block.dws?262800.htm ...

funnily enough - the same person hit that block also ...

awesome guys ...

ill be back in a few days with updates on all thats been happening in the world of granite ...

#crysx

[Jonesd]

the 100kgrn block just went off - and was hit by a lucky miner ...

what looks like a solominer - congrats on the massive hit and injection of 100,000grn ...

https://chainz.cryptoid.info/grn/address.dws?GNuvcSjFNwCf4aoEvzeZ7T8xnfQyCL44pH.htm ... great work - who ever you are ...

as of block 262800 - the halving starts and now 50grn per block is the block reward ...

https://chainz.cryptoid.info/grn/block.dws?262800.htm ...

funnily enough - the same person hit that block also ...

awesome guys ...

ill be back in a few days with updates on all thats been happening in the world of granite ...

#crysx

Good to see we made it!

[Bawaler]

hi bawaler ...

tanx for letting us know ...

the latest build is compiling but failing to run - as i have experienced this currently with a number of coins that ive been 'helping' with - and it seems now granite is affected by it ...

the latest update to boost and openssl and bdb as a combination are causing a database issue with the creation of the peers.dat file ... and even if you get to that level of file creation - the daemon ( or wallet ) crashes and goes no further ...

the debug.log will show exactly that issue ( tail -f ~/<user>/.GraniteCoin/debug.log ) - and we are working on it at the moment ... there seem to be a few changes that have been made to the updates of both boost and bdb in the latest versions which are causing this ... and we are trying to locate the affected areas in the granite code ...

again - this issue has been now seen in a few other coins also - and fixes have been looked at and we are working on getting the fix into the current code of granite at the moment ...

there is only a few blocks left to the last bonus block - where 100krgn will be minted in this one block - so if you are mining and hit the block on any of the pools - they can hold the coins until we can organize a fix ...

what linux are you using? ... maybe i can send you a precompiled wallet or daemon for the time being ... as this issue is a very recent one ( and one we were not expecting ) a workaround / fix will help - but we are already looking at a full rebase ( and have been planning on it for the last two months now ) to advance the codebase for granite for its future growth ...

i cannot see you have done wrong in your setup - in fact its a good setup ...

the only nodes you require are the three seednodes normally ( if you have the older version of the wallet - the seednodes are now hardcoded into the current codebase ) - they are currently running and fully functional ( and fast ) ...

tanx for bringing this to our attention - and we will come back with a fix soon ...

let me know if i can help you further ... as i do have other versions compiled ( ubuntu daemon - fedora 23 x64 qt5 wallet - centos 7 x64 static daemon ) that ARE functional at the moment ...

#crysx

Thanks for a explanation,
I'll try to contact you at IRC soon, I'm running Debian 9 "stretch" x86_64, my BerkeleyDB is 5.3 and GLIBCXX version (libstdc++) is 3.4.21. At leats GLIBCXX version need to match, but it will run if the binary is compiled with BDB4.8/5.1, there's just the wallet file corruption risk around :/

[chrysophylax]

hi bawaler ...

tanx for letting us know ...

the latest build is compiling but failing to run - as i have experienced this currently with a number of coins that ive been 'helping' with - and it seems now granite is affected by it ...

the latest update to boost and openssl and bdb as a combination are causing a database issue with the creation of the peers.dat file ... and even if you get to that level of file creation - the daemon ( or wallet ) crashes and goes no further ...

the debug.log will show exactly that issue ( tail -f ~/<user>/.GraniteCoin/debug.log ) - and we are working on it at the moment ... there seem to be a few changes that have been made to the updates of both boost and bdb in the latest versions which are causing this ... and we are trying to locate the affected areas in the granite code ...

again - this issue has been now seen in a few other coins also - and fixes have been looked at and we are working on getting the fix into the current code of granite at the moment ...

there is only a few blocks left to the last bonus block - where 100krgn will be minted in this one block - so if you are mining and hit the block on any of the pools - they can hold the coins until we can organize a fix ...

what linux are you using? ... maybe i can send you a precompiled wallet or daemon for the time being ... as this issue is a very recent one ( and one we were not expecting ) a workaround / fix will help - but we are already looking at a full rebase ( and have been planning on it for the last two months now ) to advance the codebase for granite for its future growth ...

i cannot see you have done wrong in your setup - in fact its a good setup ...

the only nodes you require are the three seednodes normally ( if you have the older version of the wallet - the seednodes are now hardcoded into the current codebase ) - they are currently running and fully functional ( and fast ) ...

tanx for bringing this to our attention - and we will come back with a fix soon ...

let me know if i can help you further ... as i do have other versions compiled ( ubuntu daemon - fedora 23 x64 qt5 wallet - centos 7 x64 static daemon ) that ARE functional at the moment ...

#crysx

Thanks for a explanation,
I'll try to contact you at IRC soon, I'm running Debian 9 "stretch" x86_64, my BerkeleyDB is 5.3 and GLIBCXX version (libstdc++) is 3.4.21. At leats GLIBCXX version need to match, but it will run if the binary is compiled with BDB4.8/5.1, there's just the wallet file corruption risk around :/

try installing and compiling with gcc ( 5.x ) - as that is usually the standard i compile with here on fedora 23 x64 ...

failing that - the older version of bdb may be the way to go with the older versions installed ...

but this needs to be resolved whichever way i look at it - and this will be done as soon as possible ...

#crysx

[crackfoo]

hi bawaler ...

tanx for letting us know ...

the latest build is compiling but failing to run - as i have experienced this currently with a number of coins that ive been 'helping' with - and it seems now granite is affected by it ...

the latest update to boost and openssl and bdb as a combination are causing a database issue with the creation of the peers.dat file ... and even if you get to that level of file creation - the daemon ( or wallet ) crashes and goes no further ...

the debug.log will show exactly that issue ( tail -f ~/<user>/.GraniteCoin/debug.log ) - and we are working on it at the moment ... there seem to be a few changes that have been made to the updates of both boost and bdb in the latest versions which are causing this ... and we are trying to locate the affected areas in the granite code ...

again - this issue has been now seen in a few other coins also - and fixes have been looked at and we are working on getting the fix into the current code of granite at the moment ...

there is only a few blocks left to the last bonus block - where 100krgn will be minted in this one block - so if you are mining and hit the block on any of the pools - they can hold the coins until we can organize a fix ...

what linux are you using? ... maybe i can send you a precompiled wallet or daemon for the time being ... as this issue is a very recent one ( and one we were not expecting ) a workaround / fix will help - but we are already looking at a full rebase ( and have been planning on it for the last two months now ) to advance the codebase for granite for its future growth ...

i cannot see you have done wrong in your setup - in fact its a good setup ...

the only nodes you require are the three seednodes normally ( if you have the older version of the wallet - the seednodes are now hardcoded into the current codebase ) - they are currently running and fully functional ( and fast ) ...

tanx for bringing this to our attention - and we will come back with a fix soon ...

let me know if i can help you further ... as i do have other versions compiled ( ubuntu daemon - fedora 23 x64 qt5 wallet - centos 7 x64 static daemon ) that ARE functional at the moment ...

#crysx

Thanks for a explanation,
I'll try to contact you at IRC soon, I'm running Debian 9 "stretch" x86_64, my BerkeleyDB is 5.3 and GLIBCXX version (libstdc++) is 3.4.21. At leats GLIBCXX version need to match, but it will run if the binary is compiled with BDB4.8/5.1, there's just the wallet file corruption risk around :/

try installing and compiling with gcc ( 5.x ) - as that is usually the standard i compile with here on fedora 23 x64 ...

failing that - the older version of bdb may be the way to go with the older versions installed ...

but this needs to be resolved whichever way i look at it - and this will be done as soon as possible ...

#crysx

I have this issue  as well on our new pool servers. ubuntu 14.04

[chrysophylax]

hi bawaler ...

tanx for letting us know ...

the latest build is compiling but failing to run - as i have experienced this currently with a number of coins that ive been 'helping' with - and it seems now granite is affected by it ...

the latest update to boost and openssl and bdb as a combination are causing a database issue with the creation of the peers.dat file ... and even if you get to that level of file creation - the daemon ( or wallet ) crashes and goes no further ...

the debug.log will show exactly that issue ( tail -f ~/<user>/.GraniteCoin/debug.log ) - and we are working on it at the moment ... there seem to be a few changes that have been made to the updates of both boost and bdb in the latest versions which are causing this ... and we are trying to locate the affected areas in the granite code ...

again - this issue has been now seen in a few other coins also - and fixes have been looked at and we are working on getting the fix into the current code of granite at the moment ...

there is only a few blocks left to the last bonus block - where 100krgn will be minted in this one block - so if you are mining and hit the block on any of the pools - they can hold the coins until we can organize a fix ...

what linux are you using? ... maybe i can send you a precompiled wallet or daemon for the time being ... as this issue is a very recent one ( and one we were not expecting ) a workaround / fix will help - but we are already looking at a full rebase ( and have been planning on it for the last two months now ) to advance the codebase for granite for its future growth ...

i cannot see you have done wrong in your setup - in fact its a good setup ...

the only nodes you require are the three seednodes normally ( if you have the older version of the wallet - the seednodes are now hardcoded into the current codebase ) - they are currently running and fully functional ( and fast ) ...

tanx for bringing this to our attention - and we will come back with a fix soon ...

let me know if i can help you further ... as i do have other versions compiled ( ubuntu daemon - fedora 23 x64 qt5 wallet - centos 7 x64 static daemon ) that ARE functional at the moment ...

#crysx

Thanks for a explanation,
I'll try to contact you at IRC soon, I'm running Debian 9 "stretch" x86_64, my BerkeleyDB is 5.3 and GLIBCXX version (libstdc++) is 3.4.21. At leats GLIBCXX version need to match, but it will run if the binary is compiled with BDB4.8/5.1, there's just the wallet file corruption risk around :/

try installing and compiling with gcc ( 5.x ) - as that is usually the standard i compile with here on fedora 23 x64 ...

failing that - the older version of bdb may be the way to go with the older versions installed ...

but this needs to be resolved whichever way i look at it - and this will be done as soon as possible ...

#crysx

I have this issue  as well on our new pool servers. ubuntu 14.04

have you found its with some other coins also? ...

this has occurred with three coins that i have worked on ... but fixes and workarounds have been implemented ...

id like it completely fixed / eradicated in the granite code ... so we need to work out what exactly it is - and replace the code with an updated one ...

#crysx

[crackfoo]

have you found its with some other coins also? ...

this has occurred with three coins that i have worked on ... but fixes and workarounds have been implemented ...

id like it completely fixed / eradicated in the granite code ... so we need to work out what exactly it is - and replace the code with an updated one ...

#crysx

Of the 100+ ones I just re-compiled and started up... this has been the only one not staying running....

[chrysophylax]

have you found its with some other coins also? ...

this has occurred with three coins that i have worked on ... but fixes and workarounds have been implemented ...

id like it completely fixed / eradicated in the granite code ... so we need to work out what exactly it is - and replace the code with an updated one ...

#crysx

Of the 100+ ones I just re-compiled and started up... this has been the only one not staying running....

yup - that confirms that its the older codebase ...

ill find a fix for it soon - in the middle of moving at the moment ...

since the updates - ive not been able to compile on fedora 23 x64 - and can only use the previous compile ...

will look at what can be fixed in it and come up with a solution very soon ...

tanx for the info - its invaluable ...

apart from the fact that im surprised and quite flattered that you are including granite in zpool also ...

tanx ... we will have it fixed as soon as possible ...

#crysx

[chrysophylax]

hi all ...

we are having a few issues with our official pool http://grn-pool.granitecoin.com/ and are working to resolve it ...

we should have our pool back up and running within a few hours ...

apologies for the inconvenience this may have caused ...

#crysx

[ReiMomo]

Hi all, as the great reward is almost upon us I have a question. I'm not quite a fool, but I'm not wise in the ways of crypto and hashing either. I've been mining GRN with just my CPU and cgminger. It's really just a hit and miss deal from what I can tell. I get about one share at 55kh every three blocks or so. I really would like to work on the reward block, so can y'all offer any advise to improve my hashing before then? Thanks in advance.

I think you must buy several gpus. You can't compete with your cpu.

CPU mining with cgminer? I don't know what CPU you have but the best x11 CPU miner is this one https://github.com/elmad/darkcoin-cpuminer-1.3-avx-aes/releases

[chrysophylax]

Hi all, as the great reward is almost upon us I have a question. I'm not quite a fool, but I'm not wise in the ways of crypto and hashing either. I've been mining GRN with just my CPU and cgminger. It's really just a hit and miss deal from what I can tell. I get about one share at 55kh every three blocks or so. I really would like to work on the reward block, so can y'all offer any advise to improve my hashing before then? Thanks in advance.

I think you must buy several gpus. You can't compete with your cpu.

CPU mining with cgminer? I don't know what CPU you have but the best x11 CPU miner is this one https://github.com/elmad/darkcoin-cpuminer-1.3-avx-aes/releases

try this one that joblo is getting together ...

he is a great guy and is doing a major overhaul on the algos in this new miner ...

https://bitcointalk.org/index.php?topic=1326803 ...

let me know ...

#crysx

[chrysophylax]

hi all ...

we are having a few issues with our official pool http://grn-pool.granitecoin.com/ and are working to resolve it ...

we should have our pool back up and running within a few hours ...

apologies for the inconvenience this may have caused ...

#crysx

pool is all fixed and up and running beautifully again - without a hitch for 24hours so far ...

njoi mining ...

now back to work on granite - and thefarm ...

#crysx

[yaamp]

hello,

Granite (GRN) is now listed for trading on our exchange https://safecex.com/market?q=GRN/BTC

[BitcoinNational]

hello,
Granite (GRN) is now listed for trading on our exchange https://safecex.com/market?q=GRN/BTC

cool
like to see GRN on cryptopia this year too

#crysx get safecex posted on the website 

[chrysophylax]

hello,
Granite (GRN) is now listed for trading on our exchange https://safecex.com/market?q=GRN/BTC

cool
like to see GRN on cryptopia this year too

#crysx get safecex posted on the website 

many tanx to yaamp and the wonderful work he has done with the new exchange ... and many tanx also for the addition of granite to safecex also ...

i have had little time to update here - but will do in the very near future ...

there have been a few changes - including safecex - that have happened with granite and some of these changes will be published fully - with the op updated to reflect the same ...

we have been on the voting list for cryptopia for a while ( as with ccex and a few others - including the ill fated cryptsy ) - but have not been pushing the marketing side very much ...

the reason for this is the complete rebase of granite - and what it will morph into ... as well as another addition to the granite family which is under negotiation currently ...

the website is actually being currently revamped and completely changed on a structural level - with a few features we think will bring a great deal of use from it - including the integration of the official granite pool WITHIN the website itself - not just a hyperlink to the pool ...

a lot has been happening on the personal side of life also - and those are slowly being resolved also ...

good things take time - and granite will show that for the moment - time will be good to granite also ...

ill be back and more indepth soon ...

#crysx

[HYPERfuture]

Following because the dev chrys seems to be a stand up guy.

[Jonesd]

Following because the dev chrys seems to be a stand up guy.

Same here! Usually this strategy pays off. I had the same thing with Gamecredits and Expanse and that has paid off extremely well. Also just placed som buy orders for HYPER, btw, since that is crazy underprized