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

[ozboy2014]

polo should be soon.. 

[1714713323]

1714713323

[1714713323]

1714713323

[1714713323]

1714713323

[1714713323]

1714713323

[1714713323]

1714713323

[arielbit]

polo should be soon.. 

yeah lol at people who are dumping, polo is a bigger market.

[thefix]

Finished adding the other half of the block header not shown earlier to the output of the tests - putting in the final XOR with input block stage of Blake-256 that I forgot about when testing, in order to make it a full Decred process that will work, and porting tests to match. Also changed protocol to something more Icarus-like, in preparation for CGMiner support, and changed some stuff in the core transform, helping me drop slices, making the design smaller.

Previously, slice usage was ~1,300 out of the LX9's 1,430. Dropped it to 1,205 in this latest synthesis, but that isn't yet enough free logic to allow me to speed it up yet, I don't think.

Sounds promising, do you expect similar kind of speeds compared to other Blake algo coins on FPGA devices? I am also curious if you are using a more modern readily available FPGA device?

[decred]

Updated the OP text to reflect proof-of-stake (PoS) mining becoming active at block 4,096. The mainnet stake pool code underwent optimization and further testing today and is coming this week. The code will be made free and open-source software as well, so it will be really good to see if the project can work with others who are interested in becoming stake pool operators. You will be able to charge a nominal fee for doing so. It would be ideal to get at least 10 stake pools up and running to help decentralize the effort.

[chrysophylax]

Finished adding the other half of the block header not shown earlier to the output of the tests - putting in the final XOR with input block stage of Blake-256 that I forgot about when testing, in order to make it a full Decred process that will work, and porting tests to match. Also changed protocol to something more Icarus-like, in preparation for CGMiner support, and changed some stuff in the core transform, helping me drop slices, making the design smaller.

Previously, slice usage was ~1,300 out of the LX9's 1,430. Dropped it to 1,205 in this latest synthesis, but that isn't yet enough free logic to allow me to speed it up yet, I don't think.

Sounds promising, do you expect similar kind of speeds compared to other Blake algo coins on FPGA devices? I am also curious if you are using a more modern readily available FPGA device?

Backstory is, this implementation was done simply because people kept telling me it couldn't be - the current public implementation of Blake-256 takes up 16k slices on a Spartan-6 LX150 - so it was definitely impossible to fit on an LX9. So I did. Performance is not going to be good on the LX9, of course - I'm using a Mojo v3 for testing. The real chip design is in developement, on my SoCKit - details on it here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=816&PartNo=1 - for larger chips and targeting the most hashrate I can get out of it. It's got a Cyclone V FPGA and ARMv7 dual-core on the same chip, and 1GB of DDR3 connected to the ARMv7 side, with the other 1GB connected to the FPGA. It has TONS of wonderful things onboard to program - I've already played with the software side of it, compiling the kernel with Altera's patches, compiling the preloader and u-boot, and putting Arch Linux ARM on it - but now I'll be working with the FPGA more, and connecting the two together.

It can be a fully self-contained miner, too; here's just a short list of fun ideas I've had so far:
 - Using the onboard LCD to output hashrate
 - Reading temps off the sensor and displaying that
 - Connecting some of the buttons/switches to start/stop hashing
 - Lighting an LED when hashing is enabled and turning it off when disabled
 - LED flash on share found
 - Using hardware interrupts to notify the CPU of shares
 - Putting the ARMv7 into low-power mode while mining

The last two kind of help each other - you can signal an interrupt from the FPGA, and handle it in your own Linux kernel module, passing it to the userspace miner, and letting it check and submit, if need be. The advantage here is no need for polling, which reduces shit the CPU has to execute - add that to enabling the low-power state and it could be awesome.

this is where the proof of work will be in the mining capabilities ...

you are leaps ahead of people in the same arena - and if this was setup on a production basis - it would be able to make a huge sum of cash for you mate ...

im in - where i can fit and where i can help with that ...

#crysx

[thefix]

