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

<p>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 <em>ever</em> which requires no trust in third-parties.</p>

<p>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.</p>

CC BY-SA 3.0
2013-12-15T01:36:37.860Z
Won't the Turing completeness cause infinite loops?
makerofthings7
CC BY-SA 3.0
2013-12-15T08:00:30.397Z
@makerofthings7 There'd need to be some sort of limit on the number of instructions executed per script.
theymos
CC BY-SA 3.0
2014-03-13T20:30:10.563Z
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
makerofthings7
CC BY-SA 3.0
2012-02-21T16:11:48.637Z
2012-02-21T16:11:48.637Z
theymos
<blockquote>
  <p>(If indeed you want anything complex - do that in a different system, and not inside bitcoins block).</p>
</blockquote>

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

<p>Several schemes exist for sharing keys according to complex schemes, for example <a href="http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing" rel="nofollow">Shamir's Secret Sharing</a>. 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.</p>

<p>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.</p>

<blockquote>
  <p>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"?</p>
</blockquote>

<p>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 <a href="https://en.bitcoin.it/wiki/Contracts" rel="nofollow">Contracts page</a> of the <a href="https://en.bitcoin.it/" rel="nofollow">Bitcoin wiki</a>.</p>

CC BY-SA 3.0
2014-02-06T16:22:45.820Z
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: https://github.com/halfmoonlabs/secretsharing
Ryan Shea
CC BY-SA 3.0
2012-02-23T06:57:20.803Z
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
CC BY-SA 3.0
2012-02-21T19:29:15.550Z
2012-02-21T19:29:15.550Z
Pieter Wuille
<blockquote>
  <p>The most important limitation, it makes it complicated to answer a simple and common question - "how much bitcoins does my key have".</p>
</blockquote>

<p>Why is that a limitation? It's actually a critical defense against one of the most realistic vulnerabilities in crypto-currencies as immortalized in <a href="http://xkcd.com/538/" rel="nofollow">this XKCD cartoon</a>. There is at least one very good reason Satoshi chose to remain anonymous.</p>

CC BY-SA 3.0
2012-02-21T17:18:08.450Z
2012-02-21T17:18:08.450Z
David Schwartz
<p>As I see it, the script feature is one of the most complicated features in the entire protocol. It features </p>

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

<p>instructions, and requires a stack to calculate.</p>

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

<p>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).</p>

<p>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"?</p>

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

CC BY-SA 3.0
2012-02-21T18:49:18.433Z
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
CC BY-SA 3.0
2012-02-21T20:37:31.853Z
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
CC BY-SA 3.0
2012-02-21T20:50:33.540Z
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
<script>
Why is Script needed?
Elazar Leibovich
# Why is Script needed?

(Asked by: username_0 on 2012-02-21)

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).

**Tags:** script

> **Comments:**
> **username_1**: 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.  
> **username_0**: 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.  
> **username_1**: Scripts are very useful, because they allow everything @username_2 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.  

---

## 3 answers

### Answer by username_2 on 2012-02-21. Score: 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.

> **Comments:**
> **username_3**: Won't the Turing completeness cause infinite loops?  
> **username_2**: @username_3 There'd need to be some sort of limit on the number of instructions executed per script.  
> **username_3**: 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  

---

### Answer by username_4 on 2012-02-21. Score: 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](http://en.wikipedia.org/wiki/Shamir%27s_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](https://en.bitcoin.it/wiki/Contracts) of the [Bitcoin wiki](https://en.bitcoin.it/).

> **Comments:**
> **username_6**: 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.  
> **username_5**: 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: https://github.com/halfmoonlabs/secretsharing  

---

### Answer by username_7 on 2012-02-21. Score: 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](http://xkcd.com/538/). There is at least one very good reason Satoshi chose to remain anonymous.


---

