91–100 of 217 posts
Earlier quoted context omitted.
What _legally_ exploitable bank bugs have you heard of? Keyword there being legally.
Jeremy Clarkson published his bank account details in his column to back up his assertion that you can send money to a bank account but not withdraw any. However apparently anybody can set up an automatic payment from any account to any other account...
Earlier quoted context omitted.
So you mean to tell me that taking away the ability to write generic programs to validate contracts is good design? See Rice's Theorem ( https://en.wikipedia.org/wiki/Rice%27s_theorem ). Once you have turing completeness verifying any non-trivial program property starts requiring grad school experience and real proficiency with writing and verifying proofs. Most people, including programmers, do not have the training…
So instead of hiring a juris doctor lawyer to review my contracts, I'll hire a PhD computer scientist ;)
My response is the same for both Bitcoin and Ethereum:
Even if these technologies are only used by trained professionals, they can still be revolutionary. Almost no one can safely operate a printing press, and yet that invention has toppled empires.
At worst, these are back office technologies. At best in a decade or two someone will figure out how to design a good enough GUI that a novice can safely explore a powerful subset the technology, trusting that bumpers are in place around the sharp edges.
The programming classic "Mythical Man Month" had a chapter for the "second system effect". Its where developers put lots of complicated features in to the second system in a series. Its a pattern for failure. In this case, Ethereum developers built a much more complicated cryptocurrency by making it Turing complete - to the extent of writing their own new computer language and virtual machine to run it. They skipped…
In all likelihood, a working and reliable Ethereum simply requires computer science theories we don't have yet. A working Solidity would probably look something like Ada, but with types and invariants the likes of which we've never seen. Its potentially a very interesting research subject! But for now, yes, investing in Ethereum is like climbing aboard in a rocket aimed at Mars- exciting and futuristic, but unlikely to get you where you hope to go.
I wrote this originally in response to a post by cyphar ( https://news.ycombinator.com/reply?id=11942889 ), but I'd really love a response from anyone with more knowledge or thoughts on how the law might interpret this situation in relation to already existing "virtual legal systems". cyphar wrote: "It was definitely fraud. Either it was a contract, in which case "taking $50 million without anyone's consent" doesn't…
Legally speaking, CCP goes out of its way to emphasize that isk are play tokens money with no cash value, and losing it all is part of the game. TheDAO/Ethereum supports exchanging ether for money. And anyone who lies about contract (beyond smiling and saying "here the contract code, sign it if you want" is commiting a fraud
CCP officially supports converting money to ISK, and there are 3rd party exchanges for ISK to money. My understanding was that TheDAO ran purely on ether, and that any exchanges for money (be it fiat or another digital currency) were also happening purely 3rd party. Does an official line on "don't go the other way" make a material difference? If CCP merely took no stance on it at all, involved in no way but not working to ban anyone doing it, would that change anything? How "seriously" do they have to police it? Is there any case law on this?
>And anyone who lies about contract (beyond smiling and saying "here the contract code, sign it if you want" is commiting a fraud
Can you clarify your point here, and what you were referring to?
1. (and again): How is there any legal contract here, and if there isn't what's the 'fraud' legally (not a colloquial "fraud" with no legal impact)? Are you arguing that people should not be allowed to have non-legally binding (and thus non-contractual) agreements on shifting around "value" based on coded rules?
2. In the case of TheDAO, there were no lies, TheDAO stated clearly and repeatedly that the definitive governing authority was the smart contract itself, and TheDAO organization itself was not (or at least, publicly claims it was not) involved in the controversial smart contract execution. Instead it was at least one of the independent parties to the agreement. So if you were referring to TheDAO I'm confused.
3. In the case of EVE, are you arguing that ISK is different and therefore fraud is legally ok? Or are you arguing that it's still legally fraud?
Earlier quoted context omitted.
That's actually a pretty good decision in my opinion. At least in this case. Think what would happen if they went for alternative solutions: 1. If it wasn't immutable, you'd never be sure when a contract changes. That's the basic assumption about contract - once you sign it, whether in real world, or by doing some action in Ethereum, you don't expect it to change how it works. That's why immutable is good. 2. User-co…
Solidity contracts are already modules which contain functions. They're equivalent to Java classes with static methods or Scala objects. As for namespacing, I don't know how in this day and age programmers can say that's not worth it.
I'm not saying namespacing is bad, just that namespacing as defined in Java is likely not necessary in ethereum world, as I understand it. It would likely just confuse what's immutable vs what's referenced by name.
Earlier quoted context omitted.
It is doomed, who would trust a contract now with real "money"? Unless you have a mathematically rigorous proof that the contract is trustworthy I sure wouldn't.
Hopefully no on ever trusts a contract with 100 mill for a while, but for lower values and simpler contracts... absolutely i would.
What if they had used a language without the possibility of recursion and without loops? I'm being serious. Languages that disallow certain types of recursion, and disallow loops exist. You'd think they would've used something that actually allows for total functions that are guaranteed to terminate in a certain way, instead of a JavaScript clone...
Earlier quoted context omitted.
Ethereum is doomed, and not just because it's based on a poor design. It's doomed because it just shot its credibility to shreds by protecting a single, uniquely privileged contract. Forking proves that the ethereum network cannot be trusted as the neutral contract arbitrator it was designed to be. The idea of smart contracts is an interesting one, and perhaps another project will come along and do it better. But Eth…
Based on a poor design? according to who? It's the most advanced blockchain out there by far and wide! This was a single contract with a flaw, it's like saying the whole internet is doomed because some website got a SQL injection.
Solidity language makes very hard to write safe code:
Is Ethereum/Solidity Suitable for Secure Smart Contracts? It's clear that writing a robust, secure smart contract requires extreme amounts of diligence. It's more similar to writing code for a nuclear power reactor, than to writing loose web code.
Yet the current Solidity language and underlying EVM seems designed more for the latter. Some misfeatures are:
A good language for writing state machines would ensure that there are no states from which it is impossible to recover. A good language for writing state machines would make it painfully clear when state transitions can and cannot happen. A good language for maintaining state machines would provide features for upgrading the security of a live contract. A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read. The current language does not fulfill any of these commandments, and in fact, the last one, involving implicit recursive calls, is what did The Dao in.
The SlockIt team even had the designer and implementor of Solidity perform a review of their code. If he cannot get something like The DAO to be secure, no one can.