That's why a lot of the more technical people really dislike ethereum. It's not one or two problems. The entire system all the way through want made with the mentality of compromising stability in favor of getting features sooner.
Tech folk should be excited about blockchain but the hysteria over exchanges right now is off-putting once you understand how deeply rigged the markets are. My next venture will be blockchain-based but I have a few years before I'm free to pursue that. I'd rather see the fundamentals of the tech improved in the meantime rather than have it prematurely hyped and have the bubble pop as I seek to raise funding...
I imagine there are many others who are in the position of wanting to build apps based on blockchain tech but who are not yet able. For us, slow and steady wins the race.
Saying "they're missing the mark on marketing" about the second-largest crypto by market-cap, and surely top-5 in terms of ongoing development is at the very least a bit ironic. They exactly did NOT miss the mark on marketing. There are other technically superior products that don't get nearly as much funding, public attention, development resources etc.
As an entrepreneur, though, the market makes the final decision on whether you make money, whether it's "right" or "wrong." If you're "right" when the market is "wrong" as an entrepreneur, you lose—you're "ahead of your time" or some other pleasantry meaning "you weren't giving the market what it wanted."
If you want to sell something to the market, then if the market is irrationally exuberant, you have to be irrationally exuberant too.
Secondly, if the market is wrong and you dance to that tune, eventually when reality catches up the market will realise it’s mistake. Trust me, the market can sell out of your company faster than you can pivot your entire business model.
But sure, it is possible to make money following trends. But it’s not the only way. It’s not an immutable law of capitalism, and there’s plenty of money to be made providing actual, sustainable value.
Yes, but it is risky. If you don't follow trends/buzzwords you have two threats: 1) You bet that many people (the market) are wrong and you are right. Possible, but unlikely. 2) You bet that after these many people (the market) come to senses and realize that they were wrong (remember: nobody likes to admit that they were wrong), they acknowledge that you are right and buy your product. As the funny saying goes: "the market can stay irrational longer than you can stay solvent".
But in a way, being a market leader gives a lot of adoption and a big ecosystem of tools produced by other developers - which in this space means a lot, because a blockchain's usability increases with adoption, even somewhat exponentially.
The approach that a couple of currencies have taken (including the one I lead) is to make a separate blockchain entirely dedicated to their app. And I think that's a far better choice than anything out there, though it comes with the glaring downside of needing to build and run your own blockchain, which is a very difficult thing to do.
Most of the apps we are seeing today don't make any sense anyway. Very much smacks of the dotcom bubble, where people who suspected that the Internet would change the world were absolutely correct, but then the companies and ideas they put their money behind were missing the mark by miles.
We've got the same issue today. Most successful ICOs are going to fail very hard, due to known impossibilities, known poor uses of the technology, etc. It's just a general fever that has a lot of new entrants in the space innovating in the wrong direction.
It will get better. Dapp platforms will appear that make sense, have good foundations, and are easy to setup and use. But it's not around the corner, it's probably 3-5 years away.
This is the crux of the problem. The cryptocurrencies with the highest valuations right now are ones with serious technical and social flaws--people are investing in cryptocurrencies based on hype rather than merit.
Ethereum is the most egregious example: the idea that a JavaScript-like language is what you'd want to write your security-intensive code in is mind-boggling-ly stupid, and after the community showed themselves to be willing to perform a 51% attack on their own blockchain to fix a problem with the DAO, it's not even decentralized any more. So technically you have all the downsides of writing secure software in JavaScript, and socially you have all the problems of centralization AND all the problems of decentralization. The security flaw this thread is about would be a critical vulnerability to any competent security developer, but it's really minor compared to the more fundamental flaws.
But even in competently-developed cryptocurrencies, the problems are still there because people don't understand or value decentralization, which is literally the entire reason Blockchain is worthwhile. The number of people who buy cryptocurrencies and then leave their coins sitting on an exchange is incredible. You're literally donating money to the world's biggest bug bounties when you do that.
The only reason you think the cash in your portemonai is worth something is that everybody else things the same. As soon as everybody stops believing it, the paper in your wallet can still be used to make fire. Same goes for authorities. Judges, policemen, presidents are what they are because everybody believes it. We have already an informal consensus of who is a policeman and who is not. Most of the time it resolves to whether somebody wears the uniform. Crypto tech promises to make this verifiably. No need for uniforms.
Huh? No. Distributed consensus was formalized in 1978 by Leslie Lamport and the first version of Paxos was introduced in 1989. If you're okay with centralization, Paxos or it's successor, Raft, are much faster and more scalable algorithms than blockchain, and have a wide variety of mature implementations.
This cannot be stressed enough. But, I disagree that building your own blockchain is the answer in comparison to using EVM. The amount of blockchains and services people might end up needing will be huge. So, it seems the correct usage for blockchain is still far out.
Bitcoin could easily be extended to have an EVM
are you talking about Script, or some other approach I don’t know about? I think it’s pretty optimistic to put the word “easily” anywhere near a proposed use of Script.
lots of resources here, also recommend mentioning the discord here
This is where the primary technical discussion happens, and where all the devs hang out. Our company is here, mobile wallets are our first product :)
https://github.com/CityOfZion/OzoneWalletIOS https://github.com/CityOfZion/neo-swift
The truth is that the EVM is perfectly secure and the problems with Solidity are due to the fact that any new smart contract development environment was bound to have problems at the initial stages.
Solidity is being rapidly improved and there are several other programming languages under development for the EVM as well.
As for market significance, Ethereum is the only smart contract platform that's relevant.
There are now over a million MetaMask installations that can interact with any Ethereum Dapp, and millions of MEW wallets that can hold ERC20 tokens.
Ethereum-based tokens saw their share of the total token market cap grow from 73% to 92% from July 2017 to January 2018. The platform has 30X more developers working on it than the next most active one.
That means that almost all of the decentralized exchanges and other value-adding applications are compatible with the ERC20 standard, creating a positive feedback loop of encouraging new projects to build on Ethereum.
Ethereum is more likely than not going to be the platform for smart contract development.
Qtum sounds like the thing you could be looking for. To TL;DR; it, Qtum is a smart contract platform on an independent blockchain that supports PoS (not DPoS, true PoS) and designed to support multiple smart contract VMs. Right now it only supports the EVM and thus can only run Solidity smart contracts, but later this year we'll release a new VM based on the x86 architecture so that it will be possible to use mainstream languages like C++, Rust, Go, etc...
Anyway, ending the whole description bit, we built it because of similar thoughts as you. Tired of seeing the only suitable smart contract platform (Ethereum) be treated like some philosophical research project, rather than a platform that businesses and people stake hundreds of millions of dollars on. Everything we design is intended to be practical to not just use, but also implement. We pride ourselves in never missing any deadlines we set for ourselves, and in never having some pipe dream project that won't be ready to use for 5 years.
* This is a "browser bypass of SOP" issue. All your "unauthenticated" local services should be vulnerable.
* A good part of Geth's usage is for servers that do not browse the internet.
* You usually do not handle accounts inside of a geth node, instead you open the node's API via RPC and have another tool that sends already-signed transactions to it. That means that this attack would probably not yield much if not allow someone to use the geth node as a public node to query public information.
* If you do decide to handle accounts in there, you would probably (1) not open the node with RPC and (2) have the accounts be encrypted. See Ethereum's documentation[1] :
> It supports interactive mode, when you are prompted for password as well as non-interactive mode where passwords are supplied via a given password file. Non-interactive mode is only meant for scripted use on test networks or known safe environments.
[1]: https://github.com/ethereum/go-ethereum/wiki/Managing-your-a...
How could anyone not consider this a vulnerability when it has an actual CVE assigned to it?
The discussion in the github issue also shows they took it pretty seriously: https://github.com/transmission/transmission/pull/468
On a single-user machine, an attack scenario where authenticating localhost would actually do some good would be some other account existing that's easier to break into than the account of the user actually doing stuff. But if no other login exists?
Modern desktops do not run at runlevel 1. All sorts of services and daemons run under different users, so having an unauthenticated service listening on localhost is less secure even on a desktop machine. If you have network services running on a desktop machine (common) then a simple RCE in an unprivileged user (with respect to the human user) can result in wallet compromise. If the API was authenticated that would not be possible.
Unix DAC protects users from one another, so any service which exposes personal information outside of the currently running user has objectively inferior security to a security model invented in the 1960s.
This is ludicrous. If a torrent client considers this class of bug to be a vulnerability[1], I don't see why folks who are trying to revolutionise money (something that is far more important than a few small RCEs) don't. While it is true you need to run it with the --rpc option, I'm confused why the RPC is unauthenticated by default, and whether there is any front-end that will start up the RPC server in the background (similar to electrum).
[1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5702