Quote from: iamnotback on March 08, 2017, 03:03:49 AM

Quote from: tonych on March 08, 2017, 12:16:33 AM

Quote from: iamnotback on March 07, 2017, 07:22:27 PM

Quote from: tonych on September 15, 2016, 03:00:01 PM

When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?). One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals. This is exactly what declarative languages do.

The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched. The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code. The language values clarity over power and it is not as powerful as Ethereum's Solidity. It is not turing-complete, and you cannot write even 'Hello world' program in this language. But it is able to solve many practical business tasks.

Although each executed instance of your language is not Turing-complete in isolation, the system of instances is Turing-complete because you have the ability to reference global memory in the form of the data feed. Thus you can still have scenarios of unbounded recursion and even live or dead locks.

Craig Wright had schooled Nick Szabo and Gregory Maxwell on this point also.

So you have not prevented hacks. And you have somewhat crippled the language compared to Solidarity. You may argue you've made the intent clearer, but when people write convoluted systems with this in order to achieve complex smart contracts by simulating Turing completeness, then it may end up more obfuscated than Solidarity. I really don't see your design strategy as the absolute panacea you seem to claim or imply.

There is a limit on the number of operations per smart contract, data feed lookups included.

It is not a panacea. It is designed to meet the demands of regular users, and they are not convoluted, as the recent superresistant's example shows.

If you need convoluted, go with Solidity, but be extremely careful when you expose complex systems to regular users (unaccredited investors, if we consider investments context). When users are exposed to complex systems that they don't fully understand and that can potentially harm them, the governments will want to "protect the consumer" -- by regulation.

But my point is you can't prevent in the wild people from creating convoluted smart contracts even with your intended to be simple declarative language. Do you really expect users to give a damn and look at the source code of the smart contract? Users demand features such as DAOs. So I don't think you can stop the developers from bastardizing yours as well. Preventing Turing-completeness is very difficult. This is why Bitcoin is very cautious to add new opcodes.

I can't stop them but hopefully most developers are smart enough to find the best tool for the purpose, and there is no lack of choice. Even if they do create something convoluted against all odds, let's see if they find many users.

Quote

Do you really expect users to give a damn and look at the source code of the smart contract?

I dare say yes, if we speak the user's language. The nice thing about Byteball smart contracts is that they can be easily presented in user readable form:

This example is from my article https://medium.com/byteball/making-p2p-great-again-fe9e20546a4a#.3k1a7f5yo