<p>The scripting engine in Bitcoin is not turing complete on purpose. The reason this was done is that it enables a static analysis of the scripts in transactions and facilitates discarding transactions with scripts that would for example run indefinitely, consuming resources at all nodes that see it (see the <a href="http://en.wikipedia.org/wiki/Halting_problem" rel="nofollow">halting problem</a> for example).</p>

<p>That being said it is certainly possible to increase the expressiveness of the scripting language by incrementally adding new opcodes. In order to avoid a hard-fork where transactions valid in one partition are not valid in another just because of the scripts used there would be a transition period after which the individual adjustments become effective. Notice however that changes to the scripting language are often very controversial and will be extensively vetted by the core developers.</p>

<p>In short: yes, you can increase the expressiveness of the scripting language, but no, you will most likely never see it becoming turing complete.</p>

CC BY-SA 3.0
2014-01-26T07:13:16.190Z
Thank you for the insight on the impact of Turing completeness. It is a concept that I am not familiar with, I understand it as a set of programing logic? Not sure how one can construct an incomplete set of logic.
Cal Abel
CC BY-SA 3.0
2014-01-26T07:14:37.320Z
By your description, it seems Ethereum may run into some computational and bandwidth problems, by doing too much at once.
Cal Abel
CC BY-SA 3.0
2014-01-24T11:54:43.920Z
2014-01-24T11:54:43.920Z
cdecker
<p>Bitcoin has a scripting engine already. At this time only a limited number of features in it are used, such as those for standard transactions. Other features are unused but can be developed upon and some, disabled (though could be reintegrated later).</p>

<p>Solutions are already present which build on top of Bitcoin or other such coins to provide smart contracts, m of n transactions, programmable features and more for those who want to use more advanced scripting features which bitcoin would be unable to support. </p>

<p>The currently most fully featured example of this is Open Transactions (<a href="http://opentransactions.org/" rel="nofollow">http://opentransactions.org/</a>). It is also token-less in the sense there are no "coins" being minted in the use of the application keeping it pure. </p>

CC BY-SA 3.0
2014-01-24T11:48:46.647Z
I downvoted. Bitcoin's script engine is not turned off, only some of its at the time unused features. Every Bitcoin transaction uses scripts. M-of-n multisig requires less standard scripts.
Pieter Wuille
CC BY-SA 3.0
2014-01-24T12:11:42.880Z
I will make this more clear hopefully get that down-vote removed :).
MaxSan
CC BY-SA 3.0
2014-01-24T11:47:02.090Z
2014-01-24T13:10:57.283Z
2014-01-24T13:10:57.283Z
MaxSan
<p>You can easily see it this way: a hardfork can occur in two ways:</p>

<ul>
<li>an update allows things that clients running older clients do not allow</li>
<li>an update accidentally makes blocks or transactions that were already in the blockchain invalid</li>
</ul>

<p>In principle, the first problem is the easiest to solve, a hardfork will only occur when someone uses the new feature before the majority of the network has updated to the new version. So basically, it would not be smart to start using new functionality immediately, because a hardfork between new and older clients can occur. However, in a certain amount of time, the majority of the clients will be updated and the new protocol can be used in it's entirety.</p>

<p>The second problem, however, is of a different kind. Practically, it can be solved just as easy, but it required all clients to keep track of this change so that they can explicitly only enforce the rule to new blocks. This can be done fairly easily by adding a hard-coded reference to the point at which this new feature has to be accepted to all clients. However, it's clear that this is not the kind of solution you want. If you need to hard-code these kind of things, the protocol will get cluttered.</p>

<p>So basically: <strong>removing functionality clutters the protocol and will be avoided, while adding functionality can be adopted fairly easily as soon as the majority of the clients has been updated</strong>.</p>

CC BY-SA 3.0
2014-01-24T13:27:13.117Z
2014-01-24T13:27:13.117Z
Steven Roose
<p>I am curious if the Bitcoin protocol can incorporate Turing complete scripting capabilities without forking the block chain. I ask this because I understand the ability to create contracts digitally is as significant an development as bitcoin.</p>

<p>I am trying to judge the efficacy of new altcoins like Ethereum to assess the future viability of Bitcoin.</p>

<p>Thanks for your comments!  Also if you are curious as to why I think contracts are so important here is my blog about why contracts are important.</p>

<p>Peer to Peer Government: Guarding the Guardians
<a href="http://statisticaleconomics.org/2014/01/10/peer-to-peer-government-guarding-the-guardians/" rel="nofollow">http://statisticaleconomics.org/2014/01/10/peer-to-peer-government-guarding-the-guardians/</a></p>

