Finally my construction works even if you don't cripple the language. Arbitrary loops are allowed, as are programs which never halt. You just abort them if they run too long; the PoW still works.
Thanks for your valuable comments so far.
Well, at some point i'm afraid we must cripple the language so that we can reliably determine the runtime beforehand.
This is required imho to set fees that are "in some way related" to the computational power required to such the proof-of-work function.
You don't need to know in advance how long it will run.
The buyer commits a number of ELC, and specifies how much he will pay the winning miner for each block solved while running his program, and what bounties he will pay for what results. This is written into the blockchain. Once committed, the network won't let him spend those coins in any other way, until the offer terminates or is withdrawn (
Edit: by which I mean the buyer withdraws the offer. There should be a short time before the withdrawal becomes effective, in order to allow the miners to notice the withdrawal and stop work). It is then up to each miner to decide for himself if he accepts the deal or not. There's no need for him to notify the buyer of his acceptance (
Edit: or anyone else, until he actually solves a block). He just starts running the program. The network confirms each block in the usual way and pays the winning miner out of the committed funds. Similarly the network confirms the bounties, and pays the solving miners. When the funds are exhausted, or when the offer terminates or is withdrawn, then the miners will abandon work on that program and run another. Any ELC left over are returned to the buyer.
This again is required to discourage functions that run "too long" (see thoughts below your second quote).
Otherwise an attacker might create a proof of work function that only terminates when the (for him) desired result is returned and otherwise not. Otherwise it runs indefinitely until aborted.
It runs indefinitely until the funds are exhausted, at which point the miners say "thank you and goodbye". There is no attack here.
This again would mean, that only blocks which are relevant to him (i.e., contain relevant information such as the to-be-cracked hash) would be solved. Depending on the complexity of the problem, he this way might get allocated much more computation power than wanted. Blocks must be solved on a regular basis, so the termination is required here.
It's not required with my scheme. A user-supplied program could run for hours or days, while generating proof of work blocks every ten minutes on average (or whatever other period is specified)..
I personally think that either there should be a hard limit on the execution time (which is not my favorite) or the fees must increase asymptotically faster than the execution time. Going past the 10 minute execution mark should be expensive enough such that users are discouraged to submit such POW functions.
Here, we should calibrate the fees/other parameters in a way that typical applications (this is yet to be defined, what is typical?) are cheap, and everything that derives from this standard gets more and more expensive.
(In this scheme, btw., the crippled language is required again)
With these limitations, you are foreclosing on one particular application which is ideal for the kind of distributed network which we are talking about. Iinteger factorisation using the Elliptic Curve Method (ECM), uses the mathematics behind elliptic curve cryptography, but to a different purpose. ECM is currently the fastest known algorithm for finding factors larger than about 20 decimal digits, and smaller than about one-third of the number of digits of the number to be factored. (For factors larger than one-third of the length, sieving algorithms are better. Don't even think of trying to use ECM to factor an RSA modulus.)
With ECM, the payload would be the target integer, a depth parameter B1, and possibly a few other switches and parameters. The algorithm takes a random parameter s which defines the specific elliptic curve. This would be the random input supplied by the miners.
For each s, the algorithm has a small chance of finding a factor. The usual process given a target whose factor lengths are unknown is to start with a modest B1, run a few curves. If no factor is found, increase B1 and run more curves, and so on.
Here is a list of recommended B1 levels, and the corresponding recommended number of curves to run.
Currently I am trying to factor a 187 digit number. By my own efforts, I have reached the B1=110,000,000 level, and each curve is taking about eight minutes to run using
GMP-ECM. A python implementation would surely be slower, and of course there will certainly be some computational overhead associated with the Elastic Coin infrastructure.
Just as I reach the point where I think a cluster would be useful, are you seriously telling me that the cluster you're building can't hack it?
