Maybe Blockchain Really Does Have Magical Powers | Hacker News Reader

Maybe Blockchain Really Does Have Magical Powers

bloomberg.com

176 pointselaineo98 comments

I'm all for deflating blockchain hype, but I found the overall tone of the article pretty disagreeable, and more importantly, wholly missing the point.

"In other words, the only thing previously stopping the standardization of reconciliation processes was the unwillingness of financial institutions to collaborate."

No, actually, the one thing the blockchain provides, which was literally unsolved before pre-Nakamoto, was a working implementation of "trustless" consensus. Turns out fraud prevention is kind of a big deal shuffling around billions or trillions among numerous third parties, but I'm sure that's just because they're "security-conscious egoists."

I think they are referring to post-bitcoin days, the quote was referenced from a paper released just last month.

Resistance to new technology is definitely a thing at banks, I remember when I worked at one I mentioned blockchain one day and everyone looked at me like deer in the headlights.

The banks aren't using trustless consensus. They're using a third-party "uniqueness service" to prevent fraud.

I doubt this message will propagate further than technical forums - you're just going to have suck up the homogenization, pasteurization, retail branding and consumer promotion of a once great technology

Interesting, my original understanding was that they were using the blockchain for uniqueness for Corda, but it looks like it's optional: https://r3cev.com/blog/2016/4/4/introducing-r3-corda-a-distr...

This somewhat makes sense since one of Corda's departures is that consensus and validation are limited in scope to the participants.

> No, actually, the one thing the blockchain provides, which was literally unsolved before pre-Nakamoto, was a working implementation of "trustless" consensus.

That's the part banks do not care about so I think it's largely irrelevant in the context of this article.

I spoke at length w/ a friend working on mortgage-backed securities for GS a few years ago and dealing with third-party (and even intra-office) trust was specifically why he was looking into blockchains, but I'll admit to not being super familiar w/ R3's blockchain implementation. If anyone has a less diatribey and more technical resource they could link to that'd be great.

It will never work in that use case. And I was hoping that the recent ethereum fork after the Dao debacle made it clear for everyone..

They will probably not be using the public Ethereum blockchain, so the fork won't be relevant.

> That's the part banks do not care about so I think it's largely irrelevant in the context of this article.

I have no idea where you got that idea, but it's not true. Which is why any deal that happens between institutions (and sometimes intra-institution) has an army of middle men who are responsible for verifying, monitoring, reporting, etc etc.

But you still need them in a Blockchain world, and still need to trust them.

Or you could convince some other banks to vouch for your transactions if you vouch for theirs and then get rid of the middlemen.

Isn't this similar to the cryptocurrency Stellar

You can use Stellar to build a gateway to another store of value, including bitcoin, dollar, mpesa, rai stone or, my favorite analogy, barn doors you have sitting in a shed somewhere.

No, because many of the middle men are there because you don't trust yourself.

Imagine you wanted to build a Hubspot/Triggermail/Vero type system, where you send emails to users when certain events are triggered.

Now suppose you use Sendgrid or Amazon to actually transmit your mail. You are unlikely to give very many developers actual sendgrid keys or access to call sendgrid. Most developers will call an internal API to send mail. This internal API will then perform a bunch of sanity checks - duplicate detection, rate limits, dirty word filters, etc.

Can you "cut out the middle man" by letting each internal service have their own internet connected SMTP server, and stop paying sendgrid and fire whoever builds the internal API? That would be pretty silly.

Similarly, a bank can't really get rid of the risk checks, money laundering checks, data normalization checks, etc.

I think Bangladesh cares about it by now

Is your argument that Bangladesh would have been safe if they were using a blockchain? Given their revealed security practices, I'd be surprised if they had the ability to secure any private keys from being revealed - and they would have had even less recourse with a blockchain based system (though admittedly, their recourse is limited even now).

I don't think so. They would have lost ALL if the private key would have been compromised. In this case they even managed to block some transactions and recover quite a big chunk of money.

