Topic: [ANN] Denarius [D] - First "Tribus" PoW/PoS Hybrid Masternodes, Ring Sigs - page 163. (Read 504255 times)

enkayz, bokiminer nice comments. I can learn something from you two...

From comments that I read on here, I don't know on what side of the moon is dev Carsen or is he a scammer or not, but this Denarius project looks good so far and its graphically polished.

Carsen your answers to questions are very precise and rich in details, nice work so far. It would be so nice to see this project going in right direction.

No, bathrobehero is just angry because he is stuck with abandoned scamcoin SIGT and paid miner, do not pay attention to him
To hold or not to hold DNR, decision should be only yours.

Carsen's been involved in several failed projects, but they were quite some time ago in the midst of the shitcoin bonanza. He's never been one to shy away from putting his name on a project.. seems there are a few projects even launched in his honor evidently. This one however seems very different; the reward structure is very respectable; the premine whilst seemingly high was distributed out to many people and the dev account wasn't even touched during the pump. The coin speaks for itself regardless of Carsen's history. I believe Carsen's in it for the long game in this coin - there's been many a joke coin in the past and perhaps putting his name to those has been detrimental to the future of other coins he creates, but like I said, something's different about DNR.

Even if Carsen does dump his supply (only 500k at this point), the coin's going to survive - fast block times & confirmations, almost instantaneous transfers & a well spread PoW reward structure will speak for itself in the future. Carsen would be stupid to go and dump on this coin when it is evidently able to become worth upwards of $10 in the medium term. I think after a few years off the market, he's realized you can do better than create coins for the sole purpose of dumping them hard when they hit the market. The algorithm performs well & won't be hit by ASICs within the PoW period.

There will probably be more people coming to FUD the coin, but really the only FUD available is the premine supply. Otherwise the coin is not even remotely geared for a PnD, as opposed to some other coins recently launched with very high top-heavy rewards and very short PoW periods - those are the ones you need to watch out for..

KAspersky indicates the wallet v 1.0.3 as a virus on windows 10.
I have 20 others local wallets and that is the only one marked as virus by Kaspersky.

is there any truth to that?
i would like to hold but this makes me fud xD

Hi,

What is average DNR block size that we are mining? I was checking few blocks in block explorer and all of them were smaller than 1 kB. I am looking at right place?

Tnx

U have right...for miners its...for ppl what buy it to .37 isnt too good...and the price will continue i guess ...somebody say 9 k...

Even at the current low, DNR is still one of the better coins to mine.

Rough whattomine #'s, just input current cryptopia price.

1070, 42 MH/s, 90 watts
https://whattomine.com/coins/187-dnr-tribus?utf8=%E2%9C%93&hr=42000.0&p=90.0&fee=0.0&er_enabled=true&er=0.00018000&cost=0.1&hcost=0.0&commit=Calculate

1080, 54 MH/s, 110 watts
https://whattomine.com/coins/187-dnr-tribus?utf8=%E2%9C%93&hr=54000.0&p=110&fee=0.0&er_enabled=true&er=0.00018000&cost=0.1&hcost=0.0&commit=Calculate

6x 1070, 252 MH/s, 540 watts
https://whattomine.com/coins/187-dnr-tribus?utf8=%E2%9C%93&hr=252000.0&p=540&fee=0.0&er_enabled=true&er=0.00018000&cost=0.1&hcost=0.0&commit=Calculate

i think not for GSR coin

The state of all cryptos is down so it's not surprising.. buy orders set low.

Are you sure you are selecting the right algorithm? -k tribus or -a tribus depending on sgminer/ccminer. The 'auto' won't work properly are will give invalid shares. Other reasons might be too high overclock or intensity. Otherwise, the pool is working fine at the moment - so I think it would be something on your config there.

Back to 9K satoshi..

Have you tried the auto-select region DNS: -o stratum+tcp://pool.hashbag.cc:8688
Are your cards overclocked? (Maybe they are too much?)
Wich miner do you use?

With ccmner 2.2 on a 6 1060 rig, I have no problems (without putting any -p arguments).

Getting all invalid shares with RX 470. Why?

-o stratum+tcp://de.hashbag.cc:8688 -u -p c=DNR

Has anyone got ccminer mod for DNR? How about 1080ti hashrate increase? I have heard that it is not stable, isn't it?

Thank you.

tanx again enkayz ...

nice to see a fellow redhatian ...

so you dont actually compile a static build at all ... which is different to the fully static build we do ... we do this so we can spread it among the seednodes as well ( hence the sync - and full nodes if carsen did any form of deal with dnr and the seednodes ) ...

