[ANN][DCR] Decred - Community Governance | Bitcoin Devs | Lightning Network

[chrysophylax]

Very interesting project, unfortunate that Nvidia miners are not getting the same love as AMD

Do we need to crowd fund to get something valid released?


Maybe we just do not have enough Nvidia miners to Justify our existence.

o we have enough nvidia miners - and some farms too ...

even though cgminer that ocminer released apparently does work with nvidia ( i havent tried yet - as mine STILL wont compile ) - the opencl mining on nvidia is weak ...

so maybe the nvidia dev that comes out with this algo before mining commences will take a nice chunk of the pie in general - and im more than willing to give them a nice chunk of the mining with thefarm if the code will compile on my machines under fedora 23 x64 cuda 7 ...

djm34 - sp - tpruvot - anyone? ...

#crysx

[chrysophylax]

Very interesting project, unfortunate that Nvidia miners are not getting the same love as AMD

Do we need to crowd fund to get something valid released?


Maybe we just do not have enough Nvidia miners to Justify our existence.

Really, you're not being as picked on as it seems - CUDA is great when it comes to more complex algos, or algos that can benefit from Nvidia-specific optimizations that the compiler is unable to find by itself, but this is not the case for Decred. Really, you're talking about a minor bump I would guess, at most. The algo is dead simple - I've made the miner a few percent faster on AMD - but we're talking single digit percentages... and low digits. The Nvidia OpenCL compiler would really have a hard time fucking it up.

there you go - wolf just answered it again ...

so cuda would have very little - if any - effect on the hashrate of the algo ...

ok - tanx wolf ...

now to get this darn thing to compile ...

ill work on it a little later this afternoon ...

#crysx

[EmilioMann]

After spreading food against some altcoins GMaxwell admits the Bitcoin Lightning Network is vaporware

https://twitter.com/traderminer/status/695084561382928384

[eshriek]

What's a normal hashrate for one 280x? I keep getting 1.4/1.5, but according to dr. Google i could get ~2-2.5?

Core 1100 Mem 1500
Intensity at 14

I don't get it.

I get 1.4-1.5 too . This is 14 round blake, not 8 round, don't forget that

Thanks for your efforts. I can't make a connection to your pool yet, I use this line to start cgminer:

cgminer --blake256 -u username.worker -p x -o stratum+tcp://dcr.suprnova.cc:9110

Where username.worker is of course my own ;-) Am I doing anything wrong here?

[2016-02-03 09:52:31] Pool: 0  URL: stratum+tcp://dcr.suprnova.cc:9110  User: username.worker  Password: x
 [2016-02-03 09:52:31] Press any key to exit, or cgminer will try again in 15s.
 [2016-02-03 09:53:46] No servers were found that could be used to get work from
.
 [2016-02-03 09:53:46] Please check the details from the list below of the serve
rs you have input

Thanks!

Did you get an answer on this?

Try http://dcr.suprnova.cc:9110 instead of stratum+tcp

just what I read at https://forum.decred.org/threads/suprnovas-dcr-pool.422/#post-6120

[eshriek]

Hey folks,

I've got a DCR Pool ready for testing:

https://dcr.suprnova.cc

First the credits:
Thanks to ceejep and Wolf for the (really crazy) cgminer stuff and feeleep for the getwork and mpos testing/developing.

I'm using a special version of cgminer with some fixes, as while I was testing I encountered several problems with the original DCR cgminer implementation. My fork is here:

https://github.com/ocminer/cgminer-decred

In the original version endianness was incorrect, so (in my testing) blocks were found much less than expected, in the corrected version from my github you should find blocks (when pool mining) much more often. My version should also work on every other pool but not vice versa, so the official version is (not yet) working on my pool, you'll only get rejects. I'm in contact with cejep @ IRC to get my fixes commited to the official version and I'll also create a pull request soon. I'm still trying to get stratum implemented but there are STILL a lot of bugs and swapped things (big endian should be little endian) in cgminer. I hope to get most of the stuff fixed until the launch. Duplicate shares are a rather big problem currently.

Again: Please don't point the compiled official version to my pool - they won't work - you'd need to compile from my source !

Please be so kind and point your miner to my pool to see if the hashrate matches. Several blocks were found already, statistics are okay, hashrate calc seems to be ok and things like payouts etc. have to be tested.

