Bitcoin Forum

If ethereum technology becomes fondamental and useful, would it be wise to modify bitcoin to incorporate its fundamental changes which are the turing completeness and the possibility for contracts to have a state? (as well as a easier scripting language as serpent).

Best regards,
ilpirata79

The simple answer is no - what you suggest will never happen. Despite both being blockchains, they have nothing to do with eachother - they have totally different designs and goals.

If it becomes useful, I imagine there will soon be a eth-like sidechain on bitcoin.

Maybe a sidechain which is merge-mined with bitcoin. I don't see that like an impossible outcome...
at that point, what would the usefulness of Ethereum be?



By the way, it already exists. It's called rootstock. How is it that some people see it as a joke?

So the "question" now might be:

is it better to have to different chains, i.e. bitcoin and rootstock, with the second being a superset, in terms of functionalities, of the first, or is it best to just have the second (so just ethereum)?

I tend to think that is better to split them, but I don't have any real evidence to support that assertion.

Some thoughts however:
pros (for splitting): two different chains can be tweaked differently (e.g. block time) to achieve different objectives.
cons (for splitting): one single chain is easier to mantain, to debug, to develop, to upgrade compared to two (this may be a strong cons).

What do you guys think however?

There will be no public block chain with Turing complete scripts ever, because that would mean that absolutely any algorithm would be accepted in a script, including non-terminating ones. A smart contract with an infinite loop would be a very bad thing.

But, but Etherium is Turing complete, isn't it???  No it is not, it can't be. It would be killed by DOS in no time. The language may be Turing complete in theory, but since the system must guarantee that all scripts terminate in finite time (I think they do it by requiring that each instruction has a cost) it is not Turing complete in practice. They could have used a total language in the first place, where you have a guarantee that every program terminates.

I know this isn't really an answer to the OP question but I wanted to point it out ;)

