Bitcoin Forum

Some of you like to see an altcoin that is truly GPU,FGPA,ASIC resistant. We would like to see such a coin too so we have started experimenting. We are working on the hashing function right now. It's radix sort based. We use 64 random numbers between 10000 and 75536 (16^4+10k). This 512 char long decimal number is the 'key'. (If we subtract the 10k on each number block and convert it to hex, it's a 256 long hex string in total [or in other words: 1024 bits].) We then change each number block with a specific simple math function and radix sort them by LSD. This gives us a 'hash' (same structure as 'key'). Using a difficulty is already in place. The above explained process for getting a hash out of a key is also depending on the difficulty. The higher the difficulty the more often the hashing has to be done before getting back a hash (simply said). Validating a hash is based on simple math functions depending on the difficulty. The higher the difficulty the less hashes are valid (simply speaking).

I just want to make sure we are on the right track with this.

Possible improvements: I would like to implement tacotime's mentioned tree search algorithm in topic 64239 (https://bitcointalk.org/index.php?topic=64239.msg786472#msg786472). But it has to be implemented in a way the search is mandatory and that's very hard to do. We may also should use radix sort MSD and LSD instead of LSD only. What do you think?

Do you have any idea what we should change/add to the hashing function?

We are aware of that but it's difficult to truly achieve it. You can't just implement some IP restrictions and think it's done. There is much more about this to do. It's a point for later. First of all we want to get the hash function CPU 'friendly'. Any other 'restrictions' will be included after that.

primecoin did this in a way with the early client issues - high-end systems did not outperform $40 CPUs by much. Maybe smuggle in some hard-to-find bottlenecks for the launch.

Why not use Scrypt as intended.  Scrypt with default variables has beyond horrible performance on GPUs.  Litecoin developers modified it to make it roughly 128x less memory resistant (using only 128KB total).

Generally rolling your own crypto ends badly.

I'm not a scrypt expert. It's new to me that with the default values it's truly GPU resistant. As far as I understand, it's not that the operations aren't hard to be done by GPUs itself, it's just that enough memory is necessary for a certain scrypt hashing (depending on the used values of course). So with enough RAM a GPU should outperform CPUs like they do it on SHA256, no matter what variable values are used. Correct me if I'm wrong.

what are the scrypt default variables?

From what I heard scrypt miners use the L3 cache of the GPU/CPU, not the RAM. Could it be possible that if enough memory has to be used the performance difference between GPUs and CPUs disappears?
Also, an algo favoring lots of RAM could be interesting, if one exists.

exactly!
I made somewhere point on this forum that there should be coin that uses for example 16GB of RAM so that we cant implement this in gpu ?
Or more likely cant do ASICs hmmmm or meaby not :D

Anyway coin that would require at least 8GB memory would be nice alternative :)
Based od AES ? (i7 have hardware acceleration) ?

It would possibly add some botnet protection too, as users are much more likely to notice a process consuming all their memory.  ;D

Most important question is WHY? Why would you design a coin that would be botnet friendly and ASIC resistant?

Every coin so far is botnet friendly. Read this: http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet_operator_ama/
I imagine a botnet resistant coin to be a big success.

You could make it a QtGui only app which would eliminate running from a console (as much as I hate the sound of that).
Of course, someone competent could just code in a daemon after the fact...

+1 GPU coins aren't resistant to botnets so this is nothing different. I hope that the coin has rather unique things that will make it stand out from the rest  8)

Hash, LSD... MSD I never heard of but presumably you should throw a crack | into the mix or something. Will this be traded on sr? Not sure I like this.

While bot nets are a moral issue (other people are having their electricity bills increased and their hardware lifespans shortened), this is really no difference on a macro-monetary scale.  Bot nets have a defined cost per Mega Hash and owning your own mining equipment has an amortized cost per Mega Hash.  So your still expending USD resource to create coins which is all that the economics of mining care about.

Most botnets have complete access to Windows machines; running a windowed application completely hidden is a trivial exercise.

Right, the lcache is used in scrypt. Reading to and writing from the RAM would be too time intense. So forcing the process to use enough memory does it make harder for GPUs,FPGAs,ASICs to outperfom the lower processors. Anyway: I think you guys are missing the point here. For getting a pure proof of work mechanism done there is no need for an enc/dec function like scrypt. It can be done with simple hashing (what we are looking for). Of course it's interesting to see how scrypt makes the processing cache intense and it may be something we should include in our hashing function too. The GPU resistance should not only depend on simply high memory usage. We should have a hashing function that includes several different ways to make it CPU friendly. The question is still the same: Anything else than radix sort we should include?

