Earlier quoted context omitted.
I totally agree, but the reality is that in order to write contracts that are sure to be correct, you need a level of expertise that involves much more work than just learning how to write programs. Knowing the syntax and usage of a rigorously-typed language like Agda is the easy part.
Then the platform is flawed. Average programmers should be able to understand it easily. It's not that hard, some wants X and some wants Y in exchange. I'm not a lawyer but I write contracts with my clients. If you keep things simple it should fit most people. making g smart contracts complicated you keep it in the area of a small elite who are knowledgeable of playing safe with it. I wold go as far as make it as sim…
Ethereum is Doomed
211–217 of 217 posts
Re: Ethereum is Doomed
#212Earlier quoted context omitted.
We want to allow recursion and loops. We want to be able to run arbitrary code. We just need to be a little wiser about how we do it.
How did this madness start? I don't want law to be turing complete. Especially programatic law. Why are people so nonchalant about this? This is not sane design. You want totality and termination proofs. At least that's what I would look for in any programatic system of law.
Re: Ethereum is Doomed
#213The problem with Turing completeness is that if it's not there from the start, people inevitably end up needing features that aren't present in the restricted language, and then a Turing complete language is added to either the original system or a successor, and being an afterthought it usually ends up being a hack job. Examples: SQL was supplemented with procedural languages for stored procedures, Excel was supplem…
There are languages which are both expressive and Turing incomplete, for example Coq. In the Coq language, Turing incompleteness is actually needed to be able to make complete proofs. Maybe Solidity would have been better implemented within Coq, but it's too late now.
That would be a really nice application for formal methods, it seems.
Re: Ethereum is Doomed
#214Earlier quoted context omitted.
So, just write your contract in a non-turing complete subset of it. Just because the power is there doesn't mean you have to use it if you don't want to.
According to the article, you need to write interfaces that accept a function and call it somewhere down the line. At this point you already cannot guarantee the lack of recursion, simply because the supplied function can call your function again. It is simply not possible to write a code that always halts, unless you never even call the supplied function.
Re: Ethereum is Doomed
#215If you have the ability to invest, this is a good time to do so. you're about to see massive increases in valuation.
Re: Ethereum is Doomed
#216Earlier quoted context omitted.
Not a knock on your post, but "checked by experts" is like saying "QA looked at it". If the tools aren't in place to warn/prevent, re:"stop things like this", unintended executions are only going to continue. It is the brave new old world.
That's exactly it. The current op codes allow for this kind of mistake. So mistakes like this will happen.
Re: Ethereum is Doomed
#217Earlier quoted context omitted.
As long as you never convert into traditional currency, how will they know you participated in a transaction?
As long as you never convert, what use is it? (and that's assuming your country doesn't require you to declare cryptocurrency gains)
I don't think it's relevant what the person receiving the Bitcoin does with it after (converting directly to dollars, holding, or buying other goods/services), since those are the same things people do with regular dollars anyway.