And things like Smart Contracts are relatively new (1994), even though the concepts had been laid out in the 1970s. Smart Contracts are part of what makes blockchain more versatile, enabling transaction ledgers that can support the level of overwhelming (and sometimes unnecessary) complexity BFSIs can produce.

Unfortunately, even at this point, Smart Contracts probably still have many security challenges to overcome before banks can adopt it.

The trustlesness comes with a heavy price of Proof of Work with its wastefulness, complexity and vulnerability to various attacks. I can understand why financial institutions don't want that part.

It shouldn't be necessary either. The proof-of-work is only necessary to avoid a central party wrt. which blockchain is the "right one". Financial institutions are working together with each other, they can easily just agree on which blockchain to follow. But without proof-of-work, the blockchain is just a database with atomic updates. I don't see why they would need a blockchain for that.

Ripping Bitcoin in two gives you two fairly uninteresting things: 1) hash-cash and 2) a database full of public keys/signatures. Only combining the two gives you something interesting: negotiable/fungible hash cash (hash cash that can be transferred from person to person via a distributed database).

I think by "blockchain" they mean hashed blocks that include the hash of the previous block and can be synced; basically git.

That doesn't gain you much besides a definite order and a way to check integrity. Useful things to be sure, but nothing a traditional database can't do.

I had this feeling when I was discussing it here.

https://news.ycombinator.com/item?id=12044767

> But without proof-of-work, the blockchain is just a database with atomic updates. I don't see why they would need a blockchain for that.

I have been asking this question for a long time and not yet seen a satisfactory answer. At this point I'm sure that either I or a bunch of blockchain advocates are missing something important. Glad to know somebody else sees the problem too.

> The technological innovation of a blockchain is that it combines cryptographic signatures with a fault-tolerant distributed database.

This is the naive view that has allowed the financial industry to ditch Bitcoin and run with blockchain. The problem that Bitcoin solves and private blockchains do not is called the Byzantine generals problem which did not have a known solution until Bitcoin came along.

Private blockchains cannot solve the Byzantine generals problem because they cannot ensure that one of it's limited number of parties is not employing massively more computing power in order to cheat. Bitcoin only works because an unlimited number of players are mining as hard as they can making it improbable that a single entity can exceeded 50% of the total hash power. With private blockchains it will always be reasonable to assume that cheating would be with in reach.

> making it improbable that a single entity can exceeded 50% of the total hash power

Not that improbable: http://www.coindesk.com/ghash-io-never-launch-51-attack/

True, and the problem gets worse with less participants.

Keep in mind that a 51% attack doesn't guarantee anything, it just increases the likelyhood that you can reorder transactions.

True, but not necessarily that important. In world of Bitcoin this is important due to anonymity and criminal activity.

In a regulated industry there are other ways to prevent cheating. Making cheating obvious and undeniable is probably enough to prevent it from happening (due to legal risk).

If a private blockchain forks how do you decide which one was the cheaters branch and which one legit?

The legit branch is signed/vouched by at least (N/2)+1 parties and the cheating branch has less than (N/2)-1.

So groups of banks get to vote on what is true or not. How could that ever fail. /s

If that is viewed as a failure-mode before deployment, they can add servers at neutral bodies like courts, etc.

In the context of banks, where there are a limited set of semi-trusted entities and multiple trusted third-parties, I seems that most most solutions to prevent cheating offers is either really similar to a trusted third party solution, or offers no major benefits, but comes with many drawbacks.

In cash transactions, it's hard to beat the speed of a trusted third party with a deposited "float" for ensuring that you can pay at the end of the day - even a bad day where a part defaults.

In securities, there is perhaps some room for a blockchain solution, as the infrastructure is much more complex and underdeveloped - due to the historically gigantic margins.

> The problem that Bitcoin solves and private blockchains do not is called the Byzantine generals problem which did not have a known solution until Bitcoin came along.

I'm not an expert in any way, but the Wikipedia page for Byzantine Fault Tolerance suggests a solution to this problem was known as early as 2001, used in the Boeing 777 avionics software. See abstract of the paper below. That significantly predates Bitcoin. Or am I misunderstanding something?