Related to the botnet and co resistance I've already mentioned that this is a topic for later. Having a good enough hashing function has to be done first. It's about getting this done step by step. Don't expect another useless altcoin that just clones an existing one with little changes in it.

Unless people start making custom boards for their GPUs (and RAM for GPUs is very expensive), high RAM usage is the way of making parallelization difficult.

Scrypt's RAM usage grows linearly with the number of rounds. Each round requires roughly 128 bytes of RAM (with block size parameter and parallelization
 parameters set to 1), so Litecoin's 1024 rounds require 128 KiB. Bump the number of rounds to 10478576 and it will require 128 MiB. A 7970 video card with 2048 shaders but only 3 GiB of RAM could only use 24 of its shaders.


Meh. Every computer has a CPU, but only a tiny fraction of them have dedicated GPUs.


While scrypt uses Salsa20/8 (an encryption algorithm), scrypt itself is not reversible and, therefore, not encryption. Scrypt is designed as a key derivation function and can be used as a deliberately slow hashing function.

I sympathize with the concept, but making things harder just for the sake of it seems counterproductive. So many wasted cycles & electricity. Id like to see more coins that do useful work, like Primecoin, creating a social value while doing work. I don't care if it's just calculating a big fractal or something, but I'd like to see all these resources devoted to something real.

Seems counterproductive in your explained view. Don't get me wrong: I like the idea of actually producing anything 'useful' with the hashing power like your mentioned primecoin is doing (i'm mining XPM btw). But besides that it's still about getting coins out of mining and we don't want certain people to have an advantage against others in that game. Therefore a CPU friendly (and of course 'botnet/server farm' resistant) coin may is the right way to go. We would love to include calculations in the proof of work algorithm that brings what you have called 'a social value' but we don't want to loose the mentioned focus in it. If it somehow can be combined, just let me know..

Separate securing the network/ledgers/transactions from handing out minted coins.

The securing part should be as low energy as possible, maybe do it like Ripple claims to, if nothing else maybe you'll help discover a flaw in Ripple's proposed method.

For handing out coins, employ people. Rich folk can hire people, true, but at least that creates jobs.

Because really the whole CPU vs GPU vs FPGA vs ASIC is rooted in people, not in hardware at all. It is all about the politics sociology etc of who profits from the hardware, who has easy access to it and such, not about the hardware itself per se.

-MarkM-

I doubt botnet resistance is possible, unless you make it such that normal people can't take part with their PC. You want broader participation for a coin to have better chance of success.

The 1% are only 1%, that is not broad.

Appeal to the starving, the children, the outcaste, make it unappealing to the rich, the well fed, the well-to-do at first, so that its appeal to them ends up coming from how many millions of people they can sell their howerver they got rich well fed etc to by adopting this currency that all those potential customers, who are currently ignored due to having no money, can become customers by means of once they have been given money by this method of giving money only to those who so desperately need it that they are willing to sit down 16 hours a day doing Turing Tests, or whatever...

-MarkM-

You wouldn't need 6GB.  The latency on main memory for a GPU is horribly bad so bad that any process which needs random access to GPU main memory will be annihilated by a CPU in terms of performance.  GPU memory is designed to stream textures and as such it couples massive bandwidth with extreme latency.  Scrypt was designed to fill the L3 cache of a CPU.  The developers of alt-coins had to intentionally lower the memory requirements by 99% to make GPU competitive.  Yes Litecoin and clones use about 128KB of cache.  The MINIMUM memory requirement for Scrypt is 12MB.  It doesn't take 16GB.  Try it out yourself or check out various hacking forums the OpenCL performance for Scrypt (2^14, 8, 1) is beyond pathetic.  A cheap CPU will run circles around it.  

Of course this makes it optimal for botnets so maybe a higher memory requirement (say 4GB/8GB) may be an idea so that it requires a relatively high end computer.  Scrypt is configurable you can make the scratchpad as large as you want (even up to TB of space required). It would be trivial for enthusiast to add more memory/disk but I imagine the average botnet node is a relatively weak/older system.  The % which have 4/8GB or more of main memory are probably small.  One could even design the algorithm to become more memory hard over time (i.e. double memory requirement every 2 block years).

The lowest cost method is a centralized ledger.  That is the PayPal/Ripple/Federal Reserve method.  Securing a blockchain in a decentralized will always involve a cost.  Maybe it won't be an electrical cost, maybe it will be a different kind of cost but a cost is inevitable.

So you're categorising Ripple as a centralised ledger? Maybe a store-and-forward network or other distribution network of a centralised ledger, but in essence a centralised ledger?

I am not disagreeing just seeking clarity.

Where is the line between a centralised ledger and any consensus, once it has been reached?

Cannot one simply consider the aggregate of contributors to the consensus as a centralisation?

