Ethereum is a proposed "metacoin" on top of the bitcoin protocol.
described here: http://ethereum.org/ethereum.html
One aspect which sounds interesting, but also potentially dubious is it's notion of turing complete contracts.
There is a very good reason that bitcoin does not have turing complete scripts, which pretty much the same as the reason that ethereum's (unimplemented) protocol might not work.
the halting problem means that it's impossible to tell, in the general case, whether an arbitary computer program will eventually halt, or run forever.
It has many other implications, such as it's impossible to predict the output of a program without running it, and also impossible to generate time it will take to run a program without running it.
Now, it's only impossible to make these predictions given a universal turing machine. If you restrict the machine sufficiently then you can make predictions about the time to run a script. This is why the bitcoin script is not turing complete.
hmm, so the fee is linear, a small amount per step once steps > 16.
What triggers a contract? - a transaction is sent to it. Okay, so that is unambigious, you can't have invalid contract triggers.
hmm, so you could still have a buggy, well funded contract, that some one discovers an exploit for and causes it to go into an infinite loop draining away all it's funds, and during that time, slowing the entire network by churning CPU.
It seems like a wise idea to have a way to set a failsafe stop point. some sort of interrupt if the contract runs too long - it would die, and transfer all it's remaining funds back to it's creator.
The simplest way to do that would be to have a CURRENTFEE or STEPCOUNT variable available to the contract. or maybe a max steps setting on the contract, so miners could make a judgement call whether to actually run that. I'd centainly steer heavily towards a limiting the max CPU used. What might be possible with turing completeness is highly unpredictable.
keep non-turing complete scripts, but enable contracts to send transactions and even create contracts. Then, you could still have touring completeness, and loops etc. but you could also predict the runtime of each script, but not the run time of their interactions.
However, the amount of things you could do with this is still fairly limited, since you pretty much have to run all the contracts on every computer that wants to validate the block chain. That isn't very scalable. It would be much more effective to run your scripts on some computers outside the network... they could still agree on things via a multisig thing, although there would necessarily be an element of trust. As long as you where confidant that you purchased this compute from unrelated vendors (difficult to verify).
At one point, ethereum mentions running a SatoshiDice site in the blockchain? Each run must be deterministic to be verified, but you could implement this by having it depend on the hash of the time, or current miner, etc, or just have a random value that is saved with the block. If a given minor wins, it would lock in those values into it's block, which would then be reused when verifying. So, the bet would be like saying "I bet X amount that given miner (or miner pool?) will validate the next block"
When ever the contract updates it's state, a whole new instance would need to be stored within the blockchain. So, it makes sense that there should be a cost for that, although, it should probably be proportional to the data the contract takes up - depending on the scheme for storing updates to the contracts. If the code and the data take up the same space - that would make it easy to update the code and the data.
it's important for users to be able to query a contract, say, "who is the current owner of this contract?" of course, the owner of a contract is just a public key that the owner query returns. Queries MUST be pure functions, and cannot generate transactions or create new contracts, but they can be run outside of the network.