Hacker News Reader

> A low barrier to entry when dealing with financial transactions is desirable.

Writing a dapp is much closer to issuing an exotic cross-asset derivative than it is to spending a dollar.

I'd agree that the example of spending a dollar is a gross over simplification. I'd go further to say that there are good reasons to not allow just anyone to issue an exotic derivative. If you're going to draw up contracts, you should have a good understanding of how the rules of the contract work. Although using a language other than JavaScript may help prevent some errors, it does not fix the fundamental issue of responsibility. One should not enter into a complex contract, blockchain or not, without fully understanding the contract itself. If instead of understanding the contract, you are relying on the structure of the language to protect you, well, you're doing it wrong.

> Because dapps are publicly audit-able [...]

Correct me if I'm wrong, but I believe that auditing a Dapp is far from trivial. Only the bytecode is stored in the blockchain, and even if the source code is published, it's hard to see if it corresponds to the published bytecode (and even then, FOSS still have bugs, remember OpenSSH and its latest security bugs). From [1]:

> Q: How can I verify that a contract on the blockchain matches the source code?

> A: AFAIK the best way to do this at the moment is to compile the source code again with the exact same compiler version the author used (so this is something that needs to be disclosed) and to compare the bytecode. (Thomas Bertani @ StackExchange)

In addition, in the source code itself a contract programmer could implement "contractual" backdoors... ahem.. loopholes. And you'll have no recourse.

[1] https://ethereum.stackexchange.com/questions/195/how-can-i-v...

> Correct me if I'm wrong [...]

I agree, this is not trivial, but as you point out, since only the bytecode is stored in the blockchain, examining it must be only way to know what a contract does.

> In addition, in the source code [...]

Yes, the programmer could implement backdoors, no matter what the language is. As such, the end user should not rely on specific properties of a language to make guarantees as to whether or not it the contract does what they expect. It can help, but it's not foolproof.

My point is that if you invest in a smart contract, it is unreasonable rely on outside entities -- either the person who created the contract or the contract language itself --- to ensure that it will work as expected. As hard as it may be to do, if you can't reasonably understand what's going to happen when you enter into a contract, you shouldn't.

> Any script kiddie SHOULD be able to write a dapp. Most people don't [understand that they don't] understand the complexities our our modern financial system, but we don't require that one has a PhD in order to spend a dollar. A low barrier to entry when dealing with financial transactions is desirable.

I think that simple market approach works well when customers are able to understand and compare what they are buying (or investing into), but it doesn't work when customers don't have the means to do so. That's why the financial industry is one of those that needs to be heavily regulated. So, no, IMHO having lowering the barrier to entry to write complex financial instruments that can trade hundreds of millions of dollars is a recipe for disaster, not for useful innovation.

Of course I understand that, if you're a libertarian, you're not going to agree :)