Locked Contracts

When you send BTC to 1XXXXXXXXXXXXXXXXXXkfjds you know that nobody could possibly possess a private key to that address, so the money is considered forever lost. It has some applications, ie. Proof of Burn. However, you can't create an Ethereum contract without a private key, so any existing Ethereum contract could conceivably be altered and any associated Ether transferred away.

Let's say I wanted to make an Ethereum app for drunk gamblers called "Send me my money back in 12 hours". Basically any amount you send to it gets automatically sent back to you when you're sober (depending on how much you've drunk, YMMV). There's always the risk that the creator of the contract decides to just withdraw the Ether and screw you over.

It would be nice if you could "lock" a contract permanently, that is - creating it with a flag set that will permanently disallow any withdrawals and modifications to the contract code. Basically a public address where a private key was used to create it but any future uses of that private key would be ineffective.

Silly example I know but I'm sure there are lots of other examples where a well-designed and bug tested contract can simply exist on the blockchain autonomously without fear of the original creator changing his mind.

@salhadaar, My understanding is that a contract doesn't have a known private key. The white paper states that the address of a contract is the last 20 bytes of the transaction that created it. To find a private key with a public counterpart that ends in the same 20 bytes would require a brute-force search.

I meant to say that that the address of a contract is the last 20 bytes of the *hash* of the transaction that created it, and that a collision would require a private key where the last 20 bytes of the *hash* of the public key happened to match. In other words, it should be just as unlikely as guessing a private key to a given bitcoin address (might as well take one from here: http://bitcoinrichlist.com/top100)

Someone will need to build development tools for things like debugging.

I can see two approaches to debugging. The gritty way would be to run a debugger on an Ethereum client on a local test blockchain and watch as the stack machine actually executes your bytecode. A more high level approach would require compiler support and maybe a simulated runtime environment.

I agree, aqv99t. I think a testnet is important, and an interactive debugger would be extremely useful, whether at the bytecode or script source level. They really aren't that far apart. It also seems to me that you'd want to start with a robust suicide block in your contract code!