Of course the pool is completely free for now, I'll add a 1% fee later on. If you see anything weird, please let me know. Either via PM here on bitcointalk or you can also get me on Twitter: @SuprnovaPools http://twitter.com/SuprnovaPools

Thanks for this. I'll make an effort to test it out and post back in the next 48 hours.

[Godson_Mansa]

Question for the nerds!!!
will rented hash work ? or will it not cos this isn't the same Blake257 algo.

@wolf0
@ocminer

you know yourselves.

[Godson_Mansa]

Question for the nerds!!!
will rented hash work ? or will it not cos this isn't the same Blake257 algo.

@wolf0
@ocminer

you know yourselves.

Not until stratum.

even after stratum will we have to get the same Blake256 8 round 16 whatever or will any Blake256 work ?

[ocminer]

Question for the nerds!!!
will rented hash work ? or will it not cos this isn't the same Blake257 algo.

@wolf0
@ocminer

you know yourselves.

Well.. You should be able to rent out getwork rigs too.. It's just a matter of the rental service to integrate getwork instead/beside stratum but getwork is not really meant for such things, it's a old, http based protocol vs. stratum which ls lightweight, tcp based with calls/broadcasts like "mining.notify" when new blocks are seen on the network. Long time ago getwork was not able to tell when new blocks on the network showed up, so the miner literally continued to mine on the old block until the pool then lastly noticed there IS a new block and with the next http request the miner threw away the old work (stales) and started mining on the new block. This was later tried to fix with LP (LongPoll). LP uses a separate connection to the Pool (still http) which should notify about new blocks. This works, simplified, so that the miner pings the pool every 50 or 100ms "Is there a new block?" and the pool answers with "No" - or "Yes" if there's a new block which then leads to a refresh of the miners work.

Still you have a gap of 49 or 99ms between every LP check - which is quite a lot but setting this interval higher, like every 10ms, causes a big load on the pool, especially when you have lots of miners there. Just imagine 100 miners, polling every 10 ms "Is there a new Block?" from the pool.. It like sitting in a Subway and all the passengers shout "I want to get out here" every tenth of a second... The more people you have in there, the louder it gets, and at some point the pool is just overloaded and not working anymore.

Getwork is old and deprecated - definitely.

Stratum was introduced by slush as a websocket protocol. It's TCP based, miners don't poll the pool every 10ms or 100ms - they don't even need to make a second connection for long poll, they simply establish ONE connection over which they get data submitted from which they then generate their own work - so they don't need to ask the pool anymore for new work and if a new block at the network shows up - the pool does a broadcast "mining.notify" via this single TCP connection (every miner has) to notify them to poll new base work to work on - it's simply the way it should be.

I don't want to be boring here with such technical stuff, it's just a matter of time until stratum will be and shall be used IMHO - getwork will just not scale enough.

Read more here if you're interested in history and technical stuff

https://mining.bitcoin.cz/help/#!/manual/stratum-protocol#lp

[Godson_Mansa]

Question for the nerds!!!
will rented hash work ? or will it not cos this isn't the same Blake257 algo.

@wolf0
@ocminer

you know yourselves.

Well.. You should be able to rent out getwork rigs too.. It's just a matter of the rental service to integrate getwork instead/beside stratum but getwork is not really meant for such things, it's a old, http based protocol vs. stratum which ls lightweight, tcp based with calls/broadcasts like "mining.notify" when new blocks are seen on the network. Long time ago getwork was not able to tell when new blocks on the network showed up, so the miner literally continued to mine on the old block until the pool then lastly noticed there IS a new block and with the next http request the miner threw away the old work (stales) and started mining on the new block. This was later tried to fix with LP (LongPoll). LP uses a separate connection to the Pool (still http) which should notify about new blocks. This works, simplified, so that the miner pings the pool every 50 or 100ms "Is there a new block?" and the pool answers with "No" - or "Yes" if there's a new block which then leads to a refresh of the miners work.

Still you have a gap of 49 or 99ms between every LP check - which is quite a lot but setting this interval higher, like every 10ms, causes a big load on the pool, especially when you have lots of miners there. Just imagine 100 miners, polling every 10 ms "Is there a new Block?" from the pool.. It like sitting in a Subway and all the passengers shout "I want to get out here" every tenth of a second... The more people you have in there, the louder it gets, and at some point the pool is just overloaded and not working anymore.

Getwork is old and deprecated - definitely.