Like, if consensus is reached so certainly by ASICs that GPUs etc really cannot sway it, it is really a centralised ledger whose centre lies in the ownership/control of ASICs?

-MarkM-

I said "broader". That's a implicit comparison of 2 scenarios where in one, most PC today can take part, and the other where more specialized hardware is necessary. An advantage of CPU friendly coin would be more people can get decent mining results with the PC they already have, hence more people can take part easily.

Besides, what does "the starving" have to do with this topic?

I think Primecoin looks to be a very CPU friendly coin. 

I would call it a distributed centralaised ledger.  This may seem an oxymoron but the point is that there is a redundant network of ripple "servers" (not be be confused with client nodes) however the server source code remains closed source and only OpenCoin or agents of OpenCoin run the servers.

I would liken in to a private content distribution system being distributed but still under centralized control.  The advantages are no need for mining, no need for proof of work.  What the centralized network says is the status of coins is the status with no appeals or overrides.

There is no need for "proof" because all servers are trusted authorities.  They are all run by the same entity and there is no reason or scenario where they will provide conflicting ledgers.   At a high level one could say the purpose of "proof of work/stake/etc" is to resolve conflicts in the consensus.  There will never be conflicts in a distributed centralized network.

Hence eMunie, it heavily relies on Hard Drives, instead of CPU's and GPU's

Because forget a PC, think a smartphone or handheld. Who even has desktop machines anymore other than geeks?

-MarkM-

Oh you are confusing the company-operated network based on the Ripple protocol with the protocol itself.

I was meaning the proposed consensus mechanism, the protocol, not the control-freaks currently reneging in releasing the source code.

If they don't release code that doesn't necessarily mean the actual protocol proposed cannot work, does it? Or is their failure to release the code maybe because the protocol is bullshit, they actually are having to not really do it as described because as described it cannot work, the whitepaper or whatever description of the purported consensus is just smokescreen flim flam or something?

If the approach works, then even if new code has to be written from scratch to implement the approach in free open source form it could be done, right?

So i am not on about some specific proprietary software that implements the protocol but the actual purported protocol...

-MarkM-

I think the latter.  In looking at the white paper, FAQ, and wiki there are some significant "issues" with their explanation of achieving consensus.  Of course it "might" work but the devil is in the details and being closed source there is no way to expose those details to sunlight.

So it is more like "trust us it works, the magic black box says so" and "at some point in the future which will not be named and may change at our sole decree" we will let untrusted people run servers because it won't be a problem.  If you have doubts see the first quote.


Well we don't know it works.  As described I see a lot of potential issues.

Just one example:


Ok so in the event two or more nodes (servers) disagree consensus will be acheived by a deterministic algorithm.  The conflicting transactions will be sorted by hash order and the included in order until tx can't be included due to conflict.

Ok so I am going to send you coins, I generate tx until I make one with a high tx hash.  I then double spend it with a tx to myself that happens to have a low tx hash.  If I can ensure that no consensus is acheived (partial sbyill) attack then the deterministic algorithm will always pick my double spend over your tx

As described this is a massive vulnerability, one sure to be exploited once the server source code is open sourced and anyone can run a server (or 10,000 servers in a botnet). Now maybe the FAQ is just incomplete but since the server source code is closed source nobody can say for sure how weak this is.

https://ripple.com/wiki/Consensus

This begs the question: Was this known to the devs of Litecoin and/or Tenebrix? I mean, why else did they intentionally lower the memory requirements? Big scam after all (hurr durr gpu resistant)?

I have never got a satisfactory answer.  I will point out that it is intentional though.  The default parameters for Scrypt are (N=2^14, r=8, p=1), the parameters used by Litecoin are N=2^10, r=1, p=1).

I am not sure if was a scam but the end result is the same, Litecoin is 99% less memory hard then the default Scrypt and about 1/7000th as memory hard as the parameters recommended by the author for high security (not realtime) applications.

You are reading it, or reading into it, differently than I am.

Specifically, you do not mention what I had thought was fundamental: that if two disagree neither of them get in, because only consensus gets in.

You seem to assume being earlier in the queue, whether by high hash or other ordering / collating sequence, gets you in.

In my concept of the protocol, that only lets you not get disqualified yet; once a conflicting item does get looked at, boom, you and it both get disqualified as not being in consensus with each other.

So if the processing can catch up to the whole queue, it is left with all current items that do not conflict with each other and a bunch of chaff consisting of items that conflict either with history (already done-deal blocks / timeslices) or with other items currently up for consideration.

So to get in ahead of an item that contradicts your item you have to get the processing node to strike either your node or the node that sent the item that conflicts with yours from its trusted nodes list. it comes down to one of those two nodes is lying or if both items arrived from the same node than that node not winnowing out the chaff itself before passing items to me.