Finished adding the other half of the block header not shown earlier to the output of the tests - putting in the final XOR with input block stage of Blake-256 that I forgot about when testing, in order to make it a full Decred process that will work, and porting tests to match. Also changed protocol to something more Icarus-like, in preparation for CGMiner support, and changed some stuff in the core transform, helping me drop slices, making the design smaller.

Previously, slice usage was ~1,300 out of the LX9's 1,430. Dropped it to 1,205 in this latest synthesis, but that isn't yet enough free logic to allow me to speed it up yet, I don't think.

Sounds promising, do you expect similar kind of speeds compared to other Blake algo coins on FPGA devices? I am also curious if you are using a more modern readily available FPGA device?

Backstory is, this implementation was done simply because people kept telling me it couldn't be - the current public implementation of Blake-256 takes up 16k slices on a Spartan-6 LX150 - so it was definitely impossible to fit on an LX9. So I did. Performance is not going to be good on the LX9, of course - I'm using a Mojo v3 for testing. The real chip design is in developement, on my SoCKit - details on it here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=816&PartNo=1 - for larger chips and targeting the most hashrate I can get out of it. It's got a Cyclone V FPGA and ARMv7 dual-core on the same chip, and 1GB of DDR3 connected to the ARMv7 side, with the other 1GB connected to the FPGA. It has TONS of wonderful things onboard to program - I've already played with the software side of it, compiling the kernel with Altera's patches, compiling the preloader and u-boot, and putting Arch Linux ARM on it - but now I'll be working with the FPGA more, and connecting the two together.

It can be a fully self-contained miner, too; here's just a short list of fun ideas I've had so far:
 - Using the onboard LCD to output hashrate
 - Reading temps off the sensor and displaying that
 - Connecting some of the buttons/switches to start/stop hashing
 - Lighting an LED when hashing is enabled and turning it off when disabled
 - LED flash on share found
 - Using hardware interrupts to notify the CPU of shares
 - Putting the ARMv7 into low-power mode while mining

The last two kind of help each other - you can signal an interrupt from the FPGA, and handle it in your own Linux kernel module, passing it to the userspace miner, and letting it check and submit, if need be. The advantage here is no need for polling, which reduces shit the CPU has to execute - add that to enabling the low-power state and it could be awesome.

That SoCKit is pretty amazing and the price is not bad to boot

The Mojo 3 is a really inexpensive board for testing, I remember they thought about using it with VNL coin but it had really bad hash rates.

Sounds pretty exciting and I will be interested in your progress

What kind of power draw is the device pulling and how much do you expect to save in low-power mode?

Thanks again for the info and link to the SoCKit

[Maicol792]

Finished adding the other half of the block header not shown earlier to the output of the tests - putting in the final XOR with input block stage of Blake-256 that I forgot about when testing, in order to make it a full Decred process that will work, and porting tests to match. Also changed protocol to something more Icarus-like, in preparation for CGMiner support, and changed some stuff in the core transform, helping me drop slices, making the design smaller.

Previously, slice usage was ~1,300 out of the LX9's 1,430. Dropped it to 1,205 in this latest synthesis, but that isn't yet enough free logic to allow me to speed it up yet, I don't think.

Good work Wolf0 ... You arte a Legendary of optimization

[kneim]

Any guide for pos mining

If this shall be a question, take a look into the official decred forum: https://forum.decred.org/forums/proof-of-stake-mining/

[bearex]

Any ideas of the BIG buy order (50BTC) at about 0.004 mark at Bittrex? Also, what caused this increase in price and will it be permanent?

[badam]

Any ideas of the BIG buy order (50BTC) at about 0.004 mark at Bittrex? Also, what caused this increase in price and will it be permanent?

The price rise was caused because of the fact that decred is a very promissing coin. Also never trade on suggestions made in forums or trollboxes. Do your research such kind of questions are useless because you will either get trolling responses either hyping responses. Do your research that's my best answer for such questions

[badam]

