Bitcoin Forum

To give non-early adopters a chance, why not create a fork of p2pool that goes like this:
I have a pathetic amount of khash/sec. Now, some other miner has 1GHash/sec.
The system generates new blockchains - like p2pool - every day or so, and the pathetic people mine on the low difficulty blocks, and the powerful people mine the higher ones - until eventually we hit bitcoin difficulty level, and everyone is rewarded. Rinse and repeat with a new blockchain. This way, much more people can mine and power the network, get something out of it, and everybody's happy! :)

What do you think?

what should we call it?


CommyCoin?

Just a fork of p2pool - not a totally new chain.  8)

Is it possible to remake the bitcoin protocol so it works more like Litecoin instead and screws all ASIC-miners?

the whole mentality of newcomers and mining is quite elementary and juvenile.


move your mind away from mining and try to see the light that shines from the face of bitcoin.

I agree with this guy

Giving people bitcoins is a result, not the purpose of "mining". Miners act as notaries witnessing transactions and get paid for their service. CPU miners are realistically unable to serve, so there's little reason to compensate them.

Well, you could compensate them for helping move these separate chains along... :P

Also - yes, if the whole network upgraded you could make Bitcoin be like Litecoin.

CPU mining friendly algos didn't play out as expected last time it was tried.

I've heard some IRC talks with people discussing whether it's even possible (consensus was an uncertain "maybe") but so far, no actual attempts.

I think it's just too early... Give it some time, someone will find a GPU/FPGA/ASIC hostile PoW :)

The reason for this has more to do with the tuning parameters used  for the scrypt implementation in scrypt based coins (1024:1:1).

Those particular tunings are not very high, and there is some question as to whether it was a serious attempt at a true CPU friendly/ GPU hardened coin.

Yes, I believe there is need for a CPU bound coin to allow new users without either the knowledge or equipment investment to start using crypto coins.

Face it, getting started is not easy. It is not easy to trade cash, use credit cards or any conventional means to buy coins. The process often involves using expensive wire services to send cash to small companies one has never heard of who often charge their own fees. I doubt any of us has the capital to start a business that would be capable of absorbing the cost of reversed transactions on non-reversible crypto-coins to solve the issue.

A CPU bound coin would allow easy entry as mining would be easier and could be as simple hitting a button in the client.

Hash rate as it relates to securing the block chain is relative.The best example is comparing LTC and BTC. Network Hash rates are still measured in M/H for LTC while BTC is in the G/H range (Due to the scrypt algo, LTC mining is about 1024x slower)


Anyway, this nothing I have not said before and I am experimenting with a coin whose concept includes using dynamic scrypt tunings along with PPC based difficultly algo.

However, my time becomes more limited, so it will probably be a decent time out. I also see a market that is literally overflowing with new coins and see the need to wait until the market thins out a bit.

If anybody is able to bring a cpu friendly/gpu hardened coin to market before myself, which I find likely, I would help to support it 100%.

Doesn't seem like it's possible to do that unfortunately. When it can be done on a general purpose CPU, it can be improved to do on more specialised hardware.

Great idea on paper - but I want nothing to do with it. 

Well, if this ever makes its way into an implementation, it'll at least be better than starting yet another cryptocoin... ;)

You can already do this now.  There are plenty of alternative chains to choose from, and you can also create your own.

Here's the useful idea for an effectively CPU-only coin: use 80-bit extended floating point arithmetic to compute several iterations of a chaotic system, e.g. http://en.wikipedia.org/wiki/Chua's_circuit or http://en.wikipedia.org/wiki/Lorenz_system . Sandwitch those between the first and the second SHA-2 computations.

Implementing a full 80-bit FPU is quite complex and resource intensive. Moreover, the implementation is unlikely to get faster than a dedicated hardware implementation inside Intel or AMD CPUs. No existing GPU has 80-bit floating-point arithmetic implemented. And future GPU-style computational accelerators most likely implement 128-bit extended precision, not the 80-bit version hailing from the historical 8087 coprocessor.

Quite obviously it is impossible to completely prevent FPU or ASIC implementation, but the money and time required to implement a copy of 80-bit FPU conformant to IEEE-754 is several orders of magnitude higher than re-implementing e.g. scrypt() or anything else discussed by the cryptographic community. In particular there are no pre-existing complete implementations that are open source or free from licensing encumbrances.

The main obstracle is that unfortunately you'll have to spend some time to make sure that you aren't implementing a coin that forks into an AMD-coin and an Intel-coin. There are known differences in the implementations of transcendental functions between those two vendors. You'll probably will have to limit yourself to using the +,-,*,/ operators and square-root,reminder and the two BCD conversion operations.

This problem already has significant research available, but not in the context of a Bitcoin variant but in a context of verifying the results of numerical computations.

http://stackoverflow.com/questions/13102167/do-fp-operations-give-exactly-the-same-result-on-various-x86-cpus/13102431

http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf

Although this will not yield truely CPU-only coin, the coin will be CPU-only for several years, probably about 3 or 4. On the other hand implementing the numerical http://en.wikipedia.org/wiki/Chaotic_map in an x87 assembly language will take at most couple of weeks.

Would it be possible to make a coin that could only be mined if you had SSE instruction set 1,2,3, etc? As far as I know no GPU would be able to decode something that required one of those instruction sets.

Nope, I already used that name (sorta) for my idea.

There are already several chains that you can mine effectively with a CPU, so people who want to use CPUs for mining have plenty of choices available to them. There does not seem much point creating more chains since those people are already not bothering to mine the several chains that are still easily accessible to CPUs. Maybe when all the existing chains have their difficulties too high for CPUs to be feasible the idea could be revisted but right now for example if you have a few cores you can still mine BBQcoin, and even with just one core old pentium or whatever slow ancient computer you can easily mine Tenebrix or GeistGeld. Plus there are more too that are slipping my mind right now I expect.

So go mine the ones already provided, they could do with some more CPUs mining them...

Heck I think i0coin might be easy enough for CPUs again right now too. Not sure about coiledcoin, check that one too and see...

-MarkM-

Wait, so any subsequent scrypt-based coin can be released to be, say, 10x harder on GPUs?

What happens when one of these coins gets a revival through CPU mining?

Difficulty skyrockets when a few GPU's start mining them again.

All those coins are useless as a CPU coin, as soon as they see a rise in value, GPU's will quickly knock CPU mining out of the market.

This doesn't make sense: the code has to be open source and therefore any competent programmer could rewrite it from SSE/AVX/etc. to the vector instructions of the GPUs. And the GPUs are much faster at single- and double-precision floating point (32-bit and 64-bit).

The thing that handicaps GPU is the extended-precision (80-bit) floating point. It isn't impossible to emulate it on the GPU, its just that the results will be significantly slower and will require significant development effort that will be of little use anywhere else.

There are various quad-float (128-bit) libraries is where the multiple-precision floating point development work is geared.

The thing that cripples GPUs is the lack of significant memory per thread on the video card.

Have a scheme that uses scrypt and requires 2GB per thread (or even as little as 256MB per thread perhaps) and your quad-core CPU with 8 GB of RAM will beat any video card. The GPU can do many threads, but they aren't very fast. Attach large memory requirements to each thread and the GPU (as well as FPGA and even ASIC) is dead in the water.

This is only GPU-defeating. FPGAs will trivially beat that, not to mention an ASIC with eDRAM instead of DRAM. Or there already may be an existing SoC-s with ARM CPU attached to sufficient eDRAM, but almost all of them are under NDA. All of those will massively beat Intel/AMD on power efficiency and easily compete on speed.