Would you please stop posting snarky and/or uncivil and/or unsubstantive comments? especially on divisive topics?
You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.
i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes.
the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.
I think a big part of the complaint is about the implicit assumption that because people are smart, and have experience with cryptography, they necessarily have the experience to design a sane and safe programming language given their goals.
They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense.
If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.
Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success.
I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
That may be, but if so, it might be worse. What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?
Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top.
As far as I can remember, the EVM has never failed, just programmers.
That comparison may be apt. PHP at that time was a mix of some good ideas (ease of deployment) with some horrible ones (register globals on by default is unexcusable), and some poor planning. We all lived with the fallout of that for a very long time.
The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
I don't think your personal attacks lie within the standards set by this community. There are many ways of disagreeing, even vigorously, without being a jackass. It's discrediting to yourself.
You appear to have misconstrued my words. I don't in any way think this is a good idea; just one that has the viral characteristics of "worse is better".
I spent about three thousand words on the smart contracts chapter, attempting to conclusively stab this bad idea in the face and supply a suitable rhetorical ammo dump for anyone faced with having to deal with these things to kill the idea stone dead. Absolutely everything about smart contracts is terrible and misconceived. I don't believe there is any way to do them right, because the idea is fundamentally wrong.
Are you asserting Szabo's original smart contracts idea "is terrible and misconceived", or Ethereum's implementation "is terrible and misconceived". The latter, I would have to agree; hard forking as a response to these kinds of security holes is neither sustainable nor scalable, and I'm very partial to mechanical proof-based designs and implementations as a result.
Szabo's idea was a hypothetical for two decades. Ethereum is the first smart contracts platform people actually write for. There were attempts to do it previously, but Ethereum is the one that actually took off.
So if you're talking about Ethereum as a bad implementation of a good idea, you're weighing up reality against something that was a hypothetical from 1994 to 2014.
In any case, there's plenty really obviously wrong with the idea of immutable smart contracts. Legal code is a bad match for computer code; immutability means changes in circumstances can't be allowed for; immutability means you must code with zero bugs; the oracle problem (getting real-world data in and out of your smart contract) ...
"Dr. Strangelove" is the story of a smart contract going wrong, unstoppably, immune to human intervention.
Szabo's stuff is better than the reality - he does actually understand law as well as code, and at least early on he considered there was a role for human intervention - but it's still the sort of thing that's "interesting" rather than "a good idea".
> But if banks and major retailers who have huge budgets can get hacked, of course we can too.
Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked".
When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny.
When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day.
The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website.
There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.
I'm inclined to agree but I must say this traditional system is unscalable. Sure it can detect millions of dollars of fraudulent transactions, but what if it's a single person who's the victim of identity theft and lost just a few thousand dollars? A few thousand dollars is nothing in the grand scheme of things but they are a lot to a single individual.
I've had calls from my bank's fraud detection department about single transactions of less than fifty pounds that they were concerned weren't from me, so clearly the traditional system is plenty scalable enough.
Right, and also, a good part of why credit cards have 2-3% overhead is essentially insurance against chargebacks. I'd rather pay $51 for groceries every week than $50 for groceries plus a risk of irrevocably losing tens of thousands of dollars at some point with no warning.
If cryptocurrencies think that they can provide this service for substantially cheaper than 2-3% (note that this is an additional service on top of simply making the transfer happen, so mining fees aren't the right thing to compare), that sounds awesome, but also I'd like to understand why it's possible.
Even that 2-3% is way high, in some places like Europe and Australia, interchange fees are capped at values around 0.3% and that doesn't seem to be a hindrance in getting business done.
But Bitcoin and Ethereum can do this too. In fact Ethereum already has done it (and is arguably designed to do it). Ethereum simply has to convince a majority of the participants to fix the bug and reset to a good hash (whereas bitcoin would need a majority of the mining power unless they went out of band and used old school politics/force/coercion).
From this and your previous comments, I am trying to figure out your basic point. Would you summarize it as, "I have a low tolerance for financial risk and others should think as I do"?
I don't think that's a good way to summarize my point - I have expressed no opinion about financial risk, either my own or others. (Did you mean to address someone else?)
However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point.
Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed).
If you really want a simple point out of me, I think G. K. Chesterton made it in 1929:
> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.
One of the more important skills in this craft is the combination of intuition and knowledge to know when you don't know something well enough to achieve the goal. The difference between "ambition" and "hubris" is small but critical.
Then you shouldn't be working on it. If you can't be humble, you should not be working on things that can hurt people because you're creating risk for them that they can't actually measure. (It's why I consciously avoid such projects; knowing one's propensity to arrogance makes it unethical not to.)
If it's important, you need to be good. If it's very important, you need to be good and sure.
The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography.
But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that
The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable.
This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation.
It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.
There's essentially no legitimate use case for crypto-currency. Cypherpunks have been at it for decades and all they have to show for it is drugs, ponzis, assassination markets, and conspiracy theories.
It would be nice to see some sort of casual hawala-type federated micropayments system based on real national currency, with instant settlement, low fees, and no fake money value store. But, that would be a pre-9/11 idea. Nowadays that's basically illegal and useless.
Paypal is more or less good enough, and hopefully regulators and market forces will control the fees and abuses.
Sorry, but have you looked on the democracy and justice-culture index maps worldwide? The democratic, end-of-history, justice-seperatly-delivered state is currently in full retreat.
I agree, the futurists got it the wrong way around, assuming something cyper-punk-currency enough would blow the state away and allow for crypto-anarchy to rule. Instead, we got states that on slight economic decline implode on themselves (a whole thinker caste in denial about human nature hunting scape goats) and suddenly the crypto-currency nonsense doesent look idiotic, because it can work on, even as the state becomes hostile.
Thats the vision- a somalia like decline, but society moves on, with schools back uped to youtube, with contracts backed up to the block chain, with the currency back uped to bitcoin. I find the ideals of crypto-anarchy laughable (those guys would be gunned down on the first corner, in a real anarchic world), and yet, i can agree to the path we taken. Cellphones and facebook, to have a culture of shame, that fights wild mobs and public hysteria, because the internet does not forget your lowest point. Anyone in power in fear of getting caught in public, for the world to see as just another corrupt, well fed monkey?
When my work introduced me to the guy that explains to us how the retirement fund works, I asked him if the Euro is safe (this was 2011-12), and what the safest investment is. He said "the safest investment is to buy a farm and grow your own food, because you can't eat money or gold.".
And in this Somalia 2.0 future of yours, how will the computers and networks be powered?
you don't think 200m ico's counts as marketing traction?
This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.
Predictable, but not necessarily inexcusable. What is gained and learned in attempting more complex smart contracts sooner rather than later when all the building blocks for absolutely secure smart contracts are built can certainly justify the approach.
I like your point about language complexity. Can you point to a language that would fit the simple and verified criteria? I don't really follow the subject, so it would be interesting reading.
You could take inspiration from a system like Dafny or F-* and write your contracts with the assistance of a type system and compiler that generated proofs that your contracts satisfied some postcondition given a precondition. People have already written moderately complicated applications like operating systems in these languages, so there's some evidence they could be applied to contracts on the blockchain.
