Even if the tech is "legit" it's encredibly inefficient. We're spewing off tons of CO2 just to verify the block chain, but we have plenty of technologies that can do the same with a minuscule amount of energy.
The problem is that they want a system that's trustless and that's simply not what most engineers care about. We want a system that's fast and efficient.
There are solutions to that though, like Proof of Stake. If distributed systems really cared about that, then that's exactly why they ought to be working on blockchains, to make them more efficient.
So, your argument is: "you say our thing sucks at X, but if you really think so, why aren't you trying to fix it?" Filling in the variables differently, we could construct an argument like "If civil engineers really cared about structural stability, then that's exactly why they ought to be working on my bridge made out of playing cards."
It's not their job to fix someone else's bad idea.
Cryptocurrencies aren't going away. Which means that if your primary motivation to not work on cryptocurrency is that it wastes energy, then there's a whole lot of room for you to be making it better, and that is a stupid motivation. I'm not saying that they are obligated to work on it because it wastes energy. But the comment I was responding to implied that distributed systems engineers didn't want to work on blockchains because they are wasteful - which is clearly illogical. That'd be like Elon Musk not working on electric cars because they're inefficient. Or Solar cells. Etc, etc..
No that's not illogical, Why would I work to bend something like block chain, that was designed to be inefficent, to my will when I can just start from scratch using projects that were designed to be efficient first? That's very logical, the kind of decision that an engineer that's getting paid the make the best distributed system for the least money would make.
It's not designed to be inefficient. It's designed to solve the distributed consensus problem in an adversarial environment. There are other now proposed mechanisms of doing that (e.g. PoS) that are quite efficient. Working on those would be extremely beneficial to the cause of environmental efficiency.
Evironmental efficiently solving a problem I don't have is still inefficient. I still can't think of a mojor user for proof of work in a destributed system. I have trouble thinking of a distributed system that someone would pay for to not be centrally trusted, usually by the benefactor of employment? We always hear what a great solution blockchain is. Even if that's true, I never hear the actual problem it solves. Sure, say distributed ledger, and proof of work but those are solutions of sorts.
Name a problem that would best be solved with blockchain.
- Assets move instantly, and settlement time is ~10 minutes (settlement can also be instant if the parties trust the other won’t “double spend”)
- The transfer mechanism is public infrastructure and is always improving — everyone has a shared incentive to make it better, similar to Internet protocols like email and http
- Assets and end-user data are privately controlled, and strong security for assets can be achieved by using multiple signing keys across several parties
- Policy rules about the movement of assets can be enforced programmatically — whether those are “terms and conditions” or regulatory requirements
- Assets are fungible and play nice together — e.g., you can use reward points to buy mobile minutes
- A single transaction can include multiple entities and assets, on both sides of the transaction — e.g., you could execute a merger of two companies in a single transaction, with the inputs to the transaction being all stockholders across all share classes for both companies, and the outputs being all the newco shares going to all the new stockholders (again, no escrow service needed)
- Every transaction is added to an immutable record which, while anonymous, can be used to construct a perfect audit trail of an asset’s movement when combined with the private data held by the entities using the system — this defends against fraud, and also gives issuers transparency into asset movements
It isn't intrinsically theft prone, the UI around using it is just not up to snuff yet. Credit cards, on the other hand, are intrinsically theft prone. They are a pull architecture. Every time you use your credit card, the store takes money from you. This is patently absurd, and the only reasonable definition of 'theft prone'. Bitcoin is a push architecture. You can never take my bitcoin, I can only send you bitcoin. Further, irreversibility is definitely what you want in the underlying protocol. It's fine if people want to implement escrowing and chargebacks via intermediaries on top of Bitcoin, and I would encourage that. But at a fundamental level, a payment system should be irreversible, immutable, uncensorable and push-based. Which is exactly what Bitcoin is.
That's not splitting hairs; that's literally the point of credit cards. It is entirely "push" from my perspective, modulo the minimum monthly payment and tolerance for paying interest and bad credit.
If I buy something with a credit card for $2k and have $2k in my bank account, the $2k is still there until I pay the credit card company. It could take years or be paid off immediately.
It is a pull. You bear the costs of fraud whether you notice them or not. The fact that the credit card company hides those costs from you doesn't change the fact that their architecture is broken, and that you are still paying for it by virtue of the fees they charge merchants, which create higher sticker prices for you. Costs like that don't simply disappear into the ether - you, the consumer, pays them.
Any time you require 1) a distributed database 2) in the face of adversarial participants, which truthfully, is less common than the blockchain obsessives would think.
A centralized organization (.com or .gov) that can achieve consensus amongst participants can do just fine with Postgres and a REST API.
Adversarial participants are common, but typically that's solved with a third-party overseer that administers the system. Finding use cases that demand decentralization are harder.
Bitcoin was created to remove central banks/govts from the money creation process, but in most cases, if you don't trust the central authority, you just don't participate. With cash, you can't easily get around dealing with the govt.
When cash was gold and/or silver the central authority might do some minting of coin but you did not need to trust them with a ledger or not to print huge amounts of paper currency. Gold and silver were currency for thousands of years. Soon all the people who lived under that system will be dead. It will be interesting what the system of global fiat will bring in the future.
No they're not. They're implemented in many altcoins. And to say that 'proposals' are not efficient because they haven't been implemented is both semantically wrong, and an incredibly stupid point even if it weren't.
But the entire point is that it wastes energy. That's why it works. It isn't like a car that can be made more efficient and therefore better. The central premise is that we're going to waste energy to do something that can be done in other ways without wasting energy.
The entire point is that it wastes something. Not specifically energy. The idea is that there is a sunk, unrecoverable cost associated with mining. That cost may be able to take other forms, though. In the case of proof-of-stake, that cost is the time-value of money.
In part because this is trodden ground for distributed systems engineers and we know that, on balance, the correct solutions all involve massive centralization.
You don't want that. So we're at a bit of an impasse.
Distributed systems these days mostly argue that you do your trusting up front, outside of the protocol itself. You then validate that the actors share the secrets you all agreed upon, and then optimize the agreement process. Only the most robust systems actually consider "active" dissent; most distributed systems engineers consider this a special case that is most often focused on the idea of "incorrectness" as opposed to "maliciousness."
You can see elements of these assumptions in more modern data structures used for eventual consistency, like CRDTs. CRDTs are amazing and fast and often abstract-able to a trivial programming model. Anyone can use them, but they have to be monotonic, so we can't ever forget bad input, just try and cancel it out.
In some cases you can forget bad input, though, can't you? It's a rather wasteful example, but if (like you say, having established trust beforehand) every element of a grow-only set is a signed message, you can reject any messages that don't validate against their signature when merging. On one hand, this breaks idempotence. On the other, if we regard that set as a subset of the set of validly signed messages, it could not have been there in the first place, so to speak, so I wouldn't immediately think it breaks any guarantees. As far as I can tell, any properly functioning machine will only ever see correct state this way, unless it receives some state and doesn't merge it with anything, for example when initially starting to participate. However, that's easily fixed by always having some state, for example by starting with the empty set in this case.
> you can reject any messages that don't validate against their signature when merging.
That's not really what I meant by "bad". I meant bad as in intent, not structural and immediately verifiable message integrity.
If all entities in the coalescing set can independently verify that a message does not meet its signature requirements, it will be rejected and idempotence is maintained.
If ONE member is somehow deceived about key validity it'll propagate the message into every other member's state, eventually.
Most of the bitcoin researchers have thoroughly convinced themselves that Proof of Stake is not achievable with acceptable levels of security, and for good reason. The reason you don't see more active research on Proof-of-Stake is that it is thought to only lead to dead ends.
Ethereum has not shown a particularly strong track record when it comes to security, so I think the comment stands until they address that or get replaced by the next hotness.
I think that statement is a little disingenuous. There haven't been any attacks that target Etherium proper, only bugs in smart contracts riding on top of Eth.
> I think that statement is a little disingenuous. There haven't been any attacks that target Etherium proper, only bugs in smart contracts riding on top of Eth.
This is a bit No True Scotsman. It's like "secured by math!" about Bitcoin - the ecosystem is rife with fraud and error.
So too with Ethereum. Given that smart contract functionality is literally Ethereum's unique selling point, you can't claim that is somehow not something that can be discussed as a problem with Ethereum. They broke the immutability guarantee for one bad smart contract, after all.
You really can't say "Ethereum is completely secure!! Except for everything that people actually use it for" without being more than a little disingenuous yourself.
It is, thus far, completely secure. The fact that SQL injection bugs exist does not negate the security of HTTP. The fact that stack overflow bugs exist does not make x86 insecure. The primitives you are provided are secure - how you use them may not be.
Now you may legitimately argue that Ethereum is poorly designed to encourage secure contract authorship. And I would agree with you in many respects. But that is a distinct concern from the security of Ethereum itself. Conflating the two is at best confusing and at worst maliciously spurious.
I don't mean that I have concerns about Ethereum itself, just the fact that it's currently too easy to write insecure contracts. And there has been some low-hanging fruit in remedying that, such as the whole "functions are public unless otherwise specified" thing.
Again, the bug was in the application layer, not the protocol layer. That's like saying that HTTPS is broken because you can do SQLi against someone's poorly coded website.
I believe it's not core Ethereum that has issues, it's buggy smart contracts. They don't make it particularly difficult to write insecure contracts, though.
Ethereum actually has a better security track record than Bitcoin does [1]. It's the contracts on top of Ethereum that are the problem. Calling those incidents Ethereum security problems is like calling a Windows 0day an Intel security problem.
That's a bit of a mistake. It doesn't rely on inefficiency it relies on economic costs. At the moment, hashing is a form of economic sunk cost. If you invest in hashpower, you can't split it without reducing your probability of success. It's an unforgable economic burden. Proof of stake architectures attempt to do the same thing with the currency of the network itself. There are lots of arguments about whether or not this is truly secure - but anyone on here telling you they know it's not is pretty much an idiot. There are tons of proof of stake coins operating successfully right now. There are no known attacks on these coins that allow you to do anything untoward (if there were, they'd be exploited on one of the many existing PoS coins).
No serious blockchain relies on proof-of-work. Bitcoin (being forked now) doesn't and ethereum (already forked twice) definitely doesn't.
Blockchains are a social construct and what ultimately protects them are the participants. Exactly like actual currencies they are subject to market forces; people either believe in and want the currency or they don't. It's this confidence that gives the currency strength.
More simply:
"On medium to long time scales, humans are quite good at consensus. Even if an adversary had access to unlimited hashing power, and came out with a 51% attack of any major blockchain that reverted even the last month of history, convincing the community that this chain is legitimate is much harder than just outrunning the main chain’s hashpower. They would need to subvert block explorers, every trusted member in the community, the New York Times, archive.org, and many other sources on the internet; all in all, convincing the world that the new attack chain is the one that came first in the information technology-dense 21st century is about as hard as convincing the world that the US moon landings never happened. These social considerations are what ultimately protect any blockchain in the long term, regardless of whether or not the blockchain’s community admits it (note that Bitcoin Core does admit this primacy of the social layer)." [1]
The subtlety here is making the distinction between confidence and resistance to attack. They're not the same thing at all. And what's interesting here is that, going off the model of real currencies, one could assume market forces will prevail here. Developed nations let their currencies float precisely because on the whole they're confident that the market will ultimately punish any malicious attacker who attempts to destroy the currency by selling large amounts of it.
I think that's exactly what it means. If you want to help the environment right now, what field should you be in? Energy generation, storage, or consumption.
LiteCoin's proof of work is memory hard so it's harder to create an asic.
A hard proof of work algorithm is required for decentralized coin chains to work. Otherwise it would be easy to create a denial of service attack by rogue agents filling up your blockchain with worthless blocks.
It's worth noting that the qualification should be "easier." But the POW is only one side of the DoS problem bitcoin's model can be forced to experience.
By carefully attacking the network links between miners, someone can significantly extend the amount of time that an attack can take place in. These attacks are expensive, but orthogonal to any PoW algorithm.
Then the problem transforms into: "can I trigger enough small pluralities of miners to split and form opposing but equally long viewpoints?" The only resolution to such a scenairo is to discard most of the divergent blockchains arbitrarily by human consensus.
Which is sort of unvalidated and points to one or two actors in the space suggesting that they want to move to non-fossil fuels and one that miiiiight be.
Not the parent commentor, but this is certainly true to some degree. To what extent is very hard to say, but China has built several large hydroelectric projects in remote areas where electricity is very inexpensive. Many miners have taken advantage of this.
Of course, there is also cheap coal power in China, so the environmental impact may be very significant.
Going forward, I anticipate the rise of solar mining in some favorable areas. Possibly geothermal as well. Since Bitcoin mining can be done anywhere with decent internet access, it seems natural that it should gravitate toward renewables over time. Fossil fuels continue to get more expensive, while renewables get cheaper. Of course, building e.g. solar panels isn't without environmental impact, either.
The problem is that they want a system that's trustless and that's simply not what most engineers care about. We want a system that's fast and efficient.