1. What protection against non-halting?
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.
2. what are the long-term economics? (i.e. is coin supply unlimited or limited and at what rate of decay)
line 90
- planned fundraising period with issuance of 10000 ether per BTC contributed- 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.
- 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.
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?
line 385 to 399
- A contract is "funded" when it is created, and the computation performed by the contract consumes the funds.- storage of a "data item" in contract memory costs 100x where x = floor(10^21 / floor(difficulty ^ 0.5))
- don't see the limit/cost of data items bound to transactions as per transaction definition on line 133
anyway it takes courage to name a currency after a drug like ether.
From Thesaurus: "ether - the fifth and highest element after air and earth and fire and water; was believed to be the substance composing all heavenly bodies"
Appologies to Hunter S. ThompsonEthers are also a group of rather common organical compounds in chemistry. This is the page Wikipedia gives you when searching "Ether", as gateway allures to. Apparently, a specific compound of those (diethyl ether) can be used as a drug. Seems rather unlikely to me that people would connect the name to the drug first.
Perfect name.
The transaction fee is determined based on the number of computational steps in the contract. My understanding is that, if the contract has not halted by the time the transaction fee has been "spent", then the transaction is rejected.
So maybe it's Vitalik Buterin, one of the more interesting cryptocurrency thinkers out there. Hmm.
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 not 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.
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.
(The fastest-to-verify option would probably be plain ol' RSA, but signatures are rather large.)
(Saw comments that the site went down and still had it loaded on my machine)
"As a result, we have a cryptocurrency protocol whose codebase is very small, and yet which can do anything that any cryptocurrency will ever be able to do."
http://fusion.net/modern_life/story/ethereum-bitcoin-currenc...
The ethereum proposal is the most technical yet. Hopefully it sets a new minimum bar in the market for crowd-funded vaporware (I'm highly skeptical of them all).
[0] http://dx.doi.org/10.1109/IPDPS.2004.1303105
Edit: maybe the modification strategy could provide some 'proof-of-steak' protections, without burdening the system with excessive early adopter advantages.
What am I missing? Is the idea that without loops the transaction size can be used to estimate the computation required without actually performing it, and thus the appropriately sized transaction fee required?
wiki here
>It is purposefully not Turing-complete, with no loops.