http://ieeexplore.ieee.org/document/963311/?arnumber=963311

There were known solutions given a fixed set of generals. Nakamoto consensus handles the case of an unknown number of anonymous generals (miners) who may come and go when they please.

Out of curiosity: were there known solutions for an arbitrarily large number of fixed generals? Could a similar solution as with Nakamoto consensus be obtained by having a huge, fixed number of generals, setting some as occupied and using live inputs for those, and then using an alternating series of yes/no votes for the unoccupied generals? (Maybe you'd have trouble with off-by-one errors in the alternating series, but you could ad-hoc fix that.)

Come to think of it, why does the variable number of generals make a difference? When you are making a single decision, is that decision not an atomic operation such that the number of generals influencing it is fixed? Otherwise, wouldn't necessarily the outcome of the vote be (marginally) affected by the order in which you evaluate the votes cast? (That seems like a very bad property for a consensus algorithm to have.)

I assume protocols like Paxos can work with any odd number of generals. Since the generals are anonymous, consider a Sybil attack. If there are N total generals, what's to prevent me from claiming that I am all N generals? If there are N total generals but M entities try to each spam the system with fake generals, how does the system decide?

So you're saying blockchains prevent this because proof-of-work? I.e. that you literally can't run a Sybil attack, because the only way to impersonate N miners is to actually run N miners?

Yes. (Modulo arguments about the definition of "blockchain".)

How can you know a general is not a sybil?

What? The Byzantine generals problems most certainly did have solutions before Block chain came along.

Not for an unknown number of generals.

No.

First, solutions to Byzantine agreement for known numbers of processes predate Bitcoin.

Second, Nakamoto Consensus is not Byzantine agreement. Byzantine agreement forbids committed writes from being reverted, and each replica sees the same history of writes. However, Nakamoto Consensus only offers probabilistic write durability (our transactions can get orphaned arbitrarily far into the future), and different peers can see divergent histories of arbitrary length even under normal operation.

Third, Byzantine agreement is defined in terms of the set of peers. Systems where the agreement protocol does not know the number of peers cannot solve the Byzantine agreement problem, since they can't prove that no more than f of 3f+1 peers are faulty (neither quantity is known to the system).

Fourth, open-membership Byzantine agreement was published this year: http://hackingdistributed.com/2016/08/04/byzcoin/. The membership set changes every "block", but the peers in the set during the current epoch are known.

EDIT: typo

Byzcoin is interesting but like Bitcoin its security model depends on massively decentralized mining.

Mining is a function of turning electricity into coins. Since coin generation rate is fixed through a difficulty adjustment, mining becomes a winner-take-all game where only those miners with the lowest electricity costs can effectively compete. Thus the system collapses quickly into a mining oligarchy.

What does Byzcoin propose to resolve the as-yet unresolved problem of mining centralization, which is fundamental to the success of any of these coins?

Any proof-of-work based system has this problem, especially when the PoW is outsourceable. However, I believe you are missing the point of Byzcoin, which is that if there is a set of decentralised miners we can still get the strongly consistent, final guarantees of Byzantine agreement in a scalable way.

ByzCoin has PoW to be Bitcoin compatible, but it can change to PoS or PoA or even permissioned systems (e.g hyperledger).

The example clarifies my feeling about blockchain: How would the example provided (avoiding the clearing house) work without the banks accepting something like a mining-backed crypto-currency like bitcoin?

With bitcoins, there is no possibility for dispute: bank A gives bank B the money during the transfer.

Any other scheme involves a promise (a legal contract), so you will not know for sure that bank A really had the money to give to bank B. The solutions to this are all in use today:

(1) Bank A previously gave B money (they have a correspondence account in B). So the transfer is really between accounts at bank B.

(2) Bank A gives bank B physical money.

(3) Bank A transfers money to B between accounts at some other bank (or the fed). It means A had money in the other bank to begin with.

(4) Bank B gives credit to bank A (i.e., Bank B trusts Bank A) and accepts IOUs from them. The banks could cancel out each others IOUs. The IOUs become new money. This used to be done in the old days, but the basis for trust was each bank's gold reserves.

In scenario (4), they're bank-backed crypto-currencies. Banks are trying to build their own settlement coins: http://www.coindesk.com/utilities-settlement-all-about-banks...

other approach is issued ColoredCoin by banks - Lykke.com does this. then you get pricing of assets. fiat money are already "settlement coins", the question is about liquidity, risk and openness.

Can somebody explain me how we deal with the increasing size of a blockchain? I get moore's law etc., but other than that? I mean, it's trillions of transactions we are talking about. Federated servers? We break the chain in some way?

Most of the chain can be dropped/collapsed. All you need to keep are the final hashes. The white paper discusses this.

The best theory I could found is that everybody just starts trusting an old enough snapshot of the chain, and its end becomes the chain's beginning. Then everybody just throws the older transactions away.

I can imagine this working in a low volume chain. I do really doubt it would ever work on current Bitcoin chain or anything bigger.

It seems reasonable even on a massive chain. Some people do need to keep the whole archived part of the chain, and anyone who wants to verify it can do so, while day-to-day transactions can just compress that part of the chain down to a hash.

You'd need to keep enough of the chain live for all "live" transactions; that would likely have a time bound (days, perhaps). People who run a "full" client that verifies the complete blockchain then just need to have enough storage for the complete transaction volume over that time period. (And people who only need to worry about their own transactions and don't care about verifying other people's transactions can hold onto even less data.)

I'm a blockchain noob, but what about people like me that own some bitcoin, but don't touch them for a decade. I imagine my ownership of said coins would be in that part that is truncated/archived/hashed. So how would I then use them?

Someone more familiar with this than me feel free to correct me here, but this is my basic understanding:

If you think of your bitcoins as following a path from address to address, the pruning process would retain the final node or two on that path but discard any previous nodes. So your 10 year old bitcoins at address X are still the most recent node on that chain and are kept around. However, once they are finally sent to another address the bits recording your current address can be forgotten.

Yep. If people are familiar with Redis, it would be much like how Redis periodically rewrites its append-only-file to make it smaller. So you go from a file with full history like

    SET a 2
    SET b 4
    SET a 6
    SET b 10
    SET a 20

to just

    SET a 20
    SET b 10

The snapshot would just retain resulting balances at a certain block height, and no history of how they got there (previous transactions). If people wanted that history it could obviously be archived and accessed separately.

Would be interested in your feedback on Verifiable Maps as implemented at https://www.continusec.com/ which can give verifiable answers to specific questions such as what is the current balance as well as a full history log of all mutations to the map.

In Bitcoin, these final nodes are called UTXOs (unspent transaction outputs), and indeed if you use chain pruning or a light client, they are all you need. They also need to be searched quickly to verify transactions, so they are usually kept in RAM. Because they cannot be pruned, there is a soft fork being developed called SegWit that changes the accounting so that transactions cost more if they create many unspent outputs, or cost less if they spend more outputs than they create.

This is probably a gap in my knowledge, but I hope this isn't a terribly obvious question.

So let's say I buy a bunch of bitcoins and I just sit on them.

A year or two from now, they're worth a bunch of money, so I use them or sell them. How does everyone with the truncated blockchain know that the bitcoins I'm using aren't being double-spent?

The truncated blockchain would contain at least the latest amounts for any wallets. Truncation loses the old transactions, but cannot exclude any wallets that have any BC in them.

In this article's case, the "blockchain" isn't duplicated by everyone. It's just duplicated among parties in the need to know.

Any blockchain client for any chain (Bitcoin, Ethereum, Dogecoin, ...) could very easily implement a storage layer for the underlying blockchain data using a protocol like IPFS.

https://ipfs.io/

In this model, individuals would not need to store the entire chain as they could lazily fetch parts of the chain as they are needed. This would allow individuals to store very little of the historical blockchain data if their use case doesn't require them to access that historical data.

There are nuances to this solution. IPFS can be thought of as one giant torrent, and with torrents, someone must have the part you need for you to be able to fetch it. There is a theoretical failure mode in this model where everyone happens to delete the same part of the blockchain thinking that they won't need it and if they do they'll get it from someone else. In this case, this portion of the chain history would be lost. This failure mode should be simple to mitigate, especially since many people participating in the network need access to significant portions of the historical data, and everyone won't use the IPFS based storage layer so, when a chunk is not available over IPFS, the client can just fetch it over normal means.

How would you ensure the validity of the part of the blockchain you are reading from IPFS?

You may be aware, since you're asking the question, but you really can't without some other information.

If you have block D, and want to fetch block A, you don't actually know if it's the real block A unless you also have blocks B, and C. Block D (which you have) contains the hash of block C, which contains the hash of block B, which contains the hash of block A. You need the hash of block A to be able to verify that it is indeed the real block A.

Of course, because of things like SSL/TLS, you can be sure nobody tampered with the block on it's way from the server to you. With that in mind, ensuring you receive the real block just requires you to trust the server giving you the blocks, which may or may not be worth it depending on how much time/space it saves you. In some ways, the server would become your 'central authority' on the block-chain.

In reality though, I can't really imagine there's much they could do. Sending you fake blocks may work for a while but would fail if the client caches them and asks for the surrounding blocks (Their fake block isn't going to match the hash of the real block). I think it would be a bit hard to pull off for any length of time.

> unless you also have blocks B, and C.

It suffices to have the headers of blocks B and C. Which, at only 80 bytes per header, is quite manageable.

Are you sure? The header for C will tell you the hash of B. How will you verify the header given for B if you cannot hash the entire block and compare it to the hash you got in the header of C?

Each block's header contains a hash that is the root of a Merkle tree [0] of the transactions in the block. The Merkle-root hash effectively summarizes all of the block's transactions, which allows the overall block hash to be a hash just of the constituents of the header.

Thus if you have the header, you do indeed have everything you need to produce a hash and verify that it matches the hash referenced in the succeeding block. You do not need the information describing individual transactions.

0. https://en.m.wikipedia.org/wiki/Merkle_tree

This assumes you already know Block D is genuine. You can only know this if you have already verified all the previous blocks. You can prune them away afterwards, but you still must download and run computation over them once.

Not an expert about blockchains, but this makes me wonder whether something close to skip lists <https://en.wikipedia.org/wiki/Skip_list> couldn't in principle be implemented in blockchains to avoid this difficulty.

Imagine that block n, when produced, in addition to the hash of the previous block n-1, gave the hash of block n-2, n-4, n-8, ..., n-2^n. This implies that the block size grows linearly, but it should give you the following: whenever you request and obtain a past block A and you have the current block D, you can use these pointers starting at D to easily request and obtain a sequence of blocks (of length log n) which allows you to authenticate A from D. (Of course the algorithm to reach from A is simply to request the first block authenticated in the header of D which is after A.)

Bitcoin already has a p2p layer like torrents or IPFS that can quickly download the block chain from many peers. On a sufficiently fast internet connection you get limited by CPU speed verifying signatures.

Don't forget that like BitTorrent, IPFS uses a DHT to route requests. This makes it vulnerable to DHT routing attacks, where an attacker can Sybil the system and censor all of the routes to a block.

Is IPFS a workable solution, since storage and bandwidth still have real costs to participants? It seems to me it's prone to abuse (botnets storing large amounts of crap on it)

This is a problem Ethereum is currently working on. With the upcoming switch to PoS, methods of sharding the blockchain are being experimented with.

The Bitcoin whitepaper [1] (which is very short, concise, and definitely worth the read) describes how the Merkle trees might be pruned (transactions could be pruned when all outputs are spent) and in fact Bitcoin 0.11 added pruning (and 0.12 added further compatibility for pruned nodes).

Vitalik Buterin (Ethereum lead) also posted a description of how Ethereum will implement State Tree Pruning [2].

These are short/medium-term scaling solutions.

Many people are pushing sidechain [3] / child-chains [4] as longer-term ("Visa" level) solutions.

* Lightning Network [5][6] is what Blockstream and others are pushing for Bitcoin scaling.

* Raiden Network [7] is the Ethereum version, and may come out before Lightning, funnily enough.

For those interested in the topic matter, Vitalik wrote a pretty dense paper on blockchain scaling last year [8].

While sidechains will be an option, Ethereum is also pursuing on-chain scaling as well.

Sharding is scheduled for the upcoming Serenity release [9] (which also switches to Proof of Stake (Casper), another important scaling-related change). Writeup on Serenity PoC2 [10].

In general for scaling atm, processing/network latency/bandwidth for initial sync is more of a bottleneck than raw storage. By that measure, I'm actually a lot more interested in the on-chain tx-processing that Casper/PoS might bring [11].

Of course there's no requirement for a single chain to handle everything. Especially over the past few months, we've seen a few relatively smooth migrations to multiple chains as Bitcoin tx processing has "maxed out" (or more recently as fungibility/privacy issues have loomed). At the same time, Bitcoin volatility has stabilized, so it might be just the natural life cycle for blockchains to "scale" until they can't. It's still early days, so who knows?

[1] https://bitcoin.org/en/bitcoin-paper

[2] https://blog.ethereum.org/2015/06/26/state-tree-pruning/

[3] https://gendal.me/2014/10/26/a-simple-explanation-of-bitcoin...

[4] https://www.ardorplatform.org/

[5] https://lightning.network/

[6] https://lightning.network/lightning-network-paper.pdf

[7] http://raiden.network

[8] https://github.com/vbuterin/scalability_paper/blob/master/sc...

[9] https://github.com/ethereum/EIPs/issues/53

[10] https://blog.ethereum.org/2016/03/05/serenity-poc2/) from March

[11] https://twitter.com/VitalikButerin/status/760185856057638913

(phew, maybe one day HN will have markdown support, maybe one day...)

> I mean, it's trillions of transactions we are talking about.

It is not even close to that yet. Eventually yes. Right now the bitcoin blockchain is about 80GB.

What real numbers are you using to predict this being a problem?

BTW a 120TB SSD meant for read heavy workloads was announced not long ago. Huge, fast random access and made for reads is exactly what you would want.

Beyond that my own prediction is that there will be many successful crypto-currencies. Most people won't store the blockchain of any of them, but whoever wants to be more involved could pick and choose.

"the only thing previously stopping the standardization of reconciliation processes was the unwillingness of financial institutions to collaborate. Financial institutions spend $65-80 billion on back office reconciliation every year. The employees working in back offices probably offered lots of excellent reasons why their roles couldn’t simply be standardized away."

Being a general ledger, the Blockchain also can be used as a more professional way of proving you made a prediction at a certain time. Sure, as an individual, I can tweet where I think the P/E of Amazon will be in a year and refer back to it to prove my point, but is that the best way for a financial institution? Having an entry in the blockchain has a more business oriented feel to it.

Neither one of these is compelling to me as you have to prove that this was the only prediction you made and you aren't cherry picking the correct ones.

Why can't you place multiple bets? Hedging?

Goes back to an old stock prediction scam. You choose 1024 and send 512 the prediction that a stock will go up and 512 the prediction that the same stock will go down. Each day you repeat this process only with the group where you were right. So, 512 -> 256 -> 128 -> 64 -> 32. Eventually you have a small number of people that think you can predict the future and you can ask them for money that you will invest on their behalf.

This also happens in the sports betting world. People use this method to convince others that they can consistently predict the outcome of games, or the spread, or the other stuff people want to bet on.

Nicely demonstrated in Derren Brown's "The System": https://www.youtube.com/watch?v=9R5OWh7luL4.

Though we've rather ruined the twist ...

Preventing one individual from making multiple predictions doesn't necessarily solve this problem. You can do the same thing by getting 1024 people together to make a variety of predictions. At the end, one person looks prescient.

It's not clear to me how any system (other than education, which is obviously a very different topic) can solve the gullibility of people who are uneducated about basic game theory and common scams.

They'd also need (to become compelling) to prove why one should care that they tweeted a P/E prediction a year ago that turned out to be right.

We keep seeing a lot of examples of how Machine Learning can really innovate and reinvent all sorts of processes (i.e. the vegetable sorting we saw on HN yesterday), but when it comes to blockchains, it seems that it's mostly talk about how it could potentially change everything, but so far I haven't seen many very useful examples that couldn't have been done without using a blockchain (the whole blockchain thing often seems to be used just for the coolness factor).

Can anyone provide some ideas of how I, as a solo entrepreneur, could improve software by using a blockchain? I get how it might provide tremendous values for bigcorps, but I'm not part of that audience.

This is a good flowchart that tells you if you need a blockchain: https://pbs.twimg.com/media/Cn1YcTwVMAAvzac.png

http://dapps.ethercasts.com/

Are any of these dapps really in use and making a difference? It seems to me that the listed dapps are mostly technical proof of concepts. For example: a decentralized actuary sounds great, but I find it highly unlikely that the industry is really accepting it. Same goes for flight insurance and option exchanges.

Yes and no. Basically there was and still are major obstacles to widespread adoption. For example, VERY recently stuff like https://metamask.io/ and Mist has been released, which make this sort of apps more accessible to the average user. light clients protocol are still under development, there is lots of important scalability improvements on the roadmap (proof of stake, instantaneous transactions, unlimited txs, etc..). Decentralized storages such as swarm, IPFS, maidsafe etc.. are still under development. Overall, there is a lot of experimentation and throwing stuff at the wall to see what sticks. If you want to develop production ready stuff that your grandma can use today, you might be better off waiting 2-5 years until it's sufficiently mature and all the use cases are obvious. If you like to experiment with new paradigms, new architectures, and explore new business models then it's an exciting field to be in.

Yea that last point is where I'm struggling with. I've done quite a bit of software dev in the Bitcoin space. I built at least 5 different wallet apps (mostly contracting), but I'm still struggling with how I can use blockchains to build other stuff than payment systems. The distributed storage definitely sounds interesting and I can see how that would benefit certain scenarios.

Have you given a look at ethereum? Generally the community there doesn't care too much about wallets, that should tell you something :)

For usage, one of the mains advantages would be for systems that you don't want to use a centralized system anymore - for whatever reason from privacy to control over your data to simply infrastructure reasons (i.e you want 100% uptime and no censorship), and want to transform it into a decentralized system.

tldr; this whole breakthru in technology called the blockchain isn't a new idea at all. Banks have known about "shared" ledgers since 1800s. But because everyone is talking about Blockchain now in 2016, banks are finally ready to embrace some standards.

> tldr; this whole breakthru in technology called the blockchain isn't a new idea at all

I haven't read the article, and I been tired of blockchain hype for multiple years, but if this is an accurate tldr of the article, it isn't true at all. Blockchains are far more than simple shared ledgers. They're trustless shared ledgers, which is a huge leap forward from simple shared ledgers, and a pretty big deal for financial institutions, for whom dealing with trust issues is a major headache.

The point is that the trustlesness is not needed for the applications mentioned in the original report.

Also they probably don't want Proof of Work for its wastefulness.

Or, I'm sure, its relative slowness. LMAX can do millions of transactions per second. [1] Bitcoin is doing, what, 3 TPS? And I don't mean 3 million, just 3. (I get that from ~1600 transactions per block [2] and 1 block per 10 minutes.)

Back when I was doing trading systems, my traders would have murdered me if my response time graph looks like the Bitcoin one does. [3]

[1] http://martinfowler.com/articles/lmax.html

[2] https://blockchain.info/charts/n-transactions-per-block

[3] https://blockchain.info/charts/avg-confirmation-time?timespa...

>The 130-page report reminds me of those old Coca-Cola ads that promised to cure everything from headaches to exhaustion. The ads worked because nobody really knew what was in a Coke bottle.

I would have thought it was the coca.

>Similarly, the term “blockchain” has been so misappropriated that no one knows what it means anymore.

Thankfully, those who no longer know can just grab the paper at bitcoin.org/bitcoin.pdf and get a refresher.

Reply on news.ycombinator.com