Until my user tells me which node to trust over the other node, i have to assume both nodes are compromised or they are not both in the same actual network of trust.

So unless my user specifically tells me to always trust the beagle boys, or at least to always believe them over scrooge mcduck, I have to just figure both have some problem in that they seem unable to reach consensus with each other...

As for 10,000 server botnets, if I have told my node that both the beagle boys and scrooge mcduck being in consensus is a significant consensus, but I have never even admitted to my node that I know any of these 10,000 bots, they only count at all if they can convince both the beagle boys and uncle scrooge of their version of reality...

-MarkM-

I'm working on this too and the problem I'm anticipating is that it will take time to verify the hash. The performance I'm seeing running scrypt to require 256MB of memory is a hash time of at least 0.5 seconds . . . . time increasing linearly with memory required . . that's not so bad for mining where you can just have a low difficulty, but creates a problem for clients verifying the block chain - it makes it a slower process, and could start to bite as the block chain gets longer.

I'm working on this same problem, and I think you're taking a viable approach. You might want to hash on the way into your function and on the way out so you don't need to worry about cryptography and focus on making a GPU resistant algorithm.

Hash = SHA256(MAKEWORK(SHA256(Block)))

Where MAKEWORK is your GPU resistant algorithm.

Some interesting stats here -
https://github.com/floodyberry/scrypt-jane

If I'm reading these correctly, they confirm my tests that it takes about 2 seconds per hash per GB memory required on a modern processor.

Interested to know what you think would be a good memory requirement/time tradeoff to resist GPUs but maintain a good block validation time.


Yacoin? Nfactor started a little low though.

FreeTrade: Thanks for your input and it's nice to see other people working on that too. We may should exchange our results. I like to do the programming very low level for that purpose. While assembler is a little bit too freaky and time intense to code with, we are doing it on very low leveled c. P.e.: We don't use any strings at all yet and just std math operations besides the radix sort. Your mentioned SHA hashing doesn't make sense within the proof of work algorithm itself in my eyes. The created algo has to be as good as the well known hashing operations in terms of irreversibility and unique hashes anyway and then nothing else is needed around it. I think our current mechanism is already very good in terms of that.

Artforz said in one of his last posts on this forum that the verification time is the reason you can't jack up the n values.


The guys who maintain YACoin disagree with artforz and tacotime's position.  They claim that verification time is not a problem based on their testing.




Here are the benchmarks from mtrlt, who was the first to write a GPU miner for litecoin.  He switched to mining YACoin because it was more profitable for him.  Now he is writing a GPU primecoin miner apparently, but I haven't paid attention for a several months.


TacoTime asked if he had played with the lookup gap, and he said he had played with it quite a bit and couldn't get it to mine faster.  You can see here that jacking up the N value DOES make GPU mining substantially less effective relative to the CPU, and apparently they are not having problems with verification times.  YAcoin switches to N=8192 on August 13th.  You should probably get WindMaster in here to comment.

Both Litecoin and Bitcoin have had large botnets mining them early in their histories, and it hasn't been any huge security issue as far as I remember.  The legitimate miners eventually outnumber the botnets.  I will agree that if anything can reasonably done to prevent them from mining, it should be done because the whole point of a CPU coin is to get a better initial distribution of the currency, and having tons of CPUs all linking to one person is bad for that.

Just a driveby thought.

I am under the impression that the vast majority of botnet machines are windows XP 32 bit.

Therefore, make it 64 bit only, or make minimum memory requirement 3.5 GB or wherever the cutoff is for what XP handles.

Seth - thanks for compiling all that history and summarizing the position on this with the different altcoins. Here's my take . .

>Artforz said in one of his last posts on this forum that the verification time is the reason you can't jack up the n values.

This is true to an extent . . . but Litecoin's N values could have been a lot higher before that became an issue.

If you look at the following chart -
http://yacexplorer.tk/graphs.htm

Litecoin has an Nfactor of around 8 . . . you could go right up to 17/18 before you see a problem with verification times. Most CPU users can verify those blocks faster than they can download them.

>The guys who maintain YACoin disagree with artforz and tacotime's position.  They claim that verification time is not a problem based on their testing.

It may not be a problem, but that will be based on their timeframe rather than their testing. They're expecting faster CPUs and memory to reduce the time as the NFactor increases. NFactor 20 takes 0.5 seconds now, who knows what that will be in 2020. But Yacoin was handed to the GPU miners, so I don't see it even tried to be GPU resistant. It would have been interesting if it had started with an NFactor of 15 or 16. As it is, it'll take a year to get to that point.

I like CPU friendy coins  :D :D ;)

