Topic: Turing completeness and state for smart contract - page 2. (Read 12240 times)

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

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

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.

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?

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

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?

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

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

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.

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

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.

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

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.

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.

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

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

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

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

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.

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