In almost all use cases, there are existing identity, reputation, and legal frameworks that a distributed ledger can depend on. Here's an article I wrote about how most of the time you're better off with a database instead of a blockchain: https://blog.fauna.com/distributed-ledger-without-the-blockc...
There are some cases where existing identity and legal frameworks can't be used, where proof-of-work has some interest. My other problem with proof-of-work is that it can't scale because it always demands that blockchains use more energy than the economic value they are protecting. Here is an analysis of how blockchains aren't immutable: https://www.coindesk.com/blockchain-immutability-myth/
More importantly, the argument doesn't apply to proof-of-stake blockchains, which I believe are the future. Unless a government is able to purchase a 51% stake in the currency, but that would require hundreds of billions for a currency as large as Bitcoin.
[1] https://www.google.com/search?q=12.50+%2F+%2810+minutes%29+*...
51% attacks normally require 51% stake. It's true that large stakeholders will occasionally have several winning block scores in a row, which lets them create a viable short fork, but it's not really a problem. Short forks just mean that users need to wait for several blocks if they want a high degree of certainty that a transaction is final.
51% attacks could also be more feasible if an attacker can manipulate entropy, but the usual safeguard is to derive entropy from verifier addresses, as NXT does, so that manipulating entropy will cost a verifier their block reward. Then require verifiers to have a certain minimum account age, high enough that grinding attacks become infeasible.
Certainly more complex, but with the right design PoS works fine while saving electricity, and the cost savings are passed on to all stakeholders.
The majority of the supply was produced rather trivially for a measurably inexpensive amount of captial cost to mint it prior to 2015.
One could surmise the reason crypto isn't banned yet is because nation states have the resources to mine majority stake easily due to the majority supply being created in a short time frame.
I'm not saying it's unrealistic, just that it would be more expensive today than what the article says.
[1] https://blockchain.info/charts/hash-rate?timespan=2years
A case study in censorship though the pools has proven this:
https://steemit.com/ethereum/@dhumphrey/f2pool-manipulates-u...
Unless a coordinated majority is censoring your transactions, you can't really be censored, your transactions will just be slightly delayed sometimes. Which is normally very harmless.
The only problem here was a poorly run ICO, where prices were dependent on the order of transactions. That wouldn't be the case with e.g. a reverse Dutch auction similar to the process for Treasury bills.
Assuming you are correct, here's something you dint consider - most of the PoS coins need a starting point - mainly the genesis block. These coins are acquired through ICO mechanism. Example NEO. While the current price is 122 USD @ 8 billion in marketcap. But, it started at 0.3 USD and raised USD 28 million. So, China need not buy now 4 billion of coins now, it could have spent 15-20 million to acquire more than 50% of the staking coins.
In other words, a distributed system is less cumbersome if it is centralized.
Blockchain is a very expensive technique, but it's the first attempt at developing document timestamping system (one that doesn't need trusted third party) that produced at least mildly robust protocol.
The internet had tremendous utility at 56k speeds. The blockchain so far is mostly just useful for propagating itself and propping up the value of cryptocoins. There are some exceptions, such as using the blockchain to notarize documents (although has any court actually accepted blockchain-notarized documents as having legal power?), but the author's criticisms are well-founded. Even Ethereum Smart Contracts aren't particularly useful because in order to affect anything not on the blockchain you need an oracle, which destroys the whole decentralized 'trustless' concept.
> They mention "immutability" being a problem - so much so that it somehow disallows typos or undos. That's just not true - you just represent the updates as changes in their own right
The author already covered this. You can't undo a transaction without the cooperation of the other party. Accidentally send 10BTC to someone when you meant to send 1BTC? You're entirely beholden to the whims of the recipient to decide whether to refund you. Nobody else can do it. Or perhaps more importantly, if someone steals money from you, it's impossible to recover (because you can be sure the thief isn't going to refund it).
If you're using the blockchain in a manner where you can trust the recipient to be on board with correcting any errors, what benefit are you getting from the blockchain?
> I just think blog posts like these aren't really making compelling points other than "the current technology today has many flaws", which I think is uninteresting to most.
The only two points tied to "current technology" in the article are complaints about the blockchain speed and the blockchain size. But it turns out the first problem is going to be solved by literally not using the blockchain for most stuff (which pretty much proves the article's point), and the second problem is still a legitimate problem. Even if you can mine without having the full blockchain, someone is going to need to have it in order to actually validate the whole thing periodically. If we get to the point where the blockchain is so large that only a few major players can afford to have the whole thing, then we've lost the 'trustless' aspect because now we have to trust those major players when they say the blockchain validates properly.
First of all, plenty of systems have the ability to roll back transactions. Exchanges can and have declared some transactions void if they were the result of market manipulation or extreme volatility, such as during the famous flash crash.
Second, with a blockchain you need the other party to sign the reverse transaction. Either you have to trust that party, or a central and neutral authority with some sort of main key, to produce the inverse transaction. Once you have this, you have introduced a ton of trust and/or centralization into the system, in which case you could have just used a regular SQL database anyways.
It's the kind of thing that I would put in a "false things programmers believe about transactions" article if I ever wrote one.
Due to late fees, overdrafts, interest, frauds, various legislation and protections, cooling off periods, time zones, comm lags, etc etc etc, it's dangerously false to believe that transactions work in some kind of immutable real world time stamped process.
I know these days there's a network of banks that do much faster transfers between them, but that's because they trust each other to reverse charges as needed.
Maybe stray gold or silver coins or similar. Those offer more privacy than BTC though and are also quite easy to safely store (safety deposit boxes are cheap compared to any meaningful valuables). Or you can just buy GLD on the stock market.
Cash, at least in the US, offers a lot more privacy than BTC does. It also has low, stable transaction fees related to its use and existence.
You know what other things people said weren't the future? Tons and tons of things that failed.
You have survivor bias; there are far more things people say will not be the future that then fails and everyone forgets about.
The Blockchain is an awesome technology for an incredibly niche market. So his article is right - in most cases, you probably don't need a blockchain.
Let's say you record voting based on SMS for American Idol show in MySQL database. Singer A got 1000 votes, singer B got 700 votes. But singer B is more viral and popular in social media. You think if singer B goes to the next level, it will increase the rating of the show much more compared to singer A does. So you decide to bump up the singer B's voting number to 1100.
Blockchain can prevent this malicious behaviour.
Paper ballots work fine and have amazingly low error rates, leave it be.
FYI, the voting in blockchain can be anonymised.
The issue I have with electronic voting of any kind is that it's a huge and valuable target, it's pretty much guaranteed that multiple hostile nation states will want to poke holes into these systems. Introducing crypto doesn't do squat to prevent all sorts of nasty problems, including information leaks and stolen private keys. Given what we know about how most people handle basic passwords, I think paper is probably the most secure form of voting we've ever seen.
The political voting is a complex beast so I am not going to comment on it yet. My main focus is for the voting process like American Idol, choosing moderators in forum.
When you think through this, every voting system has a weak link in terms of verifying who is a valid voter. So you must have a centralized authority here. Thus a blockchain is useless.
This is the hypothetical solution. Let's say there are 1000 voters. You premine 1000 coins then send it to each voter. Voter then can vote with 1 coin. So you can make sure the voting process is valid, and you can hide the sender in the smart contract. Of course, the technicality is not this simple. But you get the idea.
I'm not claiming any benefit related to government control, just that escrow would be unnecessary.
A centralized source will be held accountable to the legal demands, thus as trustworthy as the blockchain yet significantly more beneficial for all users in terms of speed, storage and utility.
Beyond that you can make something unique digitally and hash it and someone can "own" that digital thing, instead of money it can be items in a game or art or anything really. A musician can make a song for a single person and sign it into a blockchain and you can prove who it was for. Lots of neat applications that haven't been created yet just like the internet when it was new.
Heck, you don't really even need a database for this at all, come to think of it. Just have the QR code contain a signed copy of the part identifier. You can validate that the signature matches the manufacturer's public key and that will be just as good as asking the manufacturer if it's valid.
Also, now that I think about this, this whole scheme (including using a blockchain) has the fatal flaw wherein a knockoff can just copy the QR code from a valid part. There's nothing stopping anyone from reusing the QR codes, and the knockoff will appear just as legitimate as the original.
Given that a blockchain is just a distributed database with a distributed certification mechanism, you can generally immediately construct a couple of non-blockchain solutions by first removing distributed certification, then distribution of the database itself. You can then quickly see the eigenmerits of those kinds of distribution for the problem at hand. I have yet to see an example where they are positive.
So there are 3 actors in supply chain: manufacturers, retailers, and consumers. In your solution (centralized database and API), you rely on the goodwill of the manufacturers which is fine (I guess) in most cases. But retailers and consumers have good reason sometimes not to trust the manufacturers. Vice versa.
Okay, let's consider this case: the manufacturer produces milk packaged in a bottle. So they put QR code in the milk, and put some information in their database. Let's say they put the production date into this database.
QR code: Abbbccc Information: produced on January 5th 2018
They send the milk to the warehouse A. Warehouse A keeps the milk for a night before sending to the retailers. But alas, there is a storm preventing the warehouse sending the milk to the retailers. So 1 week later, it delivers the milk to the retailers. Warehouse A informs the manufacturer about the incident. But let's say this milk only has 10 days before it hits expiry date after the production. Manufacturer decides to lie to the retailers. They updates the database.
QR code: Abbbccc Information: produced on January 11th 2018
In blockchain, this corruption can be prevented.
Say the manufacturer instead just has an RSS feed on their site, where they publish that information (digitally signed, of course) as the milk is produced. The retailers just have to keep a local copy of that feed, and so they can detect any later tampering.
</sarcasm>
That said, this does bring to mind one genuinely useful aspect to the blockchain I forgot about, and that's the fact that Keybase uses the bitcoin blockchain (IIRC) to periodically record the Merkle tree roots that they use to verify their own information. The only reason to do this is as proof that they're not tampering with the Keybase history that they publish, and so fundamentally this is just the same thing as digital notarizing that I did mention before (except in this case it doesn't matter whether the courts recognize it as being valid). And you could still accomplish this without a blockchain simply by having a neutral third party agree to keep a record of the merkle tree roots, but this is one of the few cases where the 'trustless' aspect of the blockchain actually is useful.
Though of course even with a 'trustless' blockchain you still have to trust the chain itself. With Bitcoin, you can assume nobody's managed to execute a 51% attack against the chain (at least, for the time being; AIUI with the way things are going it looks like the Chinese government might be able to do it by exerting pressure on all the Chinese miners), but if you're running your own chain, how do you make mining the chain popular enough to prevent attacks?
In fact, to my mind, the only real benefit of Bitcoin at this point is the fact that it's so popular it's hard to attack (well, except by the Chinese government).
I'm not actually a Bitcoin/blockchain hater; I can't avoid having a soft spot for any tech that makes me feel like I'm living in a cyberpunk world :) What I dislike is the mania. Bitcoin is a cool experiment, not a production-ready solution to anything.
maintain a queue of.. failed modifications and retry them later when the API goes back up again.
neither would I have to
provide the software that does this to the client so the client doesn't have to do any work for it.
You're literally describing a benefit of blockchain. Its right under your nose.
Your blockchain client still has to have a queue of transactions to be submitted, as the Internet is not magically reliable.
You're literally describing a benefit of blockchain. Its right under your nose.
It is a benefit of the blockchain, in the same way that transporting people is a benefit of a dump truck. That doesn't mean it's appropriate for that job.
There are many, many tools for storing and pushing messages to remote servers. The blockchain clients can do it, but it's absurd to use them unless you need the rest of the blockchain stuff. Even an email server (MTA) would be a better option.
The same goes for quality data, mostly because even if the vendor provides it, basically any industry partner will absolutely insist on doing sample tests on the quality anyway. That also doesn't remove the factor where the quality results are cheated before being put on the blockchain.
A blockchain is not very useful when
A) all participants are trusted or
B) there is no incentive to cheat or
C) if there is incentive to cheat there are already countermeasures available that are more useful (ie, doing samples and having a contract that specifies damage payments in case quality does not match)
Second, you have yet to actually provide any motivation for end clients to spend money or hardware on a manufacturer's blockchain. Chances are the manufacturer would have to maintain all the miners, which is silly.
Third, the manufacturer in this case would have all of the signing keys, since they're the only ones that can make parts. This also damages the selling point of the blockchain.
So no, this does not work.
If you somehow managed to persuade an industry to get on board, for the most part, those with nothing to hide are the ones a decentralised quality database is the least useful for - anyone trying to hide anything (manufacturer / buyer) is going to avoid taking part or cut corners anyway.
bonus points if you can work out what it is.
One obvious use case is collectible items for games. People spend thousands on games like Hearthstone or Clash Royale. Imagine if the cards you collected in such a game were ERC20 tokens. Instead of all that value being locked up within Blizzard or Supercell's servers, you could freely trade or sell your in-game items. I think that would encourage players to spend even more money on these types of games, and could open up huge new marketplaces for digital goods.
There's also a lot of technical issues here. What happens if I sell a card while I'm in the middle of playing a game?
And of course the usability issues. What happens if I get hacked and someone steals all my cards? Blizzard / Supercell would have no way to make things right short of giving out free copies of cards to people (which would quickly become an avenue for fraudulently duplicating cards by having various accounts get "hacked"). And more generally, in order to participate, I need a private key that I keep secure. What happens when I lose that key, because I'm not a crypto nerd but am just an average computer user playing a game? Now I've lost access to everything I spent my hard-earned money on, and once again, Blizzard / Supercell would have no way to make things right (short of giving out free copies of cards, which leads to fraud, etc).
About the only benefit here is the ability for users to trade items without the involvement of the company in question, but there's very little benefit to the company to allow that, and it carries far too many serious issues.
The blockchain is a distributed public ledger, but everything in the actual game itself is controlled by the game developer's centralized servers.
The provenance of any token can be known just by looking in the ledger, and the game's developer could simply blacklist that token on their game's servers, rendering it useless.
The blockchain does next to nothing in this game token scenario. It's still mostly a centralized system.
> About the only benefit here is the ability for users to trade items without the involvement of the company in question, but there's very little benefit to the company to allow that, and it carries far too many serious issues.
Exactly. Although, given that you can't use the tokens when the game servers are down, being unable to trade them when servers are down is probably not a big loss.
I read the article as a criticism of the status quo, in which case the prospect of future potential would be irrelevant.
Absolutely this. As soon as I read the article I was reminded of those 1996 "this internet stuff is a fad" pieces.
It feels to me a bit like claiming in the 90's that the internet isn't the future because you can't download that much stuff at 56k speeds.
They mention "immutability" being a problem - so much so that it somehow disallows typos or undos. That's just not true - you just represent the updates as changes in their own right (which better reflects reality than literally altering history). There's nothing about "the blockchain" that can't record human error or corrections.
They go on to talk about how proof of stake doesn't solve all problems by mentioning, "The Bitcoin blockchain is currently 157GB in size, and that’s at a very low transaction speed. The idea of everyone mining on their phone is just laughable."
Once again, they are talking about current implementations - I don't see how this is inherently a restriction in the technology, and there are (reputable) companies working on this exact thing.
The amount of money I have in cryptocurrencies can basically be rounded to zero, so I don't have much skin in this game - I just think blog posts like these aren't really making compelling points other than "the current technology today has many flaws", which I think is uninteresting to most.