In case anyone is curious, here is the thread with the speculation that Coblee and Artforz knew litecoin was not GPU hard and were mining it with GPUs from the start.

https://bitcointalk.org/index.php?topic=63365.0

I think it is funny that now ignorant litecoiners are the ones saying "cpu coins will get ruined by botnets", when the whole point of litecoin was to be a cpu coin in the first place.

Here is another thread where Coblee suggests changing litecoin's proof-of-work to something more GPU hard after a GPU miner was proven to exist.  TacoTime suggests a radix sort at the end of the thread, and then nothing was done to change it.

https://bitcointalk.org/index.php?topic=64239.0

Most litecoiners have no idea this happened and continue to promote a coin that already has 19 million coins mined in a way that is most likely a massive deception.

There is definitely some room for a CPU coin.  I would recommend signing up a few merchants and coming up with a method to pay for stuff like electrum support, phone wallet support, and exchange support before launching it.

I recall seeing a coin launched within the last two weeks that claimed to use 6 different hashing functions.  What was the problem with that one?

That was Quarkcoin, and I quite like that one. There's also Primecoin which I think might turn out to be more GPU resistant than some had imagined.

I have followed the whole CPU vs GPU debate since it started, and nowadays it has been looking more and more clear to me that we really should try to keep securing the network separate in our minds from initial distribution of coins.

Is there any big reason to force the ongoing securing of the network to have to be done by inefficient hardware?

Or would it be fine to leave that to the most secure and efficient method a given point in history allows?

(History of a coin itself not just the field in general; for example even if methods different from bitcoin's are more efficient changing bitcoin to use a different method at this point in its history is more than just a technical problem of upgrading to the latest technology.)

Suppose for example that Ripple's consensus method turns out to be both effective and efficient and its source code is released or a free open source implementation is built to circumvent its failure to release its source code.

Would it not be ideal to use such an approach to securing the network, leaving us with only the question of how to initially distribute its built-in ("native") currency?

Or would that make the problem of who even gets to be a node that actually matters too political or something?

Another possibly useful thought-experiment is to imagine we already have a fine and dandy initial distribution of the currency ready to go and are only worrying now about how nodes get to be nodes that actually matter. For this thought experiment how the initial distribution happens can be a black box, magic, how it works need not be part of our concern. Although I expect man people have various ideas how it might work. Some ideas I have i do not even want to mention before using them, since most such ideas can be gamed so part of coming up with them is thinking of something there was hotherto no good motive to game thus that are unlikely to have already been gamed in anticipation of being used.

(Forum accounts and email addresses and IP addresses for example people already have motive to have gamed / sockpuppeted, same for facebook accounts and such. But blockchain based things based on blockchain activities that cost fees would have cost people to have gamed ahead of time for years, would anyone have bothered if they weren't sure their expensive gaming was going to be rewarded someday by the launch of a coin that issues its new coins to people who had done those precise actions on that particular already-existing blockchain?)

Initial distribution of coins aside then however that gets accomplished... is there any big reason for all this anti-GPU, anti-FPGA, anti-ASIC stuff purely for the ongoing securing of a network / blockchain / ledger / transaction-set ?

-MarkM-

Ongoing distribution is a feature too . . in 5 years time will a user be able to get some of your altcoin by joining a pool and converting electricity into altcoin, or will he need to buy it from a third party. By ensuring CPU generation is efficient, we'll be able to ensure both the user can generate altcoin for himself, or have a local thirdparty who can.

Sure because it works.  POW has been proven to work.  POS is more efficient and is "close" to working but requires significant centralized control (checkpointing) something which may be improved upon in future versions.  You keep talking about Ripple as if it works. It doesn't or at least it hasn't been shown/proven to work in an open network where some nodes are malicious.   

If it works then great but why not cross that bridge when (never) you get to it.  My belief is that Ripple will never work in an open psuedo-anonymous network.  So anyone planning to go that route is planning to build a closed source, central authority coin.  The good new is it will be very efficient.

Okay but what about in 25 years time, 100 years, 100,000 years, etc?

Do we have to keep minting forever? it seems like part of the appeal of Bitcoin has always been that after the relatively brief initial 140 years or whatever during which initial distribution takes place we do eventually reach a point where that is all, we have reached the cap, the only way to get some now is to go into business earning them (including going into the transaction-processing business which is just one of many possible financial-services businesses one could choose to get into) or just outright buy some.

Transaction fees presumably do ensure that there will always be some for sale, even if they are being sold only for the specific service of processing transactions; but can a currency be a success, even only as a store of value, if that is the only product or service they ever get used to buy? If not then there will be other products or services one can buy the coins with, so transaction processing surely should have no special desirability it should become merely yet another product or service people can choose to go into business as a provider of.

So really unless your model is that a cap is bad, minting forever is needed, then this whole get the coins minted thing should probably be done rapidly, so that as soon as possible the world can reach the presumable long term equilibrium stage in which minting is long over, part of prehistory, and we get to see the real thing really running not just yet another "get in early to get rich" pyramid / ponzi / tulip-mania / IPO type project?

It does not seem unreasonable to question the division of motives, as in how much if any of the motivation is actually the goal of the long term stable state versus how much is the desire to launch yet another "get rich in 150 years or less" scheme...

-MarkM-

Markm, of course we could MASSIVELY improve upon bitcoin and get everyone to switch to a new coin if we designed one that was:
a) more efficient while still providing the same level of security
b) equally distributed to everyone on the planet in a decentralized way