Stratum was introduced by slush as a websocket protocol. It's TCP based, miners don't poll the pool every 10ms or 100ms - they don't even need to make a second connection for long poll, they simply establish ONE connection over which they get data submitted from which they then generate their own work - so they don't need to ask the pool anymore for new work and if a new block at the network shows up - the pool does a broadcast "mining.notify" via this single TCP connection (every miner has) to notify them to poll new base work to work on - it's simply the way it should be.

I don't want to be boring here with such technical stuff, it's just a matter of time until stratum will be and shall be used IMHO - getwork will just not scale enough.

Read more here if you're interested in history and technical stuff

https://mining.bitcoin.cz/help/#!/manual/stratum-protocol#lp

haha you're a NERRRRD!!! lol but seriously though when i asked this question i was thinking if the mining algo will line up(8 round vs 16 round etc) but i see there are more problems that i didn't see. thanks

[craslovell]

@ocminer

Do you know what address and port number the pool will use when decred officially launches on Monday? Wasn't sure if you were going to change it. I will be away from my gear with no internet access during launch and I'm trying to get this sucker started through a scheduled task.

[ocminer]

@ocminer

Do you know what address and port number the pool will use when decred officially launches on Monday? Wasn't sure if you were going to change it. I will be away from my gear with no internet access during launch and I'm trying to get this sucker started through a scheduled task.

Will remain the same.

[craslovell]

@ocminer

Do you know what address and port number the pool will use when decred officially launches on Monday? Wasn't sure if you were going to change it. I will be away from my gear with no internet access during launch and I'm trying to get this sucker started through a scheduled task.

Will remain the same.

Sorry if I missed that earlier, didn't want to dig through the thread. Thanks!

[favdesu]

so.... is there a PoS Pool in the making? I'd like to start immediately/test it out

[ozboy2014]

which exchange(s) are Decred likely to be on initially?

[eshriek]

which exchange(s) are Decred likely to be on initially?

https://bleutrade.com referenced from here: https://forum.decred.org/threads/mainnet-launch-date.380/#post-5442

[ozboy2014]

which exchange(s) are Decred likely to be on initially?

https://bleutrade.com referenced from here: https://forum.decred.org/threads/mainnet-launch-date.380/#post-5442

Thanks

12 CST Monday 8/2/2016 launch time... hmm that would be 5:00AM on Tuesday 9/2/2016 for those who are in Melbourne/Canberra/Sydney I think.

[anders lokka]

@ocminer

Do you know what address and port number the pool will use when decred officially launches on Monday? Wasn't sure if you were going to change it. I will be away from my gear with no internet access during launch and I'm trying to get this sucker started through a scheduled task.

Will remain the same.

suprnova pool work fine.
Good job.

[Gunther]

Nice, a pool is already up. Rented some hashes to test but pool (suprnova) doesn't seem to work. Probably because it's some new algo, right? It's hard for a pool to implement new features, but i'm sure you will get it done before launch.

[anders lokka]

Nice, a pool is already up. Rented some hashes to test but pool (suprnova) doesn't seem to work. Probably because it's some new algo, right? It's hard for a pool to implement new features, but i'm sure you will get it done before launch.

It's Blake 14 round.
No rent hash available now.

[sambiohazard]

Very interesting project, unfortunate that Nvidia miners are not getting the same love as AMD

Do we need to crowd fund to get something valid released?


Maybe we just do not have enough Nvidia miners to Justify our existence.

Really, you're not being as picked on as it seems - CUDA is great when it comes to more complex algos, or algos that can benefit from Nvidia-specific optimizations that the compiler is unable to find by itself, but this is not the case for Decred. Really, you're talking about a minor bump I would guess, at most. The algo is dead simple - I've made the miner a few percent faster on AMD - but we're talking single digit percentages... and low digits. The Nvidia OpenCL compiler would really have a hard time fucking it up.

@wolf I tried the cgminer & ccminer both & they give me

970 1.52 GH/s on ccminer & 1.11GH/s on cgminer
750ti 530MH/s in ccminer & 431 MH/s on cgminer

so there is 75-80% loss in hashrate. Also as i remember, ccminer was running at much lower TDP% as shown in Afterburner, ~80% while cgminer was using 98-100% power. Considering all this i think there is a big disadvantage & some potential for optimizing ccminer for decred, unless the modification required for decred somehow lower the hashrate. But i guess ccminer devs are too busy taking potshots at each other, so we will have to make do with what we have or wait for decred team to release something.