I understand that the developers are leaning toward a captcha based free distribution.

Still, I would like to make you aware of how automated captcha solvers work. I have also posted this in the Azulik thread.


There are two ways to automatically solve captchas: using OCR (for which complexity matters) and human solved (for which complexity is irrelevant).

The human solved ones make use of an API which distributes the captchas to people all over the world, who solve them manually and are paid for that. These are very cheap because they are solved by people living in places where that money is good money at the end of the month.

Potential errors are not relevant because the page is refreshed and you simply need to a good solving rate. Considering that this can happen continuously, a simple 50% rate is great, although it's much higher for the captchas used by RaiBlocks.

These automatic captcha solvers can also be run concurrently, therefore increasing the yield. It really is no different than a small piece of software generating proofs of work.

In fact, we might even be able to limit the generation of proofs of work by serializing them, by using a counter instead of a timestamp, and each proof of work would have to use the previous proof of work.

This would have to be combined with a registration process for the addresses that would be allowed to participate in the free distribution; for example, between dates X and Y, the users registered on this forum could send you their addresses (one per user); maybe also require a minimum number of posts per user.

There are two ways to automatically solve captchas: using OCR (for which complexity matters) and human solved (for which complexity is irrelevant).

The human solved ones make use of an API which distributes the captchas to people all over the world, who solve them manually and are paid for that. These are very cheap because they are solved by people living in places where that money is good money at the end of the month.

Potential errors are not relevant because the page is refreshed and you simply need to a good solving rate. Considering that this can happen continuously, a simple 50% rate is great, although it's much higher for the captchas used by RaiBlocks.

These automatic captcha solvers can also be run concurrently, therefore increasing the yield. It really is no different than a small piece of software generating proofs of work.

In fact, we might even be able to limit the generation of proofs of work by serializing them, by using a counter instead of a timestamp, and each proof of work would have to use the previous proof of work.

This would have to be combined with a registration process for the addresses that would be allowed to participate in the free distribution; for example, between dates X and Y, the users registered on this forum could send you their addresses (one per user); maybe also require a minimum number of posts.



The following would be a possible way to do it:

The process is similar to mining, but very limited in time (and therefore energy) and without the immense complexity of implementing mining into the cryptocurrency itself.

Make a small desktop application which generates a proof of work by using a memory-hard hash algorithm, like Argon2d. The goal is to make CPUs as efficient or more efficient than videocards and ASICs.

Each hash operation should take about 1 minute on an average desktop computer, and use about 2...4 GB of RAM. The chosen time is short because each verification of a proof of work takes the same amount of time.

Every 10 minutes, the application should save the last computed hash in order to minimize the possible loss caused by computer restarts and power failures.

The application would generate a proof of work, starting with the following information:
* A (random) seed which is generated (by the developers of the cryptocurrency) immediately before the final build is made and the application is publicly release. This will prevent the precomputation of the proofs of work.
* A timestamp.
* The user name from the Bitcointalk forum. This has to be registered with the developers of the cryptocurrency. Unregistered users would not receive free cryptocurrency.
* An address for the account which will receive the cryptocurrency.
* Counter which is incremented at every hash; this starts from 1.

The proof of work would consist in a single hash which has as many 0 bits as possible at the beginning of the hash. The number of 0 bits can vary so that the users can decide how many bits they want to generate (because they are rewarded proportionally).

At a specified date X, publicly release the application.

Then allow the users from the Bitcointalk forum to register their user names (and 1 cryptocurrency address per user), with the developers of the cryptocurrency. Unregistered users would not receive free cryptocurrency. Maybe also require a (small) minimum number of posts per user; the posts have to make sense, not simply be noise; this is to minimize the automated registration of users for the purpose of getting free cryptocurrency.

The application can be run for any amount of time, stopped, started again, and so on, since the computed hashes are saved periodically. The proof of work is the last saved hash. The number of 0 bits from the beginning of the proof of work is the "strength" of the proof of work.

At a specified date Y, for example 30 days after date X, the proof of work generated by the application has to be submitted to the developers of the cryptocurrency, by each user.

Each proof of work has to be validated by the developers of the cryptocurrency.

For each valid proof of work, the developers of the cryptocurrency would give to the registered user an amount of cryptocurrency proportional with 2 raised to the power "strength".

The amount of cryptocurrency given to a user should be capped in order to limit how much cryptocurrency a user could get by using a computer farm or a supercomputer.

You can use an online notary service, like DigiStamp, to sign a zip (with your code and names inside), to prove that at a specific date you your names were associated with the code.

If captchas will be used, some people will use automatic captcha solvers.

Personally, I prefer a small application which computes some proof of work (based on a lot of RAM, XRB already uses Argon2d) instead of solving captchas, but it appears (from the Manta thread) that some people don't know about automatic captcha solvers.

May suggest a different mechanism for distribution, instead of captchas?

The idea is to make the distribution as balanced as possible relative to the number of people who are going to want to get free coins, and to their physical ability to solve captchas. This would also make irrelevant the automatic captcha solvers.

Make a small desktop / web application which does some proof of work based on a lot of RAM (like 2...4 GB). The idea is to make CPUs as efficient or more efficient than videocards and ASICs.

The result of a day of work (on an average computer) of this application would be a string which is sent to you through a website. This string contains the necessary information to validate the proof of work (in the same application).

For the valid proofs of work, you can then manually (or automatically) distribute the coins to the participants.

You allow this for a limited time, like a month, or whatever.

What you need for the proof of work:
* A (random) seed which you generate only immediately before you make the final build and release the application to the public. This will prevent precomputation.
* An address for the account which will receive the coins.
* A timestamp. This is used to generate different proofs of work for the same address.
* Possibly a counter, depending on the proof of work algorithm.

As you can see this is a like mining, but very limited in time (and therefore energy) and without the immense complexity of implementing one into the coin itself.

What limits would there be to the number of coins that someone can get through the faucet?

Number of solved captchas, IP address, email address, phone number / SMS...?