The thing is, we don't know how to do either of those things yet.  If ripple is proven to work (unlikely), that could solve A.  B is virtually guaranteed to be solved within a few decades, but is impossible now.  Governments are reasonably well equipped to do an initial distribution to a population with minimal gaming of the giveaway mechanism, but it would never be decentralized.

By the time these things are solved, bitcoin's network effect is likely to be so large that even a more efficient and fair coin will not be able to displace it.

Btw, you cannot use events in the block chain to distribute an alt-coin because that would result in an even narrower initial distribution than bitcoin had.

I do not think it is practical, given the number of CPUs in existence and the projected numbers of things-that-can-do-a-CPU's-job going forward, to expect, aim for or hope for one person with one CPU, or even one person with one normal everyday everyone has one billion-trillion-CPU-equipped-handheld-device, to be able to earn any really useful fraction of the common weal / common wealth in any reasonable span of time by mere application of that device to well known familiar task(s) everyone knows full well can be done by such a device and has access to the program/app for doing.

There are many examples in history, even merely in the history of the internet.

Every fully automatic method of raking in money over the internet from home using your PC died a horrible death once someone made available a Windows binary GUI app for doing it.

Every single one, I am pretty sure?

Can anyone come up with one that didn't?

Even CPU-mining Bitcoin, which is one of the latest such things, died a horrible death once compiled GUIs for Windows became available to do it.

This whole thread is motivated by the same quest that motivated the spam ten million email address apps for Windows, the spam the newsgroups apps for Windows, the build a pyramid of marketers marketing for you apps for online marketers and so on and so on.

There are too many people, with too many PCs, dividing up pies that like ponzis and pyramids can only grow so large before the piece of pie each PC gets is too trivial to be worth doing.

Such things always (any counterexamples, anyone?) seem to get to a point where even just trying to keep up with trying all kinds of new twists on the same old ideas, join new launches of the same thing renamed/rebranded and so on and so on ends up making you less money per hour that you'd make simply solving captchas for pay or other "mechanical turk" type tasks.

I strongly suspect that even the time put into these discussions only seems potentially likely to pay off if you plan on being an "early adopter", one of the top of the pyramid / early entrant to the ponzi people who runs around making money off the suckers who buy into the scheme or buy the Windows app not realising the very fact that anyone with Windows can run it already means the thing the app does is obsolete. Selling the Windows app is pretty much the last resort, the last way to try to eke out a few last bucks from a wonderfully lucrative exploit that unfortunately too many people are exploiting for it to be worthwhile anymore for any one of them.

I realise I seem to be arguing that no one would sell shovels unless the shovels would dig them less gold using them directly or by means of employees than they make just selling the damn shovels. You sell the shovels once using them is no longer lucrative. Hmm. So I can see that I still need more insight.

-MarkM-

The model I favor is rapid distribution followed by a 2% inflation. I'll have more about this soon.

I thought about making my own clone, where all coins are given out after 1 year or so, calling it Finitecoin.  ;D

No need for a clone. Take a closer look at Infinitecoin. The name is a con to make people think it is inflationary . . but everything will be distributed within 6 months.

I've speculated about a protocol that might use the Peer-2-Peer network itself as a place of 'work'.  Block solving is done by daisy chaining together a number of signatures, the resulting hash then determines (randomly) what public keys are eligible to sign again.  The chain of signatures just grows as it bounces from node too node until it legally can be signed by its original creator to complete a chain-link, this makes the total number of signatures random.  The obvious weakness it that private keys are free so a huge number can be created to churn through, so an additional PoS signature might be needed with the chain-link requiring a cumulative total.  Also a small nominal coin cost to keep an address active would also be a good idea as it may make the mass address attack unaffordable, and it would likely have a stabilizing effect on valuation too.