CC BY-SA 3.0
2014-01-24T05:58:24.530Z
Ethereum is not an altcoin, but it supports altcoins on top of it.
John T
CC BY-SA 3.0
2014-01-26T07:09:58.653Z
Ethereum has a coin that it uses for its own transactions called ether. It also within its structure allows unlimited other coins.
Cal Abel
CC BY-SA 4.0
2020-05-08T16:12:45.817Z
@JohnT the term "altcoin" is not strictly defined. For many it simply means any cryptocurrency other than Bitcoin. For others it means other things. The Bitcoin StachExchange describes tag "altcoin" with "Questions about alternative cryptocurrencies are off topic unless they are applicable to Bitcoin.", for example.
Hubert Jasieniecki
<script><altcoin><blockchain-fork><ethereum><turing-completeness>
Can Bitcoin incorporate the scripting protocols of Ethereum without a fork?
Cal Abel
# Can Bitcoin incorporate the scripting protocols of Ethereum without a fork?

(Asked by: username_0 on 2014-01-24)

I am curious if the Bitcoin protocol can incorporate Turing complete scripting capabilities without forking the block chain. I ask this because I understand the ability to create contracts digitally is as significant an development as bitcoin.

I am trying to judge the efficacy of new altcoins like Ethereum to assess the future viability of Bitcoin.

Thanks for your comments! Also if you are curious as to why I think contracts are so important here is my blog about why contracts are important.

Peer to Peer Government: Guarding the Guardians
<http://statisticaleconomics.org/2014/01/10/peer-to-peer-government-guarding-the-guardians/>

**Tags:** script, altcoin, blockchain-fork, ethereum, turing-completeness

> **Comments:**
> **username_1**: Ethereum is not an altcoin, but it supports altcoins on top of it.  
> **username_0**: Ethereum has a coin that it uses for its own transactions called ether. It also within its structure allows unlimited other coins.  
> **username_2**: @username_1 the term "altcoin" is not strictly defined. For many it simply means any cryptocurrency other than Bitcoin. For others it means other things. The Bitcoin StachExchange describes tag "altcoin" with "Questions about alternative cryptocurrencies are off topic unless they are applicable to Bitcoin.", for example.  

---

## 3 answers

### Answer by username_3 on 2014-01-24. Score: 4

The scripting engine in Bitcoin is not turing complete on purpose. The reason this was done is that it enables a static analysis of the scripts in transactions and facilitates discarding transactions with scripts that would for example run indefinitely, consuming resources at all nodes that see it (see the [halting problem](http://en.wikipedia.org/wiki/Halting_problem) for example).

That being said it is certainly possible to increase the expressiveness of the scripting language by incrementally adding new opcodes. In order to avoid a hard-fork where transactions valid in one partition are not valid in another just because of the scripts used there would be a transition period after which the individual adjustments become effective. Notice however that changes to the scripting language are often very controversial and will be extensively vetted by the core developers.

In short: yes, you can increase the expressiveness of the scripting language, but no, you will most likely never see it becoming turing complete.

> **Comments:**
> **username_0**: Thank you for the insight on the impact of Turing completeness. It is a concept that I am not familiar with, I understand it as a set of programing logic? Not sure how one can construct an incomplete set of logic.  
> **username_0**: By your description, it seems Ethereum may run into some computational and bandwidth problems, by doing too much at once.  

---

### Answer by username_4 on 2014-01-24. Score: 4

Bitcoin has a scripting engine already. At this time only a limited number of features in it are used, such as those for standard transactions. Other features are unused but can be developed upon and some, disabled (though could be reintegrated later).

Solutions are already present which build on top of Bitcoin or other such coins to provide smart contracts, m of n transactions, programmable features and more for those who want to use more advanced scripting features which bitcoin would be unable to support.

The currently most fully featured example of this is Open Transactions (<http://opentransactions.org/>). It is also token-less in the sense there are no "coins" being minted in the use of the application keeping it pure.

> **Comments:**
> **username_5**: I downvoted. Bitcoin's script engine is not turned off, only some of its at the time unused features. Every Bitcoin transaction uses scripts. M-of-n multisig requires less standard scripts.  
> **username_4**: I will make this more clear hopefully get that down-vote removed :).  

---

### Answer by username_6 on 2014-01-24. Score: 0

You can easily see it this way: a hardfork can occur in two ways:

* an update allows things that clients running older clients do not allow
* an update accidentally makes blocks or transactions that were already in the blockchain invalid

In principle, the first problem is the easiest to solve, a hardfork will only occur when someone uses the new feature before the majority of the network has updated to the new version. So basically, it would not be smart to start using new functionality immediately, because a hardfork between new and older clients can occur. However, in a certain amount of time, the majority of the clients will be updated and the new protocol can be used in it's entirety.

The second problem, however, is of a different kind. Practically, it can be solved just as easy, but it required all clients to keep track of this change so that they can explicitly only enforce the rule to new blocks. This can be done fairly easily by adding a hard-coded reference to the point at which this new feature has to be accepted to all clients. However, it's clear that this is not the kind of solution you want. If you need to hard-code these kind of things, the protocol will get cluttered.

So basically: **removing functionality clutters the protocol and will be avoided, while adding functionality can be adopted fairly easily as soon as the majority of the clients has been updated**.


---

