defending ahead the p2p nature of bitcoin - blending hashcash & scrypt

[ecliptic]

Very interesting thread.

My background is 20 years of designing CPUs/ASICs/GPUs.

A few comments here:

1) There is no computational problem that you can't design custom ASIC hardware to do faster than a GPU.

Can we make a proof of work based on the mathematical principles used for rendering video games?  GPUs should be pre-optimized to this task.

Half joking.  But seriously?

x86/x64 CPUs are too unspecialised to have an algorithm made for them i would assume

[1713940266]

1713940266

[1713940266]

1713940266

[mmeijeri]

One consideration that I don't recall reading about before just occurred to me: in addition to having separate difficulties for the two hashing functions, we could also have different reward schedules. Depending on how you do it, this could either increase or decrease the potential controversy over a change in the rules, and help avoid a fork, which would be bad for everybody. If the scrypt-based hash didn't get any reward, it might not alienate the ASIC miners, while it would still give those running scrypt a say in the construction of the blockchain. To do this, you might want to adjust the difficulty so that blocks are created twice as fast to keep the BTC generation on the same schedule.

[mmeijeri]

Intel is adding new SSE instructions for SHA calculations to their processors. While this will not make CPU mining for its own sake profitable, it may make running a mining process in the background whenever your computer is on for other reasons a sensible thing to do. This should help a bit with keeping Bitcoin distributed. It would be nice if the same thing happened for GPUs too.

New Instructions Supporting the Secure Hash Algorithm on Intel® Architecture Processors