10

As I see it, the script feature is one of the most complicated features in the entire protocol. It features

$ cat src/script.h|grep '^ *OP_'|wc -l
118

instructions, and requires a stack to calculate.

The most important limitation, it makes it complicated to answer a simple and common question - "how much bitcoins does my key have".

With a complicated script, a bug in the script engine is more likely, and thus, it is possible that the network will split (50% client accept this transaction, 50% do not, before you notice, you have two long block chains. One longer which is considered invalid by 50% of the clients, and one shorter, considered valid by both).

What's the rational behind such a system? Why can't any transaction be simply "move X BTC from key K to key I signed by private key K"?

(If indeed you want anything complex - do that in a different system, and not inside bitcoins block).

  • I think that the claim "the 'simple' kind of transactions can be feasible proven not to have bugs because of scripts" is correct. Most transactions real world transactions will only use trivial scripts for the near future ... and I believe that if you choose to only use such transactions (let's say with a "safe client" or "safe mode" that rejects all other tx), then you can be safe from potential bugs. The usefulness of scripts is enormous, but you can work around them for everyday use if you don't need those features ... or so I think/hope. – ripper234 Feb 21 '12 at 18:49
  • Can you explain why the usefulness of scripts is enormous, especially given that most of the transaction are "regular" ones? And correct me if I'm wrong, but safe client wouldn't protect you from bugs that split the network. – Elazar Leibovich Feb 21 '12 at 20:37
  • Scripts are very useful, because they allow everything @theymos wrote, and much more. Most transactions don't need to use any of the features, but a lot of people will choose to use these scripts to hold their "uber secure wallet that uses multisig", while condutcing day-today business via simpler tx. The beauty is that as a user you can completely isolate yourself from any risk. I don't think a split network bug is a realistic scenario - try asking another question like "Could bugs in script execution realistically cause network splits" to understand why or why not. – ripper234 Feb 21 '12 at 20:50
5

Why can't any transaction be simply "move X BTC from key K to key I signed by private key K"?

Then you couldn't (easily) do the P2SH stuff being implemented right now without getting everyone to upgrade. You also couldn't do escrow, multisig, secure cross-chain trading, secure high-frequency trading, etc. These features are very valuable; Script-based escrow, for example, will be the first escrow system ever which requires no trust in third-parties.

Script is, in my opinion, one of the greatest innovations in Bitcoin. I would prefer a much more powerful, Turing-complete version of Script in Bitcoin, actually.

  • Won't the Turing completeness cause infinite loops? – goodguys_activate Dec 15 '13 at 1:36
  • @makerofthings7 There'd need to be some sort of limit on the number of instructions executed per script. – theymos Dec 15 '13 at 8:00
  • I'm doing a deep dive in the scripting, and ported a proof of concept to C# from BitcoinJ. Do you have any details on some theoretical scripts that are useful? The contracts page doesn't go into enough detail, and there are no examples of a turing complete example – goodguys_activate Mar 13 '14 at 20:30
3

(If indeed you want anything complex - do that in a different system, and not inside bitcoins block).

I'll first try to answer your second comment: in short, you cannot do it in a different system, with the same security properties.

Several schemes exist for sharing keys according to complex schemes, for example Shamir's Secret Sharing. Unfortunately, that still requires the full secret key to be recombined on a single computer system at some point in time, which becomes a single point of failure.

In contrast, Bitcoin's 2-of-2 transactions for example allow a transaction to be created that needs to be signed using two different keys, which can reside on two different systems, independent from eachother. That will hopefully allow applications that require a confirmation to be given on a mobile phone system, while that phone's private key never needs to leave the device.

What's the rational behind such a system? Why can't any transaction be simply "move X BTC > > from key K to key I signed by private key K"?

Restricting transactions to such a simple form would restrict Bitcoin to exactly the possibilities traditional currencies had (though decentralized). However, Satoshi saw the potential to allow it to do more, and introduced a script system. He wasn't around anymore to bring it to practice, but Mike Hearn wrote down some of the things Satoshi had in mind on the Contracts page of the Bitcoin wiki.

  • It's worth noting that there is a protocol, the development of which Stefan Thomas leads, that allows creating a 2-of-2 (and maybe m-of-n) transaction from two ECDSA keys without combining them, and looks exactly like a single ECDSA signature which can be placed in a simple transaction. So at least this application does not necessarily require scripts. – Meni Rosenfeld Feb 23 '12 at 6:57
  • You can also use Shamir's Secret Sharing in conjunction with M of N transactions. One or more of the N private keys can be split up into multiple shares with SSS. If you decide to use SSS, here's a pretty straightforward python implementation: github.com/halfmoonlabs/secretsharing – Ryan Feb 6 '14 at 16:22
2

The most important limitation, it makes it complicated to answer a simple and common question - "how much bitcoins does my key have".

Why is that a limitation? It's actually a critical defense against one of the most realistic vulnerabilities in crypto-currencies as immortalized in this XKCD cartoon. There is at least one very good reason Satoshi chose to remain anonymous.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.