Trying to figure out a couple things (from pastebin link):<p>1. What protection against non-halting?<p>contracts are "funded" upon creation, and by those who issue transactions to the contract. if there are specific fees required by the contract to perform an action, it must be enforced by the contract itself. the cost of computation will eventually exhaust the contract's funding it fails.<p>2. what are the long-term economics? (i.e. is coin supply unlimited or limited and at what rate of decay)<p><pre><code> line 90</code></pre>
- planned fundraising period with issuance of 10000 ether per BTC contributed<p>- other coins will be issued so the initial money supply is 15000 times the contributed BTC amount, with 0.25x (i.e. 16.67%) to the founders, same amount to fund the Etherium organization. Division of BTC not specified.<p>- the mining reward will be 1/3 of the initial supply, per year, perpetually (i.e. 1/2 the contributor's reward.) So the money supply increases linearly.<p>3. if a person's only goal was to use the blockchain to store data, what would be cost per byte, and is there a max rate?<p><pre><code> line 385 to 399
</code></pre>
- A contract is "funded" when it is created, and the computation performed by the contract consumes the funds.<p>- storage of a "data item" in contract memory costs 100<i>x</i> where <i>x</i> = floor(10^21 / floor(difficulty ^ 0.5))<p>- don't see the limit/cost of data items bound to transactions as per transaction definition on line 133<p>anyway it takes courage to name a currency after a drug like ether.
The page doesn't say who is behind it, but the wiki is edited by user "vbuterin".<p>So maybe it's Vitalik Buterin, one of the more interesting cryptocurrency thinkers out there. Hmm.<p><a href="http://about.me/vitalik_buterin" rel="nofollow">http://about.me/vitalik_buterin</a>
I don't know if the Etherium people are looking for comments, but here are a few.<p>I think that Dagger has serious issues. First, the spec is buggy: the text says that eight bottom-level nodes are hashed together, but the pseudocode only uses four. Second, it does <i>not</i> require 512MB per thread; it requires 512MB of write-once, read-many-times memory, shared by all threads; this property seems to be asking for a rather large ASIC (or a smaller ASIC backed by some multi-port SRAM) to have a huge advantage.<p>Also, what's up with the choice of secp256k1? It's at least less likely to be backdoored by evil choice of parameters than, say, P-256, but there are many better choices out there (e.g. curve25519 or some of its larger variants). Those better variants have the big advantage (especially in this application) of having faster verification operations.<p>(The fastest-to-verify option would probably be plain ol' RSA, but signatures are rather large.)
Text content: <a href="http://pastebin.com/NCGRv74u" rel="nofollow">http://pastebin.com/NCGRv74u</a><p>(Saw comments that the site went down and still had it loaded on my machine)
The site is down for many hours. The cached version: <a href="http://webcache.googleusercontent.com/search?q=cache:http://ethereum.org/ethereum.html" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:http://...</a>
This is a very cool idea. I think it may have some critical flaws, but even the fact that people are thinking of stuff like this is so cool. Very singularitarian.
I think the clever idea here (IMO) are the fees. An argument against implementing a Turing complete language inside Bitcoin or an Altcoin might be that it's hard to determine when execution should end. The fees allow arbitrarily complex constructs without any hard cap, while preventing abuse.
My first thought was why would one want their currency to be Turing-complete? It's actually a cool concept though. Being able to have your money make decisions opens all kinds of possibilities.
My understanding was that a balance based model opened up some pretty serious security problems, which is why bitcoin didn't use it. I'm dubious of a new coin as complex as this.
I don't understand <i>who</i> does all the turing complete contract computation. Presumably the miners, but they're paid to do some useless proof-of-work work, not the turning complete computation of the contract.
Ripple is also working on the same thing and is supposedly releasing them "soon": <a href="https://ripple.com/wiki/Contracts" rel="nofollow">https://ripple.com/wiki/Contracts</a>
I'm most curious about cryptocurrency algorithms that can be optimally run on FPGAs, but not ASICs or GPUs. Is there anything along those lines floating around already?
Note that Bitcoin is purposefully not turing complete. <a href="http://bitcoin.stackexchange.com/questions/17258/turing-completeness-of-bitcoin-script" rel="nofollow">http://bitcoin.stackexchange.com/questions/17258/turing-comp...</a>