Locked Contracts

Is it possible to create a provably un-alterable contract?

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.

Comments

  • bgeronbgeron Member Posts: 2
    I think contracts are only alterable by the code itself. So the contract may overwrite itself, e.g. when it receives code signed by a trusted party; no external modification is possible.

    In the Ethereum whitepaper (https://www.ethereum.org/ethereum.html#p35), contracts are created by setting the receiving address to 0.

  • salhadaarsalhadaar Member Posts: 26
    Ok thanks, so the code can't be changed once a contract is made? What happens if there are bugs that need to be fixed?

    I assume that somebody with the private key could still transfer the Ether out of the contract address regardless of whether the code could be modified.
  • mids106mids106 Member Posts: 188 ✭✭✭
    You'll need to build in the ability to update the code in the contract itself, see http://www.ethereum.org/ethereum.html#p414

    If you don't you can't update the contract. Same goes for transfering the Ether out of a contract; you can't do that unless you code that ability upfront.
  • salhadaarsalhadaar Member Posts: 26
    Oh ok I was under the assumption that you could send Ether from a contract address if you had the private key.
  • aqv99taqv99t Member Posts: 7
    @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.

  • aqv99taqv99t Member Posts: 7
    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)
  • salhadaarsalhadaar Member Posts: 26
    I need to read that whitepaper for the 7th time, I'm missing some important details :) Do you know what happens if you need to debug a contract, is that even possible?
  • aqv99taqv99t Member Posts: 7
    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.
  • w0bb1yBit5w0bb1yBit5 Member Posts: 17
    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!
Sign In or Register to comment.