Turing completeness and state for smart contract

[Come-from-Beyond]

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.

[1715151270]

1715151270

[1715151270]

1715151270

[1715151270]

1715151270

[1715151270]

1715151270

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

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

[JackH]

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.

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?

[KoinMaster]

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.

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

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

[christianlundkvist]

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'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?

[nihilnegativum]

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

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.

[tucenaber]

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

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

[go1111111]

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.

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:

Code:

function( pubKeyHash, sig, pubKey){
    h = OP_HASH160(pubKey)
    if ( pubKeyHash != h ) return false
    return OP_CHECKSIG( sig, pubkey)
}

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

[StrawberryF]

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

[gmaxwell]

but I'm not seeing why exactly this means they shouldn't be written in a declarative language

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

[RocketSingh]

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?

[funkenstein]

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?  

[gmaxwell]

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.

[Decoded]

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.

[hv_]

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.

 

[CIYAM]

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

Code:

00000000* STZ $00000000
00000005  FUN @00000001 Get_Current_Balance
0000000c  BGE $00000001 $00000002 :0000004e
00000016  FUN @00000003 Get_Creation_Timestamp
0000001d  FUN A_To_Tx_After_Timestamp $00000003
00000024  FUN @00000004 Check_A_Is_Zero
0000002b  BZR $00000004 :00000054
00000031  FUN @00000005 Get_Amount_For_Tx_In_A
00000038  FUN @00000003 Get_Timestamp_For_Tx_In_A
0000003f  FUN B_To_Address_Of_Tx_In_A
00000042  FUN Send_To_Address_In_B $00000005
00000049  JMP :0000001d
0000004e  FUN B_To_Address_Of_Creator
00000051  FUN Send_All_To_Address_In_B
00000054  JMP :00000054

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

[JackH]

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

Code:

00000000* STZ $00000000
00000005  FUN @00000001 Get_Current_Balance
0000000c  BGE $00000001 $00000002 :0000004e
00000016  FUN @00000003 Get_Creation_Timestamp
0000001d  FUN A_To_Tx_After_Timestamp $00000003
00000024  FUN @00000004 Check_A_Is_Zero
0000002b  BZR $00000004 :00000054
00000031  FUN @00000005 Get_Amount_For_Tx_In_A
00000038  FUN @00000003 Get_Timestamp_For_Tx_In_A
0000003f  FUN B_To_Address_Of_Tx_In_A
00000042  FUN Send_To_Address_In_B $00000005
00000049  JMP :0000001d
0000004e  FUN B_To_Address_Of_Creator
00000051  FUN Send_All_To_Address_In_B
00000054  JMP :00000054

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?

[CIYAM]

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)

[Karartma1]

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.

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

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.

 

[CIYAM]

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.

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

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.