so far - our procedures are almost identical - bar the sandboxing required for static builds ...

BUT the LD paths are what are missing by the looks of it - and seems i have overlooked ... so some time tonight or tomorrow - ill have a go at it by changing the makefile.am to include the paths ... its a complete script that has been written for the static build - and is very efficient - but fiddly when it comes to such issues as this ...

everything else is on par ...

as for editing the makefile - are you kidding? ... this is all part of the fun - and frustration ... ...

much appreciated ... let see what area of the rabbithole this leads us to ...

#crysx

anyone can help?

i'm running a daemon on centos 7 x64.. it compiled fine using libevent-devel with no need for hand-holding of the make file. the only real issue i faced was the tcp6 stack which required me to put rpcallowip=external.ip.address, rpcallowip=127.0.0.1 since the boost binds to a shared tcp/tcp6 port and for some reason the ip which is given by connecting to loopback is the external ip, so i was receiving a 403 on rpc calls. not sure if it was something i did on my centos7 or if it's part of the distro's quirks, either way, just thought i'd note that in case someone else faced the issue

in regards to openssl crippling, the centos openssl version doesn't work yes, but if you compile 1.0.1g and install it into it's default /usr/local/ssl prefix, then just run:
OPENSSL_INCLUDE_PATH=/usr/local/ssl/include OPENSSL_LIB_PATH=/usr/local/ssl/lib make -f makefile.unix

then it all compiles fine. if you need some help getting it to work, just drop me a line, i can help. as noted i am using centos7 and it does work albeit the requirements for openssl

just to make a note you don't have to compile the entire daemon statically if you are using a static library, there are already two static libraries used in almost every coin daemon and that is libleveldb.a/libmemenv.a - you don't have to link openssl nor libevent statically, dynamic libraries will work fine as long as they are installed inside a directory which is included in the -L flags and then noted for linking with the -l flag.. if you definitely want to link a static version of a library then you will have to add the static library path directly, how libleveldb.a is linked:

LIBS += /path/to/openssl.a /path/to/libevent.a
or if you don't fancy editing the makefile you can use the xLDFLAGS environment variable to pass any linker flags you want into the makefile, although you might be forced to remove the -levent from the LIBS variable in makefile if that is causing issues at link time

hehehe ...

i appreciate the vote of help mate ...

but no - that is not the issue ... especially when its obvious no one seems to have a clue about centos 7 / rhel 7 / or any rhel based OS ... not sound rude to you of course ...

we are NOT newbies - and know the issues ...

the daemon is required to be statically compiled due to the redhat crippling of the openssl implementation ... they are morons - but hey they are redhat ...

the openssl implementation that rhel uses is crippled because of some garbage redtape about ecc legal ( so they removed the eec that ALL crypto works on - tanx bitcoin - secp256k1 ) ... anyway - you can readup on it in all sorts of areas ...

libevent is NOT the problem - as that installs readily ... the STATIC version is ... you cant compile a dynamic version due to the ecc crippling - and you cannot access the libevent installed in the centos system - because the code of dnr cannot find it ( as its looking for it in the static libraries ) ... the reason the dnr code cannot find it is - you guessed it - because the centos 7 / rhel repos do NOT have the static libraries for libevent ...

see the dilemma? ...

dnr is one of the ONLY coins to bomb out due to this ridiculous dependency ...

bitcoin was the other - but they fixed that in version 0.12.xxx from memory ...

so - even when trying to compile the dnr daemon WITH the freshly statically compiled libevent ( from git ) - it STILL bombs ... so cheers to -levent giving us the finger right at the end of the compile ... if libevent wasnt used - the dnr daemon would compile flawlessly ... there may be a variable for libevent that we are not exporting - but we dont know what that may be ... dbd boost and openssl all have environment varioables exported to show the daemon where the static libraries are - but libevent has nothing in the docs about that ...

as it stands - it is the only thing holding this daemon addition back from the our CWI-Pool system ...

o - and if anyone asks - NO ... we will not be moving our entire infrastructure to ubuntu or a debian based system ... its our companies infrastructure we are using - and it wont move from centos 7 x64 - until the entire infrastructure gets a revamp ... and with more than 70vps systems and dedicated servers in the plan - that wont happen from a while yet ...

tanx again for you help tho - its appreciated ... ill back in a few hours ...

#crysx

CentOS7 just yum install libevent-devel should work fine? or is that not the issue?