I've also begun wondering if a more distributed chain is also something we want.  Rather then one monolithic chain, ever account is its own chain with each transaction being it's own block that requires both parties to sign, thus each transaction is a point were two chains share a block.  The only way to double spend is thus to create two forks of your private chain with two different people and preventing them from learning of each other.  By doing this daisy-chain proof you force the disclosure of all transactions to the network at large and eliminate mining-in-secret which is the object of any double spend.

Oh, didn't know that, that's quite an interesting experiment then.

Howabout reverse difficulty with reward doubling, time limited and proof of stake (So it's not last minute gazumped) gold at the end of the rainbow coin or something :D

Mark I agree that bitcoin's distribution mechanism is incredibly terrible.  I mean 99.99% of the world's population does not own any bitcoins and the distribution is halfway done!  Unfortunately, no one has been able to think of a better decentralized solution, and Satoshi was a genius to even be able to think of the one we have now.

Giving coins to everyone with a forum account or email address, while open to manipulation, still gives a WAY better initial distribution than mining does.  Ripple does this.  Unfortunately this method sabotages the ability to use proof-of-work to secure the network since the miners won't have any incentive to mine on a new network with few transactions if they don't get a block reward, so proof-of-work must be abandoned in favor of a centralized solution.

Just 5 or 10 minutes human input when a block is found. For example, the block hash could be used as
RNG seed for something like 1 small level of a very complex roguelike game.
Keystrokes to solve it are recorded and saved in the block chain as additional PoW.
Hard for computers, incomprehensible for 99% of all people (mechanical turk resistant),
and takes only a millisecond or so to check validity.

But I guess it would be difficult to implement in a way to make savescumming+bruteforcing inefficient for bot(net)s and
to require some human attention without making grueling working hours the best strategie.

If you can figure out how to set up decentralized proof of work where human input is required, you will be a millionaire.  Everyone will switch to your coin.

aerobicoin for webcam, hash encoded as dance and yoga positions.... followed by the copycat DDRcoin and wiifitcoin.

I think you guys are too concerned about fair distribution when what matters is free distribution.

With a fair distribution, everyone gets an equal share of the worlds coin. Even if you could do it, 99.99% immediately cash it in for something more familiar.

To bootstrap a cryptocoin economy, what matters is free distribution. That just means that those who want it can get it. With a genuine CPU currency, anyone with electricity, cpu and a network connection can trade some electric for coin.  

I consider it miners getting rewarded/paid for securing the network and processing transactions.

Okay serious suggestion, but only half formed idea..

Entropy, proof of work based somehow on production of entropy, thinking cellphones have built in hardware RNGs, then require some XORing with a software pseudorandom and hashing to add a bit of CPU make work...

but checking work may be difficult.

However, it could somehow improve encryption of transactions with having huge entropy pool to work with.

Thinking entropy sources are kinda slow and throwing more CPUs or GPUs into a system would not necessarily make it faster, would be a per system advantage.

Not sure of total resistance to custom hardware, but at the moment tending to think about the same cost for about the same speed, but power efficiency would be an advantage.

Anyway, for anyone thinking they want to get the world on crypto coins, something where cellphones might be equal footing with PCs would be good, where they've gone straight to cellphones, Africa etc.

But as I said, very half formed idea, needs massaging into something workable.

I don't believe it's possible to write an algorithm that a machine can't do but a human can.  Is there any evidence to the contrary?

Well that's in the definition of algorithm "An algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function."

If you take something that it's hard to define a algorithm for ...
http://en.wikipedia.org/wiki/List_of_NP-complete_problems

Then humans may perform more effectively at the task than computers, particularly if learning and experience develops an intuition for the task.

I think so aswell. A machine if not now, eventually will be able to do just about anything that we can come up with.

We can maybe incentivise the development of software to do things that currently seem best done by humans.

I have still been working with the game idea, basically stop trying to prevent people using scripts/triggers to run their chracters on auto, instead encourage that, hopefulyl to end up with much more interesting "non player characters" in the form of player characters being run by scripts 24/7 as a form of "mining" to disribute currency.

http://www.devtome.com/doku.php?id=cpu_mining

The current state of the art of scripts is such that they are quite primitive, and continue to get into situations they don't have a way out of in the code yet so require a human to put them back into a situation the script can handle.

The fact that this is also interactive means that even if/when scripts are are able to handle nice sedate civilised situations, it can all be made less predictable by any player at any time simply by messing up the situation to throw the scripted characters off script, or maybe even just dress up in armour, which none of the scripted characters are actually creating yet as part of their scripted activities as far as I know, and start taking a battleaxe to other people's scripted characters.

So I think it will be quite a while before one can run thousands of scripted characters reliably like a botnet owner would want to do, yet it so far isn't taking much time per player to handle a typical player-account of ten characters only five of which can be online at the same time.

This setup proved so popular we had to shut down signups, obviously people are going to create unlimited numbers of accounts if there is no cost to them to do so thus already we had to go to auctioning off accounts.

-MarkM-

Hmm...  something like a SP scenario in Battle for Wesnoth where the player is outnumbered 3:1 and
under time pressure/strict turn limit would qualify imo, if the (super smart botnet) machine doesn't know what the (dumb computer) enemy will do
next turn.

I.e. synchronize it with the block chain. 1 game turn per block (30 seconds or so), RNG is re-seeded with each block hash,
this way the game is deterministic, but only in hindsight.

To get any reward, you would need to solve a block, then post a "special" transaction
(containing keystrokes/player actions and a 1use privkey to prove the original block was yours)
no later than N blocks after that (N = turn limit)

If a machine can really be made to do this the game in question will get a whole lot better.
And we have an "AI-coin". Win-Win ;)

