Refreshing to see a critique talking alternatives instead of another fanboy post on Bitcoin's blockchain. Monoculture is a good word for it. Almost all the research and attention is going in one direction when there are many valid directions worth exploring with fewer issues than Bitcoin. Some leverage proven approaches in finance, databases, or transaction processing. Just need extensions, more analysis, open implementations, etc.
So, I look forward to more articles like this to draw attention to solutions other than Bitcoin architecture. Another thing I look forward to are links to interesting alternatives like SCP and Interledger in this. I haven't reviewed them yet but brief descriptions seemed more exciting than "Cut-and-Pasted-Coin launched yesterday while promising to change the world."
Appreciate the links. Those are interesting ideas on reducing the load and increasing the speed. NatanealL's idea is closer to how I'm looking at it because I'm starting with our current model and trying to improve its deficiencies. Banks already manage their own transactions and records while interbank operations deal in huge chunks. Prevents need of global verification of individual transactions.
Plus, knocking out the miners and leveraging stored value in an existing currency can simplify things by removing some obstacles they discuss. Bitcoin's problem is a lot harder than the general problem of decentralized payments and contracts on cash-backed currency. I prefer to stick to the latter as it solves todays problems pretty well.
If there's no work - it's not a blockchain. Distributed ledgers are a completely parrallel movement that was taken up by those who wanted to leverage the marketing momentum of blockchain, for their own database projects. Which is fine, but shouldn't get confused with blockchain innovations.
There can be proof-of-stake blockchains, proof-of-use, proof-of-minimum-aged-time, etc. etc. The blockchain is just a chain of blocks, there are innumerable ways to protect it, verify it, and distribute the data.
I think the core value of a blockchain (as opposed to any general database) is that the most recent blocks contain a hash of the state of the system up to that point. This provides a tamper-resistant historical record of what's occurred previously.
I think your second point is what some of the critics of the bitcoin obsession are talking about. Not every blockchain needs to be as attack-resistant as the bitcoin network. Many of the speculative blockchain uses like for the Internet of Things could benefit from a history of all transactions but don't depend on it. Proof-of-stake might work fine for many cases.
What you are describing has been a core of any ledger/immutable database. It isn't new and in fact has been around for ages. You don't really think a bank keeps all you money in a sacred database cell do you?
Plenty of banks use pretty horrifying technology. Append-only databases have been a cool research project for ages but I've never seen one in production.
They're more likely to use mainframe database systems with the verification done in apps that interface with it or do batch runs on it. The mainframes and databases themselves cover the integrity and availability portions. So, it's a ledger in practice but not directly stored as one.
Matter of fact, storing it as one is incredibly wasteful. Banking systems have shown it's not necessary. Just need the transactions, timing, sources, and verification of them.
Are any of those dividend-paying companies? At the risk of no true scotsmanning, I wouldn't count it as "production" if the company isn't making money off it yet.
Or a series of files with numbers that go up and a data structure tracking their dependencies. Git and others might use Merkle Trees but they're not even necessary. Good, but not necessary. Lot of ways to represent these basic concepts with so many tradeoffs.
That's why it's exciting when people break away from the crowd dictating specific approaches and start asking themselves questions about alternative techniques. :)
That problem was solved back when we started putting money into banks and using it with computerized transactions. Variations on that model with nonprofits and distributed transactions could go far as alternative go current system.
Yes it's parallel but you got it backward. The use of distributed transactions, fault-tolerance, etc predates Bitcoin by over a decade. Bitcoin built on it and proof-of-work. As usual, people started re-discovering stuff they ignored in the process.
It took me a while to understand why Certificate Transparency is sound without requiring proof-of-work, and Bitcoin is not, but the answer turns out to be fairly simple: you can merge two CT log entries without conflicts, but you can't merge two Bitcoin transactions. If I want to log "Certificate A exists for bitcoin.org" and you want to log "Certificate B exists for mtgox.com", both of our data items are valid on their own (and can be independently verified, just by checking the signature on the cert) and the ordering doesn't matter. So as soon as a write goes to some log server, as long as I trust the log server to propagate writes via the gossip protocol, I'm done; I don't need to care about merges or retries. (Also, it's possible for the log server to send me a signed promise to propagate writes, that I can later use to prove its misbehavior if that entry never shows up.)
On the other hand, if I have a transaction "Transfer 1 BTC to bitcoin.org" and you have a transaction "Transfer 1 BTC to mtgox.com", they don't necessarily commute or merge because of the double-spend problem: they might both be trying to spend the same 1 BTC.
There are a number of nifty decentralized systems you can build that don't have to think about double-spend problem, where all transactions commute/merge. Associating names with public keys seems to be one of them, as long as you allow a name to be validly bound to multiple keys. (A Keybase-style binding of external service usernames to public keys would permit this, since you simply have multiple valid Keybase proofs; the external usernames are arbitrated by the various centralized services. A Namecoin-style approach doesn't, since names are first-come-first-serve, and you don't want multiple people to be served the same name.)
There appear to be ways to make a money-transfer system avoid the double-spend problem: as I understand Stellar, it simply just makes the spending account legitimately owe both people money (and puts limits on how much each link can transfer at a time, so that the money is actually recoverable). But for non-money-transfer systems, if you can arrange your problem statement such that double-spending isn't a concern in the first place, you can use regular Merkle trees and avoid the entire proof-of-work overhead.
Roughly half of the author's criticisms of the bitcoin blockchain are just growing pains, which will solve themselves with time. The other half are just feature requests that are outside of the blockchain's scope. Blockchains are distributed consensus networks, not databases. It's like asking MySQL to fix email spam.
At least now I have something resembling an understanding of how this is being applied. The concept always seemed a bit odd when I'd hear how banking establishments planned to use bitcoin for contract transactions, etc, without bitcoin being the currency of the transaction.
Such a bad implementation of a potentially good idea.
Bitcoin is one protocol that establishes trust between two parties for an arms length transaction. That it uses cryptographic hashing is an implementation detail to the same degree that pieces of paper are an implementation detail of Wells Fargo money orders. What matters is that one person can reliably pay another person. The fact that people speculate on Bitcoin and not on Wells Fargo money orders should not cloud our thinking.
The Bitcoin protocol strives for absolute consistency to mitigate risk. Other cryptographic hash based protocols that are described as "blockchains" may trade the overhead of absolute consistency for speed and lower computational overhead, e.g. Ripple [1] uses consensus between `n - c*n` nodes as the basis of trust along with transaction costs to mitigate the odds of Byzantine failure that would result in double spend; in exchange transactions execute more rapidly and with less computational overhead. Again, there's nothing magical about the implementation details. What matters is reliable trusted transactions of value. Bitcoin transfers can happen on the order of minutes, Ripple transactions can happen on the order of seconds.
What technologies that are described as "blockchains" tend to provide is low transaction fees. The time and expense of moving value via blockchain from Berlin to Cartagena is low compared to wire transfer independent of the blockchain's provenance...provided of course that the end units of the exchange are suitable to all parties. There's nothing magical beyond it being easier than using goats as the medium of exchange.
People seem to vastly over-estimate the time and expense of moving money internationally. It is not difficult, nor expensive at the moment. Bitcoin has very poor liquidity and enormous volatility compared to regular currencies at scale.
Volatility doesn't matter much if Bitcoin is just a medium for transferring value within a transaction in normal business circumstances, i.e. slight fluctuations in exchange rates over the course of an hour can be built into the offer. Forex style arbitrage and speculative investments are of course another matter...one in which Bitcoin is no different from other currencies.
The liquidity constraints of Bitcoin may ultimately limit its general adoption and perhaps encourages speculation over use. And is why, despite my lack of clarity, I did not intend to suggest that Bitcoin was better than Wells Fargo money orders for moving money internationally. That doesn't mean that blockchains may not prove to be significantly better.
However it's a classic disruptive technology scenario. Bitcoin is weaker than other currencies in almost every way, but it has its few very special advantages.
For now the only users are people for whom those advantages are paramount. That small group of dedicated users will use it dedicatedly and slowly the ecosystem builds up around it until other limitations are mitigated.
At that point we'll need to reassess its competitiveness.
So, a blockchain is just a special kind of distributed ledger; and a ledger is just a particular thing to store in a distributed database. What makes a blockchain special (and thus, I think, what informs the common usage more than any technical definition involving proofs of work) is basically what it accomplishes, that a regular distributed database cannot: a blockchain allows N mutually-untrustworthy parties—that is, people who would pick one-anothers' pockets if they could—to co-author a history they're all happy with, without having to put their trust in any particular party (who, again, might want to pick everyone's pockets), but instead only in the system as a whole.
My favorite comparison is to leaderboard ranking in competitive games (let's use Starcraft 2 as an example.) This is another place where everyone would love to cheat if they could.
Let's say you set up a blockchain where each "transaction" contained someone's SCII 1v1 gameplay-record from their perspective (i.e. their own input events, and the received network movement- and action-events from their opponent) for a ladder match they played. You'd get two "transactions" in a pair for each match—each submitted by one player—and each one would would move the players' ladder rankings and leaderboard positions around (though in an idempotent way, if both records happen to be valid.)
In this model, instead of having to have an authoritative "ladder server" that simulates all the game's physics for the players, or building any sort of anti-cheating tech into the game-client, each player would just be part of the ladder blockchain and therefore would "audit" each entered game-record after the fact, by running the game's physics engine against the gameplay-records to determine their validity, and translating the valid records into changes in the ladder-ledger.
Every player that bothers to run the ladder-chain daemon (which might-as-well just be embedded into the game-client as a nice'd background process) would be auditing every other player's game-record for physics discrepancies. Records from matches where either player was using a hacked game-client would simply be dropped from history rather than affecting the ladder (or could be encoded as a forfeit for the hacker.)
The game's manufacturer could have server-nodes of their own, purely for auditing—but they likely wouldn't need to. In fact, there wouldn't even need to be a game company; the game could be completely abandonware with no server infrastructure, yet the ladder and leaderboard system would continue to function indefinitely.
The properties that let you do this are what make a blockchain a blockchain. The other properties are implementation details.
Article seems to quickly call "Lightning Network" a "sidechain". Not only is this wrong, it's similar to calling "zero-confirmation Bitcoin transactions" a "sidechain". It's not anything like a sidechain. Examine the evidence yourself,
Lightning Network and Bitcoin payment channels are more like restrictions around the permissible possible undefined behavior of zero-confirmation transactions (which otherwise have more broadly undefined behavior), which are inherently unconfirmed in the Bitcoin system. By using an initial committed transaction, rules around the behavior of zero-conf transactions spending the UTXOs can be locked down, while still using Bitcoin transactions, not a separate consensus system and not a sidechain.
Yes, we're moving away from "PoS" from the time being, because our clients are more interested in posting collateral external to the blockchain. That said, the original security properties still hold. It's the combination of three things that create security on a non-PoW blockchain, for Tendermint.
* Validators have posted collateral (either on chain or off chain) that is not immediately transferrable, so there is something at stake.
* The BFT consensus algorithm ensures that at least +1/3 of validators must deviate from the protocol to attack the network.
* If there is a fork, then we can find out who had caused the fork. The validator-set is held accountable.
That hasn't changed. What has changed is our client base. We don't want to launch a cryptocurrency ourselves because as US/Canadian residents, that's a legal gray area. On the other hand, fin-tech clients and banks are interested in utilizing this technology for creating a distributed multi-write database. Thus the change in direction.
That said, we're very much interested in support the original PoS design. Other designs as well. For example, we're building out an experimental governance app that allows for arbitrary proposals. Perhaps we can use that to empower users or designated administrator groups to decide on updates to the validator set.
There are many ways to update the validator-set, PoS just being one of them. We will build out our platform to accommodate a wide variety of strategies for managing the validator set. For all strategies, they will make use of our robust BFT consensus algo.
Finally, there are sound technical reasons why a BFT ledger should utilize a hash-chain of blocks (list of txs). It is both a speed optimization (validators only need to sign block hashes, not each tx) as well as a security requirement. To expound on the latter, note that the original PBFT implementation does not provide any guarantees when more than 1/3 are Byzantine (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121...). But the hash-chain ensures fork consistency. So there you have it, a chain of blocks of transactions is fundamentally important for non-PoW ledgers. That's why we use the term "blockchains".
> or some transactions could be moved to “sidechains” as proposed in systems like the Bitcoin Lightning Network. But the Lightning Network is useful only for a ledger that is denominated in Bitcoin, and we still have to deal with the “central” Bitcoin blockchain, whose size is likely to continue to increase despite the addition of various “sidechain” mechanisms.
This is incorrect for multiple reasons.
> "Takes over 10 minutes to “commit” a transaction"
Incorrect. Average wait time would be less than 5 minutes.
> "Turning your Bitcoins into cold hard cash denominated in the currency of your choice is perhaps the cryptocurrency’s biggest problem"
It is author's world view based on pre-bitcoin times that cold hard cash is better. It can be said that turning cash to bitcoins is fiat's biggest problem.
>"moving money between ledgers actually involves integrating with those ugly legacy systems"
Assets on different blockchains can be swapped using various methods and does not need third parties.
> "there are far more efficient distributed consensus algorithms than this which don’t involve a proof of work."
Author gives the example of Interledger and SCP. Without proof-of-work origin of money will always be controversial. Both Ripple and SCP create money out of thin air.
>a very cool feature I will acknowledge exists and give a quick hat tip to Ethereum
There is NOTHING that ethereum can do that you can't do with bitcoin.
> Bitcoin-NG (paper), a protocol that inverts the ordering of Bitcoin consensus: a miner is first elected leader by winning the proof-of-work “lottery” by mining a “key block”, and then once elected leader becomes a transaction broker who can mint “micro-blocks” via digital signature until the next leader is elected.
I did not read last 3 paras. The author is damn right that Blockchains are world's shittiest databases and should not be used so.
In my personal understanding of what blockchain is, the author didn't mention it as a DMMS(Dynamic membership multiparty signature). This has been explained in the sidechains whitepaper, which most people do not read due to another myth that the employees of a private company 'blockstream' are majority of Bitcoin Core devs. Anyone trying to understand the blockchain should read the introduction of that paper. https://www.blockstream.com/sidechains.pdf
> Both Ripple and SCP create money out of thin air.
So does fiat, and fiat works. It may not work well all the time for 100% of use cases, but in general it works well.
As long as the mechanisms by which money is created out of thin air are well-understood by the people receiving this money (which they are for fiat) and the recipients give informed consent to that (which they... sorta do for fiat), this doesn't seem like a negative.
Fiat money works because governments pay for services in it, and demand taxes in it.
If you are not a government, fiat money does not work for you.*
* Quasi-government entities have a long history of issuing currency like this - company scrip was one such practice, but its important to note that this is a situation of a company becoming more government-like.
I'm a little confused, I think I paid for groceries last night in fiat currency and I certainly got goods in exchange for them, and I don't believe the grocery store was run by the government. Can you clarify what you mean by "does not work for you"? I suspect we mean different things by the phrase.
Sure, but a) I have no interest in issuing Bitcoin or any other currency, just using it as long as it works, and b) if I were to issue an altcoin, I would be creating money out of thin air!
> Incorrect. Average wait time would be less than 5 minutes.
Average wait time for a block is around 10 minutes. You may be thinking of it in terms of buses, where if there is a bus every 10th minute, you'd expect a 5 minute average wait. But blocks are mined practically independently, you could get two in a minute, or none in an hour. Turns out, no matter when you start waiting for a block, the average waiting time will be 10 minutes.
Interesting. Roughly 3,682,674 minutes have passed since its inception so expected blocks would be 368,267 whereas it is 391,933. Thus average should be less than 5. I guess due to low frequency of transactions the median is not the same as average.
'Do with' not 'do in'. For example, there could be an ether-tcp that transports data using unused header bytes. Now factually you don't send data 'in' TCP header so TCP-ether might seem better, but actually you can send data 'with' TCP and thus TCP-ether is redundant.
Think of any Ethereum usecase and you can do it with bitcoin.
Voice can be transmitted as packets using IP, but is VOIP an extension of IP or core use of it? Well, I guess we can call it either, because the end result is similar (but the side-effects are not).
†Note to “that guy” on Hacker News: yes, there were cryptocurrencies before
Bitcoin. I’m aware. You don’t need to educate me on them. But they don’t count,
sorry.
Btw, did you know that... in addition to cryptocurrencies... there were distributed, resilient database and transaction processing designs without Bitcoin's biggest problems (esp scalability & commit time)? And that people ignored them until a large gold rush appeared in 2008 using a clever, but inefficient, version of the ideas? And it took many years for people to rediscover some of the old work and start making wiser investments of developer time?
Can't do that every Bitcoin post on HN as too little time. Instead, I included some of the terms to Google in that and other comments here. Googling such things, especially with "pdf," is how I found the work. Following the references and related work sections helps, too.
Doing their homework for them just ain't productive. Not people riding a fad that is.
Note: A quick Google in response to one comment here led me to two, new papers with one having pretty awesome properties. Just goes to show how easy it is.
Most of these companies never cared about sharing their financial data with their competitors prior to 2008. Why they changed their mind here is beyond me, but that's the reason these systems weren't implemented prior. Transparency, thus far, has always been a bug and not a feature.
Companies? Most of work in distributed and e-commerce schemes was academia with them publishing it from journals to stories on tech and financial news. Some companies published work and design descriptioms too. I've been collecting and reading such stuff since the 90's.
The only thing new IIRC was making old things use proof-of-work and (global?) broadcast. Which also caused its problems. So, no, the stuff wasn't obscure, locked away... anything. Just ignored outside of transaction, database, security, and accounting subfields. The few doing it made slow but steady gains on technologies.
And thanks to Bitcoin, they might get some mainstream attention and more R&D.
So, I look forward to more articles like this to draw attention to solutions other than Bitcoin architecture. Another thing I look forward to are links to interesting alternatives like SCP and Interledger in this. I haven't reviewed them yet but brief descriptions seemed more exciting than "Cut-and-Pasted-Coin launched yesterday while promising to change the world."