As of 2016/2/12 there are left 2163 airdrop addresses unspent. ~27% of Airdrop receivers moved their coins
As of 2016/2/13 there are left 2143 airdrop addresses unspent. ~28% of Airdrop receivers moved their coins
As of 2016/2/14 there are left 2118 airdrop addresses unspent. ~29% of Airdrop receivers moved their coins
As of 2016/2/15 there are left 2093 airdrop addresses unspent. ~30% of Airdrop receivers moved their coins
As of 2016/2/16 there are left 2069 airdrop addresses unspent. ~30% of Airdrop receivers moved their coins
As of 2016/2/17 there are left 2051 airdrop addresses unspent. ~31% of Airdrop receivers moved their coins
As of 2016/2/18 there are left 2036 airdrop addresses unspent. ~31% of Airdrop receivers moved their coins
As of 2016/2/19 there are left 2034 airdrop addresses unspent. ~32% of Airdrop receivers moved their coins
As of 2016/2/20 there are left 2024 airdrop addresses unspent. ~32% of Airdrop receivers moved their coins
As of 2016/2/21 there are left 2017 airdrop addresses unspent. ~32% of Airdrop receivers moved their coins
As of 2016/2/22 there are left 2000 airdrop addresses unspent. ~33% of Airdrop receivers moved their coins
As of today 2016/2/23 there are left 1989 airdrop addresses unspent. ~33% of Airdrop receivers moved their coins

[fenomenhaa]

I have still same too much rejects,tried with different diff.

Uh time-too-new is the old bug of the first cgminer versions. Make sure you use the latest version from the decred github releases

Yeah new cgminer fixed it, but at this time what's this?it's look lile poolside error.

[ocminer]

I have still same too much rejects,tried with different diff.

Uh time-too-new is the old bug of the first cgminer versions. Make sure you use the latest version from the decred github releases

Yeah new cgminer fixed it, but at this time what's this?it's look lile poolside error.

Did you try a higher diff port ? Looks like the pool isn't providing the work fast enough, yep.

[fenomenhaa]

@ocminer sure, already tried with diff 64 nothing change.

[ocminer]

@ocminer sure, already tried with diff 64 nothing change.

Okay I'll try to get some testing here done with my own rigs and let you know

[Iced]

I have still same too much rejects,tried with different diff.

Uh time-too-new is the old bug of the first cgminer versions. Make sure you use the latest version from the decred github releases

Yeah new cgminer fixed it, but at this time what's this?it's look lile poolside error.

Did you try a higher diff port ? Looks like the pool isn't providing the work fast enough, yep.

Try adding the following parameters to your launcher (or .bat)
--no-submit-stale --scan-time 2 --queue 0

[qwep1]

ocminer why it came with 8GH/s I got 8 coins for 24 hours and for 8 gh in hour I got 0.45 DCR why ?

[ocminer]

ocminer why it came with 8GH/s I got 8 coins for 24 hours and for 8 gh in hour I got 0.45 DCR why ?

Sorry I cannot understand your question, 8 GH/s for 24h should give about 9-10 coins when I compare with my rigs, maybe good or bad luck ? 0.45 per hour also estimates to about 10 coins per 24h so both results are pretty close to each other ?!

[qwep1]

ocminer why it came with 8GH/s I got 8 coins for 24 hours and for 8 gh in hour I got 0.45 DCR why ?

Sorry I cannot understand your question, 8 GH/s for 24h should give about 9-10 coins when I compare with my rigs, maybe good or bad luck ? 0.45 per hour also estimates to about 10 coins per 24h so both results are pretty close to each other ?!

what you config?

[ocminer]

ocminer why it came with 8GH/s I got 8 coins for 24 hours and for 8 gh in hour I got 0.45 DCR why ?

Sorry I cannot understand your question, 8 GH/s for 24h should give about 9-10 coins when I compare with my rigs, maybe good or bad luck ? 0.45 per hour also estimates to about 10 coins per 24h so both results are pretty close to each other ?!

what you config?

All 280x here .. all together about 10 GH/s  (9,5-10,2)