On the pedantic points, I echo what tucenaber just said-- and I could not say it better.  (Also, see #bitcoin-wizards past logs for commentary about total languages. I also consider that a major useful point for languages for this kind of system).

People looking for "turing complete" smart contracts inside a public cryptocurrency network are deeply and fundamentally confused about what task is actually being performed by these systems.

It's akin to asking for "turing complete floor wax".   'What does that? I don't even.'

Smart contracts in a public ledger system are a predicate-- Bitcoin's creator understood this. They take input-- about the transaction, and perhaps the chain-- and they accept or reject the update to the system.   The network of thousands of nodes all around the world doesn't give a _darn_ about the particulars of the computation,  they care only that it was accepted.  The transaction is free to provide arbitrary side information to help it make its decision.

Deciding if an arbitrarily complex condition was met doesn't require a turing complete language or what not-- the verification of a is in P not NP.

In Bitcoin Script, we do use straight up 'computation' to answer these questions; because that is the simplest thing to do, and for trivial rule sets, acceptably efficient.  But when we think about complex rule-- having thousands and thousands of computers all around the world replicate the exact same computation becomes obviously ludicrous, it just doesn't scale.

Fortunately, we're not limited to the non-scalablity-- and non-privacy-- of making the public network repeat computation just to verify it.  All we have to do is reconize that computation wasn't what we were doing from the very beginning, verification was!

This immediately gives a number of radical improvements:

"The program is big and I don't want to have to put it in the blockchain in advance." ->  P2SH, hash of the program goes into the public key, the program itself ends up being side information.

"The program is big but we're only going to normally use one Nth of it-- the branches related to everything going right"  -> MAST, the program is decomposed into a tree of ORs ans the tree is merkelized. Only the taken OR branches ever need to be made public; most of the program is never published which saves capacity and improves confidentiality.

"The program is big, and there are fixed number of parties to the contract. They'll likely cooperate so long as the threat of the program execution exists."  -> Coinswap transformation (https://bitcointalk.org/index.php?topic=321228.0); the entire contract stays outside of the blockchain entirely so long as the parties cooperate.

"The program is big, and there are fixed number of parties to the contract, and I don't care if everything just gets put back to the beginning if things fail." -> ZKCP (https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/); run _arbitrary_  programs, which _never_ hit the blockchain,  and are not limited by its expressive power (so long as it supports hash-locked transactions and refunds.)

"The program is kinda big, and we don't mind economic incentives for enforcement in the non-cooperative case"  -> challenge/response verification; someone says "I assert this contract accepts," and puts up a bond. If someone disagrees, they show up and put up a bond to say it doesn't. Now the first party has to prove it (e.g. but putting the contract on the chain) or they lose their bond to the second party, if they're successful they get the bond from the second party to pay the cost of revealing the contract.

"The program is too big for the chain, but I don't want to depend on economic incentives and I want my contract to be private." ->  ZKP smart contracts; PCP theorem proves that a program can be proved probabilisticly with no more data than log the size of its transcript.  SNARKS (https://bitcointalk.org/index.php?topic=277389.0) use strong cryptographic assumptions to get non-interactive proofs for arbitrary programs which are constant size (a few hundred bytes). Slowness of the prover (and in the case of snarks, trusted setup of the public key-- though for fixed sets of participants, this can be avoided (https://bitcointalk.org/index.php?topic=516531.0)) limit the usefulness today but the tech is maturing.

All of these radical improvements in scalablity, privacy, and flexibility show up when you realize that "turing complete" is the wrong tool, that what our systems do is verification, not computation.  This cognitive error confers no advantage, outside of marketing to people with a fuzzy idea of what smart contracts might be good for in the first place.

More powerful smart contracting in the world of Bitcoin will absolutely be a thing, I don't doubt. But the marketing blather around ethereum isn't power, it's a boat anchor-- a vector for consensus inconsistency and decentralization destroying resource exhaustion and incentives mismatches. Fortunately, the cognitive framework I've described here is well understood in the community of Bitcoin experts.

gmaxwell is the point of payment channels/level-2 layers not to enable more advanced uses of "smart-contracts" ?

From my understanding the Script language will be used to form contracts, but all computation of such will sit outside the blockchain itself.

What I am missing is however the smart-contract construction on this layer and how it will look exactly. Is MAST going to be required before we have a "real" smart contract interface?

I thought Greg's description above was really good and was curious how Vitalik would reply so I posted it over in the Ethereum subreddit. For anyone else interested, he gave a detailed response at https://www.reddit.com/r/ethereum/comments/4g1bh6/greg_maxwells_critique_of_ethereum_blockchains/d2e24sy

There was (is?) a limit on number of ops in a Bitcoin block, looks like predicates are not as efficient as some Bitcoin devs think.

It's state that matters. You can't have true interoperability without it.

Really interesting read, still my biggest fear about Ethereum is if their scaling plans fails, then we will have just another fancy "dead horse". 

However if ETH will succeed in its scaling plans(which I am sure it will) then we will end up having an even bigger corpse than a "dead horse" in the crypto-universe: a dead dinosaur called BTC....

Don't forget BTC has a reasonable network effect at its advantage and can incorporate ethereum features through merge-mined sidechains. I bet that this will be the outcome:
Bitcoin used for monetary transactions and a sidechain used for smart-contracts/bots.


Best regards,
ilpirata79

Sorry no offense, but ETH is better in every possible regard: speed, scalability, encryption, smart contracts etc. ETH will encorporate BTC ultimately as a side-chain out of respect for historical purposes.

That also seems confused to me. Bitcoin and Bitcoin smart contracts have state-- if they didn't they wouldn't work at all. But rather than having sprawling state that requires random access to the system and hiding the true cost of providing this state, Bitcoin transactions flow state information from inputs to output.

The result is a model which is more like monads in purely functional languages: A transaction collects some state (txin selection), creates new state (new txouts), and the scriptsig/witness proves that the state transition was permitted.

Similarly to the move to thinking in terms of verification instead of computation, this insight often permits transformations that improve scalablity.  E.g. instead of storing the state explicitly in outputs, in some applications you can store a hash tree over the state; then subsequent actions can simply show access and update proofs. This kind of compaction can't be used in all cases, but where it can it's very efficient.  I spoke some of these advantages on the subject of code above (e.g. MAST), but they apply no less for state.

An example of elided state, a simple one without state updates, is https://blockstream.com/2015/08/24/treesignatures/ which shows the construction of fairly efficient, pretty private, accountable multisig that avoids putting all of the applicable public keys into the blockchain.

The advantages of this kind of construction will be more clear to more people as future script enhancements restore functionality in Bitcoin script that was disabled; which will bring back the ability to enforce constraints on state carried from inputs to outputs.

There is one area where I think Ethereum might have a smart contract advantage, that I haven't seen Bitcoiners discuss. It looks to me like writing Ethereum contracts is more 'natural' to developers than writing complex script constructions using Bitcoin. I haven't written scripts in either, but as a dev this is the sense I get by looking at their scripts. Is this a legit problem? If so, have the Bitcoin devs thought much about how to make Bitcoin script construction more accessible for normal devs (maybe either via dev tools, or by some simplified declarative language that compiles into Script)?

Writing smart contracts is inherently not 'natural' software development similar to how writing legal contracts are not 'natural' prose. The requirements and implications are quite different.

The kinds of data the software works with is different. The resource costs are radically different. The execution environment is necessarily very different-- how often do you write ordinary programs whos execution gets rolled back in a reorg or could "run out of gas"? The implications of failure are typical fairly different. The interactions with privacy are very different than ordinary software development.

Often the "simply written" smart contracts are grievously insecure-- I guess you could say that they're not that smart. :)

There can be cases for wanting to use legacy software in a smart contract context, for interoperability or rapid prototyping-- but the ethereum model isn't particular good for that either (it imposes enormous overheads on software compiled from traditional languages).

Effectively, when you create a de novo smart contract you are designing a cryptographic protocol. It turns out that it's fiendishly hard to do this, even for experts, and the science of creating good tools for it is yet unsolved. (Though it's one of the long term problem areas that I'm funding people to work on.)

I think the Bitcoin technical community has some good starting premises about what kinds of constructs facilitate making tools that make it more feasible to construct new smart contracts with less than super-human effort-- things like having top level building blocks that work like monotone boolean functions, so that you can safely compose standardized parts without understanding the internals and your software can reliably analyze the space of possible outcomes.

This problem doesn't arise when we write smart-contracts for Bitcoin/Ethereum.

Yes it does. A 'smart contract' that never interacts with anything outside the network (including users) is pointless. The smart contract itself may not set the history rewrite, but the possibility of them must be accounted for in the design of the contract.

I see, didn't know that the problem of reliable oracles had been solved.

No offence, buy you don't really know what you're talking about.

What is a de novo smart contract?

Could you tell us more on what you are trying to achieve in this field you are funding people in?

You don't want to understand what I am talking about. But that's fine and understandable. Every empire falls because of the arrogance and shortsightedness of it's followers who loose their flexibility and open-mindedness and begin to believe that they are invincible and are here to rule all. This will be the case for BTC. Reading your comment just reinforces this truth. With your attitude you are setting yourself up to a rude and painful awakening. But you cannot say anymore that you haven't been warned....

I'm interested in what you mean by this. If we take a simple smart contract like a multisig, are you considering that to be something that "does not interact with anything outside the network"? If yes that seems to contradict your statement that those contracts are pointless. If not, what are the issues with chain reorgs in this example if any?

If I understand it correctly, I think thats exactly the point, they wish to include loops (and by including loops in general, also infinite loops), the infinite loops are then solved practically by the gas mechanism. The problem isn't with the halting problem, but that the system produces the first shared computer, that has the most slow and expensive computation, and so won't be used for computation but only computationally enhanced verification, and thats just not as cool.

All I was saying is that it isn't Turing complete. There is no halting problem when you have a "gas mechanism".

Yes, smart contracts are different from normal software in many ways, but I'm not seeing why exactly this means they shouldn't be written in a declarative language. My premise is that a language like Script just adds to the developer's mental load without any corresponding benefit over a declarative language (which I am assuming are easier for the human mind to understand).

Note that I'm not suggesting Ethereum's language is better. This is just about declarative vs. <whatever Script's style is called>. I'm wondering whether it is possible to create a language that has equal power to Script, which just happens to be declarative. So for instance it would obviously not have loops, no gotos. Maybe just if statements / if/else, support for variables, the existing opcodes converted to declarative functions, and a cap on the # of instructions.

So for instance a P2PKH 'script' might look like:


Are there reasons why if Satoshi had done this instead of Script it would have been bad?

Really interesting read, still my biggest fear about Ethereum is if their scaling plans fails, then we will have just another fancy "dead horse"

How about now?

Though your example is making a distinction without a difference, something like that could easily be converted to something more Bitcoin script like... but the real differences I'm highlighting are things like avoiding mutable state, which-- among other benefits-- would absolutely preclude vulnerabilities like that re-entrancy race in the DAO, which is currently in the process of proving to the world that ethereum isn't the decentralized system it has claimed to be (so, in that sense, the error prone smart contracting programming model has done the world a service).

Do u think, this statement is valid for those who are building smart contract on bitcoin blockchain, e.g. Rootstock or CounterParty?

Interesting thread thanks :)  

Personally I think bitcoin script was already overly complex, I'd rather see things compartmentalized in accordance with unix philosophy.  Also keep in mind that contracts are conflict resolving tools, and as such fixing them with code totally misses the fact that conflicts arise due to circumstances unknown at first, which therefore haven't been coded for.  As such, they could only make business more difficult.  Even if somehow there was a magically trustworthy oracle.  

That being said, I could see the thing as more of a tool for decentralized automation.  Change the name and now it makes more sense.  But not a whole lot more.  When I think of automation I think of a project with a planner.. in which case - why the decentralization?  Extra useless overhead.  However I can' t immediately rule out the existence of a reasonable use-case somewhere like I can easily do for smart contracts.  

Add to this that ethereum has the economic distribution model of dogecoin and I'm not sure what's left.  I mean seriously, did nobody on that team consider that their coin would be around long enough that the money supply would matter?  

The argument in Bitcoin is simple: If doing anything interesting with Bitcoin forces you back to a purely trusted third party, the value of Bitcoin as a permissionless asset is diminished.

Bitcoins value comes partially from decentralization, and that value is maximized by minimizing the frequency at which you need to put those benefits aside. No more justification is needed.

Re other things copying ethereum's smart contracting system. For me, the recent snafu in ethereum is experimental confirmation of a long held belief about that design. My view that the design is flawed wouldn't be changed by putting it another altcoin or a sidechain. That doesn't mean I'm opposed to other people trying other things, -- more experimental evidence.

Ethereum and Bitcoin are heavily flawed in their own ways. Maybe even being polar opposites. Smart contracts aren't the best use for hashing power, but it's a good start.

With the clear difference is that the attack universe of the first is more Turing complete.

 :)

Whilst this probably won't be understood by nearly anyone on this forum the AT CF code is as follows:


This is AT machine code (there is no high-level language for AT at the moment and after the DAO bungle we aren't in any hurry to add one), however, it has been in production for well over a year (without a single issue being reported from two separate blockchains that are using it).

It is *minimal* and incredibly efficient (it doesn't even basically do any executing until the CF expiry time is reached).

I don't think that Turing complete smart contracts are impossible to do right but they are extremely difficult to do right and so should IMO at this stage be limited to very small things like the example above (and tested for every feasibly possible scenario).

Where is that data from?

It's not "data" but "code" and numerous instances of this code has been running on the Qora and Burst blockchains for well over a year (it is how much of the development funds have been raised).

Details of AT itself can be found here: http://ciyam.org/at/
(it is highly technical documentation)

Thanks gmaxwell.
I gave the exact same explanations to a group of friends who are developing on ethereum. I totally agree with this.

And, moreover,, thinking how legalese is complex and "dumb" at the same time I don't know if it is that good to make some software run this "complexity dumbness" with code.

 ;)

I would agree that the amount of effort required in order to get such things written and working "as expected" is far from trivial (even with such a tiny program such as the Crowdfund example I posted).

However it really isn't that much different to writing critical code for other things (such as medical equipment or software for spaceships) so I don't think it is without precedent (but is perhaps quite alien to the vast majority of programmers).

Rushing into writing complex "smart contracts" (and putting them in charge of millions of dollars worth of tokens) is not a good idea. This is a new and emerging field that is most likely only going to improve through a lot of unfortunate mistakes.

Exactly.

But this is where we are now: a lot of money has been put into the big "blockchain" pot. Who put that money wants results sooner rather than later and there it goes the lack studying and preparation.

I want to stress my point of view that you can easily find somewhere else: we can not allow any smart contract to rule anything that is subject to so much discretionality.

Just seeing your comment now. Yes, the DAO stuff is evidence against having such an expressive scripting language. However I see the mutable state vs script-like language are fairly orthogonal. Assuming that Bitcoin's more constrained system of state is better, what I wonder is whether a more declarative way to write Bitcoin-script-equivalent stuff would still be preferable. As mentioned above, I think the declarative style puts less mental load on developers and is more 'natural'.

The gist of an earlier comment of yours seemed to be: "writing smart contracts is inherently hard and unnatural, so it's fine if the scripting language is hard to understand." I just don't see how one aspect of writing contracts being hard (getting the logic right) implies that it would be better for other aspects to be harder than they need to be.

If a declarative version of Bitcoin script made mistakes less likely, what is the downside? Are you worried about newbs who just learned a bit of javascript thinking they can write secure smart contracts just because Bitcoin script v2 might look a bit more like javascript? So the fact that current script looks intimidating is actually good? If so would it have been even better if Satoshi made all op codes of the form OP_XYZ where X, Y, and Z were digits? And maybe disallowed spaces when not including them would still be unambiguous? That would certainly reinforce in people's mind that writing Bitcoin script is tricky.

You misunderstood what I was saying.

A declarative model doesn't reflect the reality of these systems well. It is easier to get started, but hard to do things right, and very hard or impossible to to be confident that you got things right when you did.

A more functional model reflects the reality of the systems better, while also providing powerful scaling and analysis benefits.  I believe it is possible to construct systems which are harder to get started, but once you get something working its very likely to get things right, and hard but far from impossible to _prove_ you're achieving the properties that you set out to achieve.

I haven't proven that better can be done, yet (unless you count Bitcoin script)-- but what DAO/ETH seem to be proving is that at least that design is too dangerous to be used-- when their highest profile contract, reviewed by the designers of the system/language, got robbed blind by a rather simple vulnerability.

That makes more sense. Thanks for clarifying.

Exactly, if someone care to modify the technology then it would prove be  very beneficial for us. As because many cryptocurrency are coming up each day so to contest the compedition it's necessary to bring the latest change.

Well.. anyone who has worked in SQL would know what a ROLLBACK is. (..and running out of gas could be considered a time condition ie it's taking too long, fail )

That is a technology that has had to manage complex financial 're-orgs' for a looong time.

There are many occasions on a daily basis that a SQL function call fails mid-sequence and you have to 'go back to the beginning..' .. undoing everything that the transaction has done up to that point. It's absolutely taken into account in the design of your system, and expected. 

Maybe using a system similar to the way SQL handles rollbacks and designing your system with that 'paradigm' in mind, would prove helpful when writing and running smart contracts, and then the re-orgs when they invariably do fail.

 https://www.reddit.com/r/ethereum/comments/4g1bh6/greg_maxwells_critique_of_ethereum_blockchains/d2e24sy

This is why I love this forum. 
As someone who only knows basic programming, its amazing to come to a thread like this and learn about things like "Turing Completeness" on my lunch break.

Is it possible to feel smarter and dumber at the same time?
The more learn, I realize how little I know...