Quote from: ddink7 on January 24, 2014, 07:15:09 PM

Quote from: Ademan on January 24, 2014, 07:02:27 PM

Quote from: tgerring on January 24, 2014, 12:35:03 PM

Quote from: Ademan on January 24, 2014, 09:45:44 AM

So there's a lot to read before asking a *completely* educated question about Ethereum, but hopefully I'm not jumping the gun too much...

Because Ethereum has a Turing complete scripting language, you cannot necessarily know how many cycles a script will take to execute, but Ethereum charges a fee based on how many cycles (past 16) that it takes your script to execute, how are you handling that?

If the contract doesn't have enough funds to fully feed it, my understanding is that it will cease execution. After all, if you're a miner, why would you do work for no fee?

Well that really sucks, that means you have to significantly overpay if you can't predict the runtime of your contract (which is a fact of turing completeness, though it's possible to write programs which have a deterministic run-length, what's the point of having a turing complete scripting language in that case?)

Then again it'd also suck to have an address drained of funds because of an accidental infinite loop in one of your scripts (though I hope you're not "testing live"!).

My point is there are multiple ways to handle this, all of them seem to suck in multiple ways, so I'm wondering what the devs are doing.

Vitalik says: http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

Quote

Fees - Ethereum contracts will regulate its Turing-complete functionality and prevent abusive transactions such as memory hogs and infinite loop scripts by instituting a transaction fee for each computational step of script execution. More expensive operations, such as storage accesses and cryptographic operations, will have higher fees, and there will also be a fee for every item of storage that a contract fills up. To encourage contracts to clean up after themselves, if a contract reduces the amount of storage that it uses a negative fee will be charged; in fact, there is a special SUICIDE opcode to clear a contract and send all funds and the hefty negative fee back to its creator.

I'm afraid that doesn't answer my question though, hopefully this will clarify my concern. I assume a script will stop dead if you run out of fees, but does that mean you have to massively overpay your fees to ensure complete execution? The direct consequence of including a turing complete scripting language is you can writes scripts which you *cannot* know ahead of time how long they will execute for, and consequently, you cannot know ahead of time how much it will cost in fees. If, on the other hand, you write scripts which you *can* know their execution length ahead of time, you may as well not have used a turing complete language to begin with!

I personally think the scripting language would have probably been better off with a "for each" like construct, and restricting JMP to forward jumps only. Since you can design your "for each" to be reasonable *prior* to execution (though obviously you could still construct a program which you can't reason about completely, it reigns in the potential for infinite loops if you implement it right).