Nothing, in my opinion. The value of a blockchain stems from the fact that, combined with proof-of-work, a single history of transactions can be agreed upon without a central party. This is the same feature that prevents alteration of history, because it would require recalculating the proof-of-work. This comes at a very high cost, however, since energy is literally burnt off just to reach this distributed consensus. Therefore, it only makes sense for the utmost valuable applications, like digital money.
I mean, right now Bitcoin miners are paid over a million USD per day in order for the network to reach distributed consensus. Please, anyone, let me know which kinds of applications can bear even a tiny fraction of this cost, except digital money. Even at 1% of this cost, a blockchain-based clearing protocol would be both more expensive and orders of magnitudes slower than using a central party -- and the purpose of clearing is to increase efficiency/reduce costs in the first place.
Banks are in the business of taking in deposits and lending them out, while taking a cut. Trustless lending makes no sense; you need to trust whoever you lend money to, or you'll be lending a lot of money to gambling addicts, with little chance of repayment.
The first is that you're assuming a race to the bottom where the banks will simply try to outspend each other on CPU. You can get a lot of the benefits of a blockchain where e.g. the 10 banks could all agree to each have 1 x86 box contributing to their part of the blockchain.
Any violation of such an agreement could be easily solved in meatspace, i.e. 9/10 remaining banks would just agree to ignore the chain maintained by the violator. Since they'd all recognize that they're getting /other/ benefits out of the blockchain without succumbing to some game-theory-esque race to the bottom.
Even if there's no such agreement the claim that any sort of alternate blockchain will use up the same resources as Bitcoin itself does is trivially refuted by various altcoins which use up less total CPU, since they're smaller networks.
The second faulty assumption is thinking that the only thing standing in the way of rewriting blockchain history is prohibitively expensive CPU resources. In the context of a "private" bank blockchain the banks could simply manually ignore a branch of the chain recognized as being produced by some malicious actor.
That leaves a bunch of valuable uses of the blockchain for banks. It's been mentioned as a replacement for the largely manual cross-bank money settling protocols they use now, replacing those with a blockchain would likely be much more secure and transparent, and any issues that arose by voluntarily running a "limited" blockchain would likely be smaller and more easily mitigated than whatever security issues their ad-hoc protocols have now.
Tell me how this theoretical private blockchain would be better, in any way, than a git repository where each bank signs commits, commits them, and pushes those commits to all participating banks.
It would be useful beyond some custom git-based solution because if what you want is just a distributed ledger with safety & auditing built-in you can get that off the shelf by leveraging e.g. the Bitcoin codebase. If you're doing that with Git you need to write a bunch of custom software around it to arrive at the same result.
The bitcoin codebase doesn't provide anything as good as you describe.
For example, let's say you wanted to find, in the ledger's history, a transfer of $20 from $a to $b. With bitcoin, that requires writing custom software. Git has built in tools to find changes with certain contents, signed by certain keys, etc.
If you want to argue about what has more mature tooling for the banking usecase, you'll find that literally anything that isn't a blockchain, be it git or a sql database, has more mature auditing tooling.
That's the benefit to financial institutions, and the threat to SWIFT. The technology itself is nearly irrelevant. From a game theory perspective, what matters is whether their R&D is plausible enough that they can use the tech as leverage to negotiate lower fees.
Also known as cutting out the middleman.
How does a distributed ledger remove/lower settlement costs?
Validating transaction settlement according to an agreed-upon set of rules is perfectly fine. The whole hashing thing on top of it makes no sense whatsoever for trusted counterparties: you just agree that if the block doesn't validate then it doesn't happen and nobody accepts it. The attacking bank is now "hardforked" onto their own chain that nobody else cares about.
Again, for trusted parties the hashing thing is entirely useless. A distributed ledger is fine, but not groundbreaking in a world with off-site replication of databases. You can probably hack something together with triggers for validation in like a week.
Here's an article describing how the majority of hashrate was reversed once for Bitcoin itself:
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-...
The largest miners all agreed to switch to the 0.7 chain, even though the 0.8 chain had more CPU power. This could just as well have been done on a closed bank network by e.g. everyone agreeing that Deutsche Bank are being dicks and trying to take over the network, and simply manually ignoring what they're mining.
If you're one of 10 miners on a closed network and you know the other 9 will simply start ignoring you if you break the rules, you don't have any incentive to break the rules.
You also haven't come up with any plausible scenario for why one bank would even bother to do this. If you're using a private blockchain for e.g. a SWIFT replacement as discussed in this thread, what's Deutsche Bank going to do once they become dicks and acquire 99.9% of the mining power? Disproportionately pay for running the whole thing? They don't have any interest either in screwing up the network or approving double-spending or whatever, since they're also using this SWIFT-replacement just like everyone else is.
Claiming that this is "useless" in "a world with off-site replication of databases" is missing the point. You're just failing to imagine that there can be anything on the spectrum betweeen a 100% centralized system with 100% trust and a 100% decentralized system with 0% trust.
How is a group of 10 banks who needs a SWIFT-like system going to run a traditional DB with off-site replicas, say the primary fails, which replica run by the 10 banks does everyone agree to fail over to? You'll very quickly just need some centralized party to run the whole thing at a large cost, and you'll end up with SWIFT again.
This is the part that a private blockchain makes easy. You have banks or other private parties that all benefit from running a low-cost distributed ledger, they can firewall this off from the open internet, and all of them just have an interest in keeping the system going as-is at a low cost.
It's easy to monitor whether some party is breaking the basic rules of mining, and once you have that setup adding new banks becomes a much easier lower-trust operation than e.g. giving some random new bank read-write access to your traditional RDBMs SWIFT replacement.
Real estate sales. US residential market, ~188K average house price, 5M house sales annually, 6% commission + 1-2% fees per sale. A blockchain record tracking the transfer of title, perhaps in parallel to the existing county appraiser records, and to the MERS system [0], would be worth something. At a flat fee of $100 (less than the property appraiser fee), that's 500M annually, clearing your bar of 365M. At a percentage of the sale, anything over 0.005% would do.
You're looking at tracking currency, but tracking assets and their ownership is another important function of banks, one that blockchains can help implement.
I seem to be missing how this would work or why this would be desirable.
Meatspace resolution is a feature, not a bug. Including for cryptocurrency, as the ETH/ETC hardfork has definitively shown (comparing the relative values of the two). Everyone talks a big talk about immutability... but nobody actually wants to live on the "authoritative" blockchain where somebody made off with 15% of the money supply.
If your assumption here is that you live in a war-torn country where a warlord can use guns to take away your property, or another situation with no real rule of law... the warlord is not going to care about what some "blockchain" says. Or they'll use their guns to force you to transfer it to them for a penny. Get real.
You buy a house, the transaction gets on the blockchain network. Just like you wait for confirmations with Bitcoin you'd wait e.g. for 1 day or for 1 week confirmations, this would be agreed upon by both the seller and buyer.
Now, let's say someone with deep pockets re-computes the last 1 week of transactions in a 51% attack and "undoes" that transaction. The branch of the blockchain that got replaced doesn't just disappear, it has your house in it, thousands of other houses will have been sold through that branch of the chain, and thousands of people will have that full public record.
At this point you and the rest of the owners could obviously go to a court and get your houses back, just as you could if the deeds got lost through a fire today but you had other evidence to prove they existed.
Nobody's suggesting that the entire court system be replaced by a blockchain and we ignore all other mitigating evidence, it's just being suggested that storing e.g. deeds in such a system is more reliable than storing them in a couple of filing cabinets somewhere.
Seriously, who in their right mind would accept this? That you pull some data in a ... what, app? Provided by whom? And it proves house ownership? Have you ever bought real estate or are you 14 to believe this shit?
In the real world, there is a chain of trust made out of lawyers, notaries, various government agencies and so on. It's only in the fever dreams of juvenile hackers and Ayn Rand believers who thinks the world work without it.
Exactly the problem I have with the system - MERS [0,1] - that the banks have been putting in place over the last 20 years. I think having to file, in paper, with local property appraisers may make the most sense as a check on large-scale manipulation, but having some kind of independent, incorruptible single source of truth is desperately needed and isn't especially there right now.
> In the real world, there is a chain of trust made out of lawyers, notaries, various government agencies and so on.
And in that real world, there's plenty of manipulation in which houses get taken from their rightful owners. See, for instance, 'Chain of Title' [2] by David Dayen. Again, some kind of independent, incorruptible single source of truth is desperately needed and isn't especially there right now. I wouldn't want to replace multiple, independent parties checking the validity of transactions, but having an accessible, reliable, incorruptible reference would help everybody, I think.
[0] https://www.mersinc.org/ [1] https://en.wikipedia.org/wiki/Mortgage_Electronic_Registrati...
[2] https://www.amazon.com/dp/B01DV1YERY/ref=dp-kindle-redirect?...
We expect that the ratio of failure compared to the burden on society to be low and so far the real estate registry, notaries, banks, lawyers very occasionally corrected by courts of law are providing this. Even if in a few contrived, complex cases it doesn't work out, that's fine.
Here's an example: I am a resident of Vancouver, Canada and last year I was buying a house in Hungary and I needed to empower my brother to act as my agent, and, repeat, I was the buyer not the seller and yet to give a power of attorney that is recognized for real estate contract purposes I needed a "strong" one: either one with an apostille which you can't get in Canada or one sealed by a consul of Hungary. The honorary consul in Vancouver was on vacation. So my options were: visit the honorary consul in Seattle, visit a notary in Washington State and send the document to the Corporations Division in Olympia, WA for an apostille and hope it gets done in time or fly to the embassy in Ottawa or the high consulate in Los Angeles. Lovely options, all of them. Thanks god, I actually had business in Bellevue anyways and the honorary consul in Seattle was helpful.
This is the sort of documentary strength we demand and accept when exchanging goods of high value. I have a strong trust in seals, signatures and such when backed by the court and ultimately the monopoly on violence by the state -- I have this trust even in Hungary where systematic corruption is in place. If someone debates whether I own that house in Hungary, I have the contract bearing the seal of a lawyer to show I bought it and the title in the real estate registry shows that the previous owner was indeed the seller. That's the chain of ownership. Could you bribe the real estate registry? Sure, I did in 2008 to expedite the copying of an important piece of paper (that's Hungary for you, no express processing available) -- but I have serious doubts of the possibilities of bribing the registry to falsify the title as there is the chain to show it false.
Meanwhile I have zero trust whatsoever in a piece of software. I am a senior software developer / architect / whatever you want to name, and I know how this particular sausage is made and I would not trust it too far.
We could create systems that fail in even fewer cases but as always with engineering as you get closer and closer to 100% precision, costs skyrocket. We could demand that ten good people testify to your ownership like a minyan for The Mourner's Kaddish but society, so far, is satisfied with the current system enough not to do this because it would be terribly onerous.
As it is stated in one of the earlier comments, block chain is good for digital currency only.
Software was good enough to send a few guys to the Moon and back fifty years ago, software is enough to tell you that your house is yours.
Anyone who can get by without intentionally wasting energy, for the purpose of reaching consensus (between whom?), will be able to offer the same service at a lower price.
I just don't see the purpose of employing an algorithm designed for distributed consensus, between a few, well-defined parties (buyer, seller, county appraiser).
PoW is not the only consensus algorithm out there. Sure, in a completely trustless scenario which is what bitcoin and some ethereum apps are doing - something like PoW or PoS needs to be in place (although Ripple has a different approach for example).
For internal private blockchains, this is not really necessary however and would just reduce the tx approval rate.
It's likely that PoS really just degrades into PoW, with stake holders needing to perform calculations as fast as possible to prevent attackers from out-competing them and generating alternate versions of the blockchain. Adding complicated fines and 'punishments' to deter PoS cheaters just increases the amount of work that they need to do, but cannot stop the problem.
At first glance, it seems to be a solvable problem because you can try to put obstacles in place that punish attackers (e.g. fining PoS attackers who generate 'false' results). But you cannot make these inducements to honesty bite, the attackers can happily keep churning out false results until they take over.
The problem is worsened because PoS is meant to save wasteful power usage. Honest participants are not likely to dedicate vast computational resources to it, while the attackers will be strongly motivated to do so. The end result seems likely to be an arms race, leading to an effective slide back to PoW, just with added complexity.
What are the possible use cases for something like this?
I've built one of these types of systems (kadena.io). The key differences between a replicated DB, though let's use consul instead because it's closer to a private/permissioned blockchain (distributed) and the differences are the same, are two-fold:
#1 They are designed to run in a multi-administrative context (i.e. where you don't own all the servers). Imagine running consul where you only had direct access to 20% of the nodes. You could do it, but you'll eventually have problems as it's possible for a few misconfigured servers to slow/halt/collapse the cluster. The problem is that in multi-admin you can't directly fix the troublesome servers. The system itself needs to be robust against them -- you need BFT consensus (for this and other reasons).
#2 The killer feature of private blockchains is having a smart contract language. It allows you to write and run code that runs on my servers without me having to trust/audit your code. This is only possible because of the frankly ridiculous level of security that the system provides. It is also a fundamentally new feature. For a new language that's actually appropriate for serious work (which EVM-based langs are not) take a look at Pact on the aforementioned site.
Simply, if you want to be able to host logic and data, with the infrastructure distributed among multiple administrative units (businesses/firms) that don't completely trust each other, then you end up building a "private blockchain". You need a decentralized way to replicate new information (consensus), that is robust against bad nodes (BFT), that linearizes the new information (blockchain-like), that can execute logic on your machine written by individuals that you don't trust (smart contracts), that tracks/enforces auth at every level (PPK-Sigs everywhere!).
A contract language has nothing to do with blockchains. All you need is a well-defined interpreter, whose interpretation all parties agree represents "the truth", and all that's left is entering into a legally binding contract which states these terms plus the "smart contract" in question.
Ethereum showed very well what happened when people enter into a non-binding (by the legal system) smart contract: they refuse to abide by the decision by retroactively modifying the interpreter to interpret the contract in their favor. And why wouldn't they?
In a strict sense, you're right. All a smart contract language needs to run is a linear set of inputs. However, they have a lot less utility without the other parts of a blockchain (distributed, crypto-data structure for assurance, etc.). If you don't care about being distributed, just use an API or run the external code in a container/vm.
> they refuse to abide by the decision by retroactively modifying the interpreter to interpret the contract in their favor. And why wouldn't they?
While I don't agree with the hard-fork decision, I understand (from a biz POV) why they did it. They didn't have too many options. Either hard fork or let the "hacker" collect the prize. IMO this lack of options was a failure of the EVM and solidity language itself.
While the DAO debacle had a bunch of causes but the main problems, from a language point of view, were: (a) centralized governance (upgrading/migrating) of a live contract isn't a first class citizen in solidity, (b) there's no distributed governance mechanism at all, (c) formal verification of solidity contracts is still years away.
Pact has (a) already and we'll be upgrading it to handle (b) as well next month (via a weighted vote mechanism). Either of these would have at least been able to mitigate the impact of DAO's issues -- just upgrade the contract and migrate the table the contract is guarding. Pact also has (c): https://youtu.be/Nw1glriQYP8?t=1072
So basically it's a hilariously slow and wasteful equivalent of Heroku. Amazing.
Blockchains, both public and private, are really just distributed DB's. You wouldn't fold a protein or price an option in your DB, you'd use some external system and save the results to the DB. The same line of reasoning goes for blockchains.
This is why we made our own language from scratch -- Pact is a bit like regular SQL + procedural SQL + programmable auth. It's not Turing complete and can compile to Z3 for formal verification. Given that every execution is a transaction, and it's interfacing with a normal DB, it's performance bottleneck is are the underlying DB itself.
I'm leaning towards giving them the benefit of a doubt as there are plenty of 'trusted 3rd parties' that are charging the banks significant amounts of money. There are clearly some incentives here.
As a technical decision, it makes zero sense though.
I have tried to figure out if a shared distributed ledger could reduce the huge deposited reserves for fast money transfer, but I doubt it unless the central banks are in this somehow.
When faced with two blockchains, one in which I control 100% of coins -- and thus 100% of the stake -- and some other chain, which chain do you choose, and why?
You can't use stake to make the choice, because that's a property of a chain, so you need to decide which chain to use before stake has meaning.
Also, what happens if an attacker exploits a bug in the Ethereum implementation, and uses it to replace all nodes' chains with his own copy? How can we ever return to the correct chain unless we just use trust/majority vote?
https://github.com/ethereum/casper
There's even a Github project where you can see that the current state is work on the "Fork choice/chain logic". This was started 6 days ago:
https://github.com/ethereum/casper/projects/1
The next release (Metropolis) will afaik contain a first implementation of proof of stake which will run in parallel with their proof of work algorithm (last I heard was that every 1000th transaction will be run via proof of stake, but I may be wrong here).
Going back to these blockchain applications being separate from cryptocurrencies, to me Ethereum is a step away from the coupling of the two, because it is designed with contracts in mind rather than just money. And a number of folks have signed on to developing systems that leverage Ethereum - take a look at the Enterprise Ethereum Alliance. Still I suspect that given the fact that it's unproven, the actual investment made in personnel and capital by these firms is low. Also, the ironic counterpoint to this view is that Ethereum also has ETH, a cryptocurrency. I'm an investor in ETH, but even so, I am not sure what it is worth at this point, since the value of Ethereum seems to lie not in currency but in other applications of the blockchain.
In the public dns replacement use case there is promise and potential, but it has the laundry list of problems you would need to solve to make it happen. I look forward to the attempts, of course, because traditional dns is a brittle top down nightmare of exploitable corruption and manipulation.
But still, blockchains as they are are only useful when you don't trust participants. And for along large-scale application, making that claim puts you in a political position - either you trust or distrust the governments oversight of whatever you are trying to reach consensus on. While a lot of people will, at inquiry, say they don't trust the government, very few people are willing to put the effort into forging an alternative public trust framework for things like property rights or certification that you mentioned.
But I'm not sure I understand, were any of those use cases "private?" When I mentioned "manage property, contracts, microtransactions, data commerce, file storage, or certification, to name a few things", I think pretty much all of those besides file storage (on which I'd defer to Blockstack) represent agreements or exchanges between different sides in a market or platform.
However, spending millions and millions of dollars to make a better system for recording payments, or changes in land title, or whatever is a hard sell. It's an extremely boring problem that's been solved ages ago, and now someone needs to actually go and build it, but nobody wants to fund it, and nobody wants to work on it.
A blockchain, on the other hand, is cool. People want to talk about them, people want to work on them, and you can get funding. Of course, it's totally unsuited to solving any problems banks actually face, but that's neither here nor there. :)
To me it didn't make sense, because who would participate in such a blockchain? Who is the miner? Why? Where is the trustless concensus feature needed? Maybe someone more knowledgeable can explain what he meant.
[1] https://www.welt.de/wirtschaft/article164874973/Die-Internet...
- Hotels want to have their information on as many sites as possible
- When travel site A blocks / books a room, travel site B and C need to update their databases quickly
- The money is not in the database, as those are effectively just data caches of the information that the hotels will happily provide free of charge
- The data is already shared between hotel sites, just that every site has their own data silo.
- Money is made through individual contracts, upsell, services or better UI to access the shared data
Another example of this is, of course flight information.
So why would a company move this data onto a blockchain. We can take Ethereum as an example. Note that some of the things I describe here are presently not possible with Ethereum but will be possible within the next couple of software updates (I imagine within the next 1-2 years). Ethereum offers an existing, working, generalized blockchain with existing miners. Sure, a company could try to roll its own blockchain, but, as you observed, who would want to mine that. Also, there's little to gain by taking a private database and making it a semi-private blockchain.
Ethereum incentives the miners with Ether to continue to secure the data and keep the consensus.
The Hotelbeds database could become a database on top of Ethereum and the access would be regulated via a smart contract. That smart contract could be used to mark an individual room as booked (or reserved) for a certain time range. This means that each booking would cost a small amount of gas to pay for the transaction. Ethereum strives for a sub-second block time, which means that the database transaction could be almost instantaneous (compared to, say, Bitcoin, where currently transactions sometimes need to wait 3-4 hours). In comparison to the booking cost of the room, this small transaction / gas fee would be negligible (I hope). Since all Hotelbed sites would use this same contract / blockchain, there'd be no syncing required, as all changes would be available to all clients the second they happen. Even better, the smart contract could contain basic logic to defend invalid requests without ever alerting the clients (booking invalid dates, etc). A different, but related dataset (say car bookings) could also be hosted on the blockchain and could be queried at the same time to provide additional services ("there's one free car to rent for your hotel in that timeframe").
Alternatively, of course, all hotel sites could just get their data from one database company that sells access to the data and takes care of an internal database of all hotel bookings (i.e. Google). However, then, you're dependent on a different vendor. He may change his prices, he may limit the data, he may start giving certain hotels only to premium clients (see net neutrality). Even worse, at some point he may stop serving the data because it is not economically feasible (see Google Reader, or Facebook Parse). With Ethereum, there's nobody who officially owns the database. It can also never be taken offline again (at least until the last miner stops running his Ethereum node).
This doesn't work for data sets where the value lies in the data itself, but for data which is already replicated across multiple databases anyway, this is a great alternative solution to have a truly global, synced, database that is owned by nobody, where nobody gatekeeper, and where the entrance barrier is low.
I.e. it wouldn't make sense for Facebook (obviously) or Gmail, but for a truly decentralised Twitter (nee Diaspora) or Weather Information, etc.
I mean, hotels are a great example of a system where there is a gatekeeper (the hotel), that gatekeeper wants to do stuff that blockchains aren't optimised for (rolling back transactions, keeping most of the data non-public and limiting who can access the shared bits at what rate) and doesn't want to do any of the stuff which blockchains are optimised for (trustless transactions, immutable permanent records). With hundreds of thousands of travel agencies already using distribution platforms that interface with existing reservations system and none writing smart contracts, I can't see any incentive for a hotel to insist on accepting bookings in the latter form. Making a purely internal blockchain database like TUI have done is an even weirder move.
(English version of the TUI interview http://www.tuigroup.com/en-en/homepage-news-specials/2017-05...)
Some questions:
How is user access organised?
How to remove an organisation?
How to remove old booking for hotels?
How to prevent me from exploiting an bug in the database? I.e. incuring storage or computation costs -> DDoS?
How to revoke access when a private key / access token is compromised?
If I'm having a lot of Etherum due to hacking or stuff like that - what prevents to me extort the Hotels to break their system? Blow up the database? if I have enough gas.
Bug in the database?
I'm honestly interested how this is solved / will be solved. If you have links - at best with some math / hard concepts please share!
Thanks!
When someone creates a booking, he has the right to remove his own booking. Each booking might also have an expiration date, so it's removed automatically when expired. When a key is stolen, a key with a higher privilege level can disable access of the stolen key.
If it's implemented correctly (which will take time and maybe several failed attempts), hacking, bugs and DDOS should not be an issue.
Distributed consensus transactions are MUCH MUCH more expensive than transactions to centralized databases. Is that extra cost worth eliminating the disadvantages of centralization that you cite? Maybe. But that's not at all obvious to me.
Keep in mind that a transaction on the block chain currently costs about $11:
144blocks/day * 12.5btc/block * $2100/btc / 335000transactions/day
[0] https://gendal.me/2013/11/24/a-simple-explanation-of-how-mon...
Ripple would make it so these transactions between banks costs only a few cents, and can be verified easier. That being said, I am not a fan of investing in Ripple because they have no private wallets, and they have stolen from customers because of KYC/AML (Know your customer/Anti-Money Laundering).
https://gendal.me/2015/04/27/how-to-explain-the-value-of-rep...
Internally (as in completely private intra-bank blockchain) - for transaction tracking/mining etc.
All I can think of is a trustless clearing house. That would make sense on one hand, but it would also divulge a lot of possibly sensitive information to the public.
Other that that I know there have been a lot of hackathons about Bitcoin organised by banks but I never heard anything coming out of them.