201–210 of 217 posts
Earlier quoted context omitted.
This doesn't sound right to me. Contract law should not require turing completeness. First order logic should be more than sufficient. How does having a loop in contract law make any sense?
Would regular payments based on criteria be an example? A paycheck basically.
Earlier quoted context omitted.
Right, but would the deduction commit even if the send fails? Isn't this the whole concurrency 101 "Atomic deduct and send" problem?
It's not really concurrent, the VM runs one transaction at a time. The send returns false if it fails. So if you check for that, you can throw an exception, which rolls back the whole transaction just like in SQL. The reason the send doesn't automatically throw is that if you were doing lots of sends in a loop, you'd actually want to ignore the exception, so if one send fails it doesn't block everybody.
This sounds like the wrong default behaviour. If we're talking about sending money, and there's a list of people to send money to, I would say that the default behaviour should be to throw an exception, because if not you could end up having money not be properly redistributed.
For example, a simple smart contract to share costs. If one member not longer participates then shouldn't their cut be given to the remaining participants?
The fact that it doesn't roll back everything by default concerns me quite a bit...
Earlier quoted context omitted.
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.
Coq is pretty specific in what it does like css (also Turing incomplete. There is a pretty low bar for features needed to make something Turing, it doesn't take much more then mutable variables and a while loop or recursive functions to impliment rule 110
The 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.
However, Coq can only run those computations for a given number of steps; in other words, you can't say "run this until it halts, and give me the result", but you can say "give me the result after 3^^^3 steps, or 'Nothing' if it hasn't halted by then".
The reason this is interesting in this discussion is that Ethereum uses "gas" in a similar way.
Earlier quoted context omitted.
Coq is pretty specific in what it does like css (also Turing incomplete. There is a pretty low bar for features needed to make something Turing, it doesn't take much more then mutable variables and a while loop or recursive functions to impliment rule 110
css3 is turning complete iirc
Earlier quoted context omitted.
The fact it has to go to the US courts is why it's a failure.
How is not being above the law a failure of a project? If the goal of the project was to be above the law and be accountable to no-one, then the project was doomed from day one. Then again, I never bought the concept of the DAO (lawyers are incredibly important people who are undervalued in our society).
"Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference."
Earlier quoted context omitted.
It's not really concurrent, the VM runs one transaction at a time. The send returns false if it fails. So if you check for that, you can throw an exception, which rolls back the whole transaction just like in SQL. The reason the send doesn't automatically throw is that if you were doing lots of sends in a loop, you'd actually want to ignore the exception, so if one send fails it doesn't block everybody.
>if you were doing lots of sends in a loop, you'd actually want to ignore the exception, so if one send fails it doesn't block everybody. This sounds like the wrong default behaviour. If we're talking about sending money, and there's a list of people to send money to, I would say that the default behaviour should be to throw an exception, because if not you could end up having money not be properly redistributed. For…
The best pattern is not to put sends in a loop at all. Just update a ledger inside the contract, and have each user call a withdraw() function to get their money. That way if you're careful you can even use call.value, so users can include as much gas as required, and can withdraw the money directly into any sort of contract they like.
Earlier quoted context omitted.
Yes, this would be considered fraud in the US legal system, but that's not the point. * If you have to involve the legal system then the project has failed because the whole point was to have a contract enforcement mechanism which doesn't need a court system. * If a legal system can override the smart contract then there's no point to even having one since the ultimate authority still resides with the state.
> Yes, this would be considered fraud in the US legal system, but that's not the point. It is the point though. It is the only point that will matter. Since the writers of the software are US citizens, it's most likely that they will get sued if the transaction is not aborted. Any scenario where the money is not returned to investors will result in the investors suing people -- no matter how much conviction people ha…
So what is the plan going forward - if either party in a "smart contract" feels disadvantaged by the outcome - they go running to the law and outside jurisdictions for remedy? Isn't avoiding all that overhead the point of have a "smart contract" in the first place?
It's an interesting concept and I'd like to see the project survive (from a technology standpoint; I not risking any cash with it)... maybe it is good they did a faceplant 6 weeks in and can start answering some very hard questions that have come up.
Earlier quoted context omitted.
Correct. Programmatic contracts should have democratized the entire business but instead this new scheme creates a new class of "lawyer".
I strongly prefer "laws" that are based on mathematics/computability theory than on social conventions.
Earlier quoted context omitted.
This is a very snarky hyperbole. Solidity has as much to do with Javascript as Java does. For starters, Solidity is a compiled, typed language. It is still new and has to be improved.
> Solidity is a compiled, typed language. The same language can be both compiled and interpreted, this doesn't affect the semantics of the language. For example, OCaml ships with both a compiler and an interpreter. There exist AOT compilers for JavaScript too. Also, JavaSript is a typed language. It is just dynamically typed and does too much type coercion.