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/

  • 1
    Ethereum is not an altcoin, but it supports altcoins on top of it.
    – John T
    Jan 24, 2014 at 5:58
  • 2
    Ethereum has a coin that it uses for its own transactions called ether. It also within its structure allows unlimited other coins.
    – Cal Abel
    Jan 26, 2014 at 7:09
  • @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. May 8, 2020 at 16:12

3 Answers 3


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

  • 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
    Jan 26, 2014 at 7:13
  • By your description, it seems Ethereum may run into some computational and bandwidth problems, by doing too much at once.
    – Cal Abel
    Jan 26, 2014 at 7:14

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.

  • 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. Jan 24, 2014 at 11:48
  • I will make this more clear hopefully get that down-vote removed :).
    – MaxSan
    Jan 24, 2014 at 12:11

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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