Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If only we could harness the computational power wasted on Bitcoin mining as heat, for useful distributed computing.


The best you could hope for in an alternative proof-of-work scheme is a shift from dominating electricity costs and rapid hardware obsolescence to use of commodity hardware, dominated by memory latency instead of computation. That's what my Cuckoo Cycle PoW scheme aims for...

https://github.com/tromp/cuckoo

On the other hand, some people argue that reducing waste is counterproductive as it also lowers the cost of a history rewriting attack.

Ethereum's PoW, while requiring 1GB of memory for efficient mining, remains so compute intensive that it only runs well on GPUs. Its inefficiency on CPUs is a conscious design choice to deter botnets.


How is Ethash compute intensive relative to Cuckoo Cycle?

EDIT: Ethash does 1 SHA3 at the beginning, 1 SHA3 at the end, and 64 rounds of FNV1-32 x 32.

Verification considers the intermediate digest, so really 1 SHA3 to verify.

You do more SHA3 rounds if you don't store the dataset, but this is a memory trap-door (and would require ignoring the mixDigest); the verification cost is still negligible.

In our mining pools, verification of hash values doesn't even account for 1% of of our overall CPU consumption (and this is with Scrypt).

SHA3 is also far more lightweight than SHA2, and much more parallelizable.

EDIT #2: If we want to talk about weaknesses in Ethash, I'm not sure it is FPGA resistant, given many FPGAs have DDR iterfaces on die and the access pattern of Ethash is read-only.


"Compute bound" refers to proof generation (mining), not to verification. It looks like ethash does the following computations per random memory access:

        p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
        newdata = []
        for j in range(MIX_BYTES / HASH_BYTES):
            newdata.extend(dataset_lookup(p + j))
        mix = map(fnv, mix, newdata)
I admit this doesn't look much more involved than Cuckoo's single siphash-2-4, but perhaps we can measure it. How much faster does this run if you leave out the actual memory access. i.e. replace dataset_lookup(p + j) by (p+j)?

In Cuckoo Cycle's case, avoiding the memory lookups reduces runtime by a factor 3.


I'd say the biggest advantage if you take out memory access is not latency (since most of the time latency gets hidden via pipelining), but power consumption.

When developing kernels the amount of times memory is accessed has huge impact on power-efficiency, less on actual computational throughput (especially on GPUs), unless you hit bandwidth limitations (which right now Ethash does).

EDIT: NVM - you're asking about the comparison of FNV1 vs Siphash. I haven't analyzed Siphash but I can say that FNV1 is exactly 5 clock cycles on a modern GPU (4 for a 32 bit multiply and 1 for an XOR).


I had someone run some tests where ethash was accessing only 1KB rather than the whole 1GB of dag, and runtime fell by 40%. So that's roughly the fraction of time spent on memory latency in the single threaded cpu miner. That's less than the 67% measured for Cuckoo Cycle, but still rather high. So I should say that ethash is almost memory-bound, and certainly much more so than other memory oriented hash functions.


I don't understand this recurrent point: computer power is "wasted" almost everywhere. At least Bitcoin use this power to build a decentralized currency.


> computer power is "wasted" almost everywhere. At least Bitcoin use this power to build a decentralized currency.

Pinning a GPU or ASIC at 100% undeniably draws more power than an everyday user idling around Facebook on their Macbook Air (~21W MAXED, so likely 7W)

Whether it's worth it is the question.

A back-of-the-envelope calculation gives me $12Mn USD per day as the approximate global cost of electricity given the current global hashrate of 375Mn GH/s, for 0.05¢/kWh, assuming everyone is using reasonably modern, efficient (?) ASICs like a Spondoolies SP35 Yukon at 5.5TH/s for 3850W.

If that's for a $300Mn USD daily market, that's not particularly efficient. Nor particularly inefficient either, admittedly. Democratic, for sure ;)

EDIT: initially forgot to include some time units, thanks jsprogrammer!


> A back-of-the-envelope calculation gives me $12Mn USD per day

3600.00 BTC or $1m is paid as subsidy per day.

Are you saying that people are spending 12x that on power?

I dont think so.


Do your own calculation and see what you find, instead of think. This is HN after all. :)

You have all the relevant numbers in my post after all: maybe I made a mistake? That certainly possible :P, since you seem to be right about the rewards paid per day.

Or maybe people willingly factor in power costs as a price of speculating on a volatile, trending currency? Or maybe most power costs are actually carried in low-cost areas rather than North America and Europe, so my $0.05/kWh is an overestimate?


>$12Mn USD

per what?

This number is pretty meaningless without knowing what timeframe that amount of costs are incurred.


Oops, good save. Thanks!

It's per day. (I think. :P)

Today's average hashrate is ~397Mn GH/s, and I used 375 instead, to be conservative/fair.

https://blockchain.info/charts/hash-rate


The spot price of BTC has been steadily rising. Someone must be getting more than $12,000,000 USD / day in value out of it.


It's wasted relative to other methods (e.g. proof of stake, Stellar) that many people believe can provide close enough to the same properties.


You will be happy to know then that ethereum 1.1 will no longer use computational power for security. When ethereum 1.1 is released, the total electricity requirement of the network will drop by orders of magnitude.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: