Can Bitcoin incorporate the scripting protocols of Ethereum without a fork?

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/

Cal Abel

Posted 2014-01-24T04:19:40.883

Reputation: 111

1Ethereum is not an altcoin, but it supports altcoins on top of it. – John T – 2014-01-24T05:58:24.530

2Ethereum has a coin that it uses for its own transactions called ether. It also within its structure allows unlimited other coins. – Cal Abel – 2014-01-26T07:09:58.653

Answers

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.

MaxSan

Posted 2014-01-24T04:19:40.883

Reputation: 3 680

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 – 2014-01-24T11:48:46.647

I will make this more clear hopefully get that down-vote removed :). – MaxSan – 2014-01-24T12:11:42.880

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.

cdecker

Posted 2014-01-24T04:19:40.883

Reputation: 7 878

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 – 2014-01-26T07:13:16.190

By your description, it seems Ethereum may run into some computational and bandwidth problems, by doing too much at once. – Cal Abel – 2014-01-26T07:14:37.320

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.

Steven Roose

Posted 2014-01-24T04:19:40.883

Reputation: 10 855