Awhile back I posted an idea for a "Human Coin". It would be tricky to create a coin that requires human intervention, but machine authentication.

Captcha coin? Perhaps one using NSA's list of keywords. ;D

The problem with a "human coin" is human labor can be purchased very cheap.  Large miners will simply be the people who have the resources and connections to run "mining sweatshops" in India, Bangledash, Vietnam, etc.  That will drive up difficulty and you have new users in the first world saying "WTF?  It takes an hours worth of work to produce 1 HumanCoin which is only worth $0.12".   Meanwhile some human-net operator is making $12,000 an hour using the low cost labor of others.

Yeah but so what? That first world "WTF" person can just go like holy shit $0.12 per coin, I can pick up lots of those for less than I pay for a tank of gas!

Its not as if sweatshop operators don't already have sweatshops, in fact at only $0.12 per coin maybe humancoin won't compete with making cabbagepatch jordan BB boots or whatever.

-MarkM-

Humancoin, bringing slavery into the digital age!

I also don't see the problem with this either.  If all that is required is a computer to mine "human coin" (or preferably, just a smartphone), the sweatshop operator's margin would be severely limited when all the sweatshop worker has to do is get access to a $50 smartphone to get 100% of his expected earnings.  I would expect that he would have to pass on at least 50% of the mining profits to the workers, possibly less if a computer costing hundreds of dollars was required to mine "human coin".

In a perfectly fair distribution where we equally allocated coins to everyone on the planet based on their DNA, the amount would appear to be quite small to 1st world inhabitants, who would buy up the 3rd world inhabitants' coins with their existing wealth.

Still waiting for this  8)

For what? CPU friendly coin already here, it called primecoin.

https://bitcointalk.org/index.php?topic=266999.0 - care to comment?

Whaat? Link.

dunno how heavily youre coin is based on radixsort but theres an example for it in opencl, so It's prolly not that hard to make GPU miner.
https://developer.nvidia.com/opencl#oclRadixSort

It's far away from being a coin. Thanks for the link. It seems I have to take a deeper look at current radix sort calculations for GPUs. Reading about it seems to me that radix sort isn't the way to go here in the long run. Scrypt with fixed parameters isn't very wise too in the long run.

Okay - so in case you hadn't guessed - this is now MemoryCoin. :) I think it is the first really GPU-Resistant Coin.

you people truly do not understand, you can use new methods but all you do is delay a gpu implementation. There is no such thing as GPU resistance and ASIC resistance. If the market and money behind any coin was large enough, all that would be in dev right now.

Obviously you cannot write an algorithm that cannot run on a GPU but runs on a CPU.  What we are concerned with is making the ratio as low as possible.

The memory route is scrypt.  The hard drive route doesn't work because you can have a million computers access the same hard drive.

All-

I apologize in advance for posting on an old thread.  The initial section of this thread is relevant to my question and I haven't found other forums with an answer.

For Litecoin, if memory size is increased in processing the Scrypt algorithm, for example to 384 kByte instead of 128 kByte (and assuming likewise an L2 cache size of 384 kByte), would the typical CPU architecture (x86, PPC, etc) be likely to see a corresponding increase in performance?

I realize that increasing BlockMix memory usage is not typically done on GPU architectures, for various reasons.

Thanks.

-Jeff

i know its of topic, but can you tell me what im doing wrong in my altcoin creation?  I generated a merkle and also a genesis, but I have 2 peers configured with each others IPs as per instructions but they just dont see each other.  I tried it 2x, i dont think I missed a step. was there something missing from instructions?  I picked some random base58 address, the instructions werent very clear at all, but seems like that bas58 address really wasnt that big of a deal.

no im not going to release this here, its for another forums site I frequent, just want to give everyone there something to mine as a fun thing / joke sort of thing.