Blockchains in their original design were special because they could resist contentious changes in the event of political turmoil. Bitcoin protects users against hyperinflation chosen by a ruling elite trying to fund a war, for example.
Bitcoin is a money that doesn't grant massive economic power to a controlling authority. The US has massive global influence derived from its status as the global reserve currency. Using bitcoin does not grant that power to anyone, and therefore could be argued as a better base for a global currency.
Namespace stuff is exciting for the same reason. Today there are powers and squatters and authorities that can decide if you get the right to a domain. This is inherently political for contentious names and sites. Decentralization isolates you from these risks.
Blockchain 2.0 has spoiled this quite a bit by running things like a startup and essentially giving full control to the founding team. I think most people who are newer to the blockchain space completely miss the advantages of a system that is extremely difficult to change.
I keep hearing about an inherent problem in this capability to "resist contentious changes". In dark corners it keeps whispered that if any one entity gets control over 50% of the mining capacity, they can essentially decide the "immutable truth" in the blockchain. Is there any merit to that scenario, or is it complete bogus? And if it's true, how come it's not more openly discussed?
I guess what I'm asking is if things like the hard fork of The DAO Ethereum blockchain are actually a fundamentally solved problem. Stuff like that happening when our banking infrastructure has moved to a blockchain sounds like a disaster.
> In dark corners it keeps whispered that if any one entity gets control over 50% of the mining capacity, they can essentially decide the "immutable truth" in the blockchain.
Having >50% hashing capacity allows you to arbitrarily select which transactions will or won't be confirmed.
Additionally you can perform double-spends, that is the most important thing (in my opinion) that proof of work was supposed to prevent. Of course with more confirmations this attack becomes more and more expensive to execute. For details see Majority Attack [0] page on Bitcoin wiki.
You listed two forms of control: social and computational. The latter is baked into Bitcoin and we rely on the assumption that no single entity will control >50% of the computing power of the network. This situation being "bad" is purely a consequence of the construction of the blockchain.
On the other hand, the DAO fork was a result of centralized control due to social factors. As with bitcoin, a >50% consensus is necessary to fork a blockchain. But because there is a single overwhelmingly popular ethereum client, the developers had the ability to make the software obey the fork by default. A referendum was conducted in good faith, and the devs flipped the switch. But again, this was only possible because everyone was using the same client to begin with, and few people bother to change the default behavior.
> the DAO fork was a result of centralized control due to social factors. As with bitcoin, a >50% consensus is necessary to fork a blockchain
I'm not very well-versed in computational power requirements on this scale, but it doesn't sound at all infeasible that a nation state (or a couple in unison) could setup a "51% attack", thus reducing the social form of control back to only the computational one. And if anything, that threat is only going to become worse with ever-increasing computational capability, advent of quantum computers at some point, etc. Nations (and other huge players) have the resources to tap into all that new power, while the individuals ideally making up the bulk of a blockchain's computing power would most probably not, at least not in big enough scale.
I don't see how that could be prevented, and that leaves me somewhat confused on why the blockchain is advertised as "immutable" as it is.
The current segwit non-adoption by miners in Bitcoin shows that with Bitcoin there clearly isn't as much social control as in ethereum. This can be bad or good, depending on viewpoint.
I myself doubt that segwit will ever get adopted in bitcoin. It looks like even if a small group of actors want to block some change, they can. So that will mean that the protocol will remain pretty much the same with the good and the bad features.
It depends on the blockchain. If you run your own full node in Bitcoin, it doesn't matter what the majority hashrate is doing. If they aren't creating blocks that follow your specific rules, you can ignore them. A 51% attack cannot change the block size, for example.
The ethereum ecosystem has placed a lot of trust in the ethereum foundation, plus the foundation controls a large percentage of the fully validating nodes, and is in close contact with all major miners, exchanges, etc. For this reason they are much more able to push through contentious changes. This is provably not the case in Bitcoin, as demonstrated by the active segwit vs. hardfork political deadlock.
yeah, ask people during the great depression how much they liked the fact that the lack of a central bank left them unable to mitigate the damage. there's a reason central banks exist and it's not just a globalist conspiracy.
The great depression was triggered not in small part by irresponsible fractional reserve banking. With bitcoin, there is no such thing. Your coins belong to you, and you can be certain that someone else has not already withdrawn them.
I'm not as technically versed in this stuff as it appears many people are here, but the use case for blockchain tech (not necessarily Bitcoin, though not necessarily excluding Bitcoin) may include, but not necessarily be limited to, currency.
If I had more time I could elucidate on specific use cases, but I'll list some existing attempts. For example:
* The recent foundation of the EEA[1] for the express purpose of developing with the existing public Ethereum chain and the development of other technologies that utilize both the public and private chains.
* Toyota experimenting with Oaken Innovations[2] utilizing blockchian tech (not mentioned is that this would involve an Ethereum blockchain[3].
* Maybe less notably, Kik recently adopted the Ethereum public blockchain as the foundation for their own internal token "Kin". The results of that experiment are yet to be seen.[4]
* Two of Canada's largest banks (TD, and RBC) have partnered with IBM on a project to experiment with using blockchain tech in a new identification system.[5]
There's likely more. I find it fascinating. But I guess my point being that for better or for worse there are most definitely use cases being tested, especially outside the use as a direct currency using currently established blockchain networks, no less.
I never understood the "volatility criticism" of the value of Bitcoin. It'd be remarkable if Bitcoin attained a very high value without short-to-medium term volatility. Realized volatility is not an intrinsic property to the technology or design itself, but rather a reflection of current aspects of the marketplace which can improve over time. (i.e. robust and trusted exchanges, well-capitalized market-makers, more diverse attempts at valuation, less emotional market participants, etc.)
You are correct, and I think the volatility criticism was not directed to the tech or design, but to lack of trust in exchanges, unclear valuation, and emotional market participation.
> Today there’s a lot of work going into decentralized distributed storage keyed on blockchain indexes; Storj, Sia, Blockstack, et al. This is amazing, groundbreaking work… but why would an ordinary person, one already comfortable with Box or Dropbox, switch over to Storj or Blockstack? The centralized solution works just fine for them, and, because it’s centralized, they know who to call if something goes wrong. Blockstack in particular is more than “just” storage … but what compelling pain point is it solving for the average user?
Ryan here from Blockstack. Our goal with storage is to allow users to bring their own storage (e.g. Dropbox, Google Drive, iCloud, etc). We believe in re-using the best infrastructure out there and not reinventing the wheel.
The key is that Blockstack delivers a thin layer on top of all of these storage providers with a common interface and end-to-end encryption, reducing them all to dumb drives. This (1) removes the potential for vendor lock-in (2) puts pressure on all the providers to be more competitively priced (3) enables greater data security.
Additionally, Blockstack isn't just about storage. It's a full stack for an entirely new kind of internet and a new way of building applications. Developers can work with a new blockchain-based domain name system (BNS), a new user-owned identity system, and a new BYOS storage system. The dream is for developers to be able to create a decentralized twitter by simply publishing a bundle of html, css and JS. The app folder runs as a single page application in your browser and can exist and replicate and live beyond the developer without the need for server or database maintenance. Servers could be relied upon for push notifications and feed aggregation, but they wouldn't be critical for operation and they'd be throwaway.
All this represents a pretty massive shift away from the model today. Instead of users revolving around applications, applications will revolve around users.
But why would I build a new decentralized Twitter "simply" (it's the HN go-to "I could build that in a weekend" that none of us could build half of in a year if we were actually trying to clone actual Twitter) when all of the money and control is in the centralized version?
Also, if the best example you have is "you can make easily decentralized Twitter after you learn all of our brand new replacement technologies for the things that you're already familiar with" then I don't think that's much of a value proposition.
Also also, come on - "applications will resolve around users"? Great catchphrase, but what does that even mean? Like we don't have product teams already trying to build things people want?
I'm not very well versed in the world of banking and finance. What would banks use a blockchain for?
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.
> I'm not very well versed in the world of banking and finance. What would banks use a blockchain for?
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.
You're making a couple of assumptions which make your entire argument invalid in the context of a "private" blockchain between e.g. several banks.
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.
There's no value of the work if there's meatspace negotiation, limitations like that on mining, etc, etc.
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.
git is a distributed ledger with safety and auditing built in just as much as a blockchain is, if not more.
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.
Today, banks clear transactions between themselves through the SWIFT network. By investing in distributed ledgers, a group of banks can collude to avoid settlement feees incurred by going through SWIFT.
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.
If you trust the counterparties enough to trust that they'll hold to the hashrate limitations, you are implicitly trusting that they won't try to screw you and take 51% control, in which case they can do whatever they want. The two concepts are literally one and the same.
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.
You don't need to trust everyone to hold to hashrate limitations, you have a closed network, you just need the majority of participants on the network to agree kick out any violators.
Here's an article describing how the majority of hashrate was reversed once for Bitcoin itself:
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.
> 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.
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.
Anyone could fake your signature on a few papers, bribe the guy at the land registry or whatever bureau handles property transactions and you could lose your house. It doesn't have to be a house, it can be a company or anything else. All at a fraction of the cost of 51% attack.
However, with a 51% the attacker now authoritatively owns my house. If someone tries to land-snatch my house in the real world, I go to court and get it back.
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 and so many other people in this thread misunderstand how a 51% attack would work in this context.
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.
I only want to know one thing: do you guys live in this world? I have been following Bitcoin since the beginning and there seems to be an utter disconnect between the blockchain hypers and the real world.
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.
Did you read the comment you are replying to? Not every country in the world is exactly like the United States. I was impressed that you managed to make a comment that was refuted by the comment it was replying to. But then you insult his intelligence? That is some next level idiocy.
> Seriously, who in their right mind would accept this? That you pull some data in a ... what, app? Provided by whom?
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.
You seem to misunderstand what we expect from a system like this.
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.
Not it can't. Because governments can refuse to honor the documents and they can also refuse to honor the blockchain proof too.
Sure like on paper, block chain will show he owns the house but without an approving authority no one cares.
As it is stated in one of the earlier comments, block chain is good for digital currency only.
Ok I have zero interest in blockchains and somewhat firmly believe them to be a fad but, honestly, you read like an Amish decrying "those metal monsters."
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.
Luckily, those kind of attacks can be detected and corrected in a non-blockchain world. A blockchain's features are not a good fit for this kind of use case.
Real estate sales, as you mention, are already quite expensive. Why would burning off energy, which adds to this cost, make any sense?
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).
>> 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.
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.
Does it seem reasonably likely to you that PoS could increase the proportion of computational resources that attackers would need, provided that the attackers control a low enough proportion of the tokens?
Intuitively, I'd say no. I can't see how you can ever prevent a '51%' attack (that is, 51% of compute power). No matter how many coins you own, the attackers can validate their own holdings and disavow the honest stakeholders.
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.
Nothing that is not as easily done with a database. Once you remove the proof of work which enables pseudonymity you are left with a kind of replicated database.
tl;dr -- private blockchains make it possible to distribute a common piece of infrastructure between businesses with competing interests. The sit between the stream of new inputs and the database.
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!).
> The killer feature of private blockchains is having a smart contract language.
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?
> A contract language has nothing to do with blockchains.
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
If you're thinking about the EVM's take what smart contracts should look like then you're 100% right. General, replicated computation is a good first step but a poor idea long term.
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.
A project I'm working on at work is utilising it for confidential computing between a number of parties that want to share data between themselves, but are direct competitors and don't trust each other.
My view is that the 'blockchain' hype has forced a conversation in the FI community around disintermediation and allowed them to invest in process optimization under the guise of blockchain innovation. I agree that the real innovation in this space is distributed security through proof-of-work, but AFAICT that's not interesting to the banking community.
I can't decide if the investors in R3 have no clue or if they are actually smart and are using this as an opportunity to modernise, unsettle the large networks, and also take the opportunity to pose as relevant.
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.
Ok. After reading all the comments, I am now instead leaning more towards the conclusion that private blockchains are tools to separate fools from their money.
How is Proof of Stake useful in an interbank network though? My understanding of PoS is that everyone wants to follow the same chain because the interest payments on your stake make it beneficial to you to accept a new block. Presumably there wouldn't be anything to stake in a private blockchain.
Proof-of-stake is not a consensus algorithm on the same level as proof-of-work.
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?
Actually, if you read one of their blog posts from the last few weeks, they've pretty much abandoned it because it's too hard a problem to solve. Sorry I can't cite, on a mobile and in a rush.
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).
I spend a lot of time in the ethereum proof of stake gitter and I can confirm that this is false. It's actively being researched and still in the roadmap. A hybrid PoS/PoW model will likely come out first.
So I can't provide a strictly bank-oriented response, but blockchain is just a distributed ledger system. I think some disservice is done in not clearly separating out the functions of blockchain from those of cryptocurrencies. You could use blockchain to manage property, contracts, microtransactions, data commerce, file storage, or certification, to name a few things. I think it's mostly a question of what can be fit into the ledger framework. Some people think that various local networks and other functionalities in the Internet of Things could be a testing ground for its broader uses (e.g., managing ownership of smart devices). Blockstack envisions it as kind of a backbone for a new Internet browsing paradigm, leveraging blockchain as a sort of DNS replacement if memory serves correctly. It's unclear if any of these ideas will take off in the near term.
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.
Except the examples you give demonstrate two widely divergent use cases - public and private. If you are managing an internal database, you don't need proof of work. You need concurrent conflict resolution. Every major database right now has such faculties built in and you don't need to spend megawatts of power to maintain it.
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.
I agree with you that the public use case makes more sense than the private one, though really I feel that it's not about "public" or "private" but rather about different sides in some market, whether it is public or private.
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.
A lot of the financial system is built on legacy systems that don't work very well, don't interoperate very well, and don't really have the capacity to handle what's demanded of them. Hence why a lot of very simple things takes days when they should take seconds, or cost several dollars when they should cost fractions of a penny: Stuff like transferring money between accounts, registering a change in ownership of financial assets, etc. Generally speaking the situation is something like "there's a central organisation that everyone trusts, they run a central ledger, but it's slow and limited; we need to upgrade it."
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. :)
I recently read an Interview with the CEO of one of Germany's biggest travelling agencies, TUI[1]. In it, he described selling the "hotelbeds" database service for 1.19bn€ because in the future information about hotelbed vacancies would be stored in a public blockchain, not in centralised closed data silos. He described this as a democratization of data, a counter model compared to how Facebook and Google currently hoard data without giving anyone else access to it.
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.
There's quite a lot of data out there which is shared by multiple companies with easy (or sometimes complicated) sync mechanisms where the actual money is not in the data but in the services that can produce this data. Hotelbeds is one example:
- 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'm still struggling to see what Ethereum adds over a regular API connection to the hotel's actual reservation database, except requirement for new software to be written and mining costs (paid by whom?)
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.
The advantage that Ethereum adds is other existing DAPPS on Ethereum. For example, a hotel owner could put up a room for sale and buy insurance right away for the case it won't be rented out in the next 24 hours. Or the owner could ask a prediction market, "what price should I set for this room?" to maximize my revenue. It's kind of hard to explain, but the biggest selling point of Ethereum is an ecosystem of Dapps working together.
Some serious questions - If you have technical not buzzword links for how 'the blockchain will work I'd also be happy. So far it all came to down to: smart contracts, etherum!?
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!
The contract (you can think of it as a class in Java) has a list of private keys who are allowed to make modifications to the database. Each key has has a list of associated privileges - what modifications can that user make. Keys with a higher privilege level have the right to add/remove keys.
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.
I don't think the relevant comparison is the cost of an Etherium transaction to the cost of a hotel room. I think the relevant comparison is the cost of an Etherium transaction to the cost of a transaction to a proprietary database.
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:
The extra cost here is not the cost of the DB write, but the rent extracted by the owner of the database. For example, access to flight bookings data starts at thousands of dollars/month.
Yes, that is certainly one of the "disadvantages of centralization" that I was referring to. Again, it's not clear to me that that cost will be higher than the additional costs of writing to a distributed consensus database (which are very very high).
It's not so much banks using blockchain. It's more blockchain being the new 'magic beans' that Deloitte, Accenture and their ilk can sell to clueless (but 'agile'!) executives.
Read up on how international banking and specifically correspondent banking works[0]. There is a lot of counter party risk for banks in that process. Bitcoin or something like it would allow a system to be built that eliminated a lot of that counter party risk.
The crypto-currency Ripple is meant to replace the SWIFT banking system. Right now, transfers between banks are relatively expensive, think for example about a $25 Wire transfer fee.
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).
Having a block chain doesn't mean that you have to give access worldwide to anyone and everyone. Banks could provide blockchain access to only computers that cleared their firewall, and are API authorized. Think ach except with a black chain as th back end.
Trust isn't a binary relationship. Computer security is hard. I trust people to try their best to not get hacked or not to get kidnapped and tortured, but alas it sometimes happens. I'm surprised no-one has mentioned that the only reason to use a block chain is to achieve byzantine fault tolerance. Casper is trying to solve much the same thing that has already been solved by Tendermint but with different trade-offs (CAP theorem trade-offs).
Well banks don't necessarily trust their international partners for example totally. Smaller banks fo instance have a lot of trouble sending unsecured wires. With the block chain it would be possible to have more trust on the amount of funds another bank has available.
I think the author has hit the nail on the head here. Blockchains offer two useful things:
* Decentralized authority
* A way to make digital goods scarce
To my knowledge, no one has created a business that takes maximum advantage of these strengths to provide value to the user. I can't imagine what kind of business could do this. Someone who can will make a lot of money.
What offers distributed consensus is proof-of-work, not blockchains themselves. The append-only list of blocks, that is a blockchain, is designed the way it is such that past blocks accumulate work performed on later blocks.
And the only "digital good" a blockchain can make scarce is the token which exists on the blockchain itself, which is completely useless unless it's supposed to act as a store of value. And, arguably, if a blockchain token is valuable because it's scarce, it makes little sense to have an unlimited number of blockchains even if each of them only have a limited number of tokens.
Yes, but block chains are also integral to proof-of-stake or general byzantine fault-tolerant consensus algorithms. Do you mind me asking: Do you have a lot invested in Bitcoin?
I don't know of any working non-proof-of-work cryptocurrencies ("byzantine fault-tolerant" sounds like a federated or centralized system to me, hardly a cryptocurrency IMO).
Look at Namecoin or Sia for example - Namecoin makes the ability to buy NS records scarce. Sia makes it possible to buy and sell digital storage.
This only applies to a few things for which ownership of the content is not the content itself and for which one party has more interest than another. If I pirate a TV show, I have all the value of the content.
On the other hand, if I read someone's DNS name, I do not have the value of controlling what it's set to. Similarly, if I want to buy storage, someone needs to be guaranteeing I can hold that or putting scarce resources that have value on the line if they fail.
Speaking as a co-founder of Sia, the primary advantage of a blockchain is the inability of any third party to interfere with your infrastructure. This also means you aren't depending on anybody to have uptime.
Today, when you put your data on a cloud, you select and trust a service provider. They essentially own all of your infrastructure at that point, and can easily disrupt your business or life if they decide that they don't like you. They can also do things like change price based on income level. Etc.
Sia removes that uncertainty from the equation. It's based on algorithms instead of people, and there's no controlling authority. It's a free market for data infrastructure with low barrier to entry and fewer places to introduce unfair competition. But most of all, it's going to be stable in the event of political chaos. You don't have to be an aws based logistics company worrying that Amazon is moving into the logistics space and now has a conflict of interest. You don't have to be a company in Turkey worried that the US is going to apply sanctions that revoke your access to the cloud.
Blockchains in general are a response to the systemic risk that we've built into the internet. I don't think that most people realize that they are useful for that (mostly because blockchains like ethereum really aren't useful for that)
> They essentially own all of your infrastructure at that point, and can easily disrupt your business or life if they decide that they don't like you. They can also do things like change price based on income level. Etc.
These are theoretically possible but never happens in practice because those are competitive markets in countries with established legal systems. Amazon directly competes with Netflix but if they were so inclined they'd be gifting business to Google, Microsoft, etc. and almost certainly facing significant legal repercussions.
The flip side of that is that you have contracts and SLAs. Most of the questions I'd have about something like Sia come down to the same issue: the homepage doesn't seem to make precise statements about durability, response times, etc. What guarantees does a potential user have for any of that, especially if, say, someone has infrastructure issues or decides to stop participating and removes their capacity?
Since you mentioned political instability, how do you avoid the Tor problem as soon as someone uploads legally risky material? Does that mean that the entire service is blocked because there's no more granular mechanism, or that participants need to factor possibly significant legal costs into their business?
All files are encrypted on the hosts and only can be decrypted with the key, usually present only on the storage buyer's machine. All files are uploaded to 3 different hosts to avoid issues if someone flakes out, and could be to more if needed and every hoster puts some money on the line if they fail to host the files, providing a sort of financial insurance policy. This may not be good enough for every scenario, but I think for most it offers the possibility of covering things quite well.
There are only a few major cloud storage providers around, the market just isn't that big and they're all quite expensive comparatively - for long term storage of backups and low-value data I find it quite a good concept. Publicly accessed data like S3 is often used for, not so much, that's more of a target for a traditional cloud provider or something like IPFS in the distributed world.
Sia's more creating a new market for extremely cheap, reasonably reliabile storage rather than replacing one for expensive very high reliability storage in my view. But by nature of the way the network works, it should be possible to tell the # of hosts needed to match Amazon or Google in reliability - it's not in a state where all of that's possible yet though.
> facing significant legal repercussions.
There's nothing illegal about price discrimination, it's a common buisiness practice and something companies strive for - they want to make sure you pay the maximum price you're willing to. To do otherwise is essentially a failure to their investors.
How do you protect against correlated failures - i.e. does separate hosts rule out the same person operating multiple servers? Any geographic requirements so the same power outage, hurricane, etc. doesn't take out multiple copies? That latter point seems especially relevant if you're promising protection against legal threats: say someone uploads banned data and this becomes known. Does the system allow those specific encrypted blocks to be removed or does that turn into legal action against every host subject to that legal authority, potentially taking large portions of the network offline at the same time?
> There's nothing illegal about price discrimination, it's a common buisiness practice and something companies strive for
We weren't talking about price discrimination, however, but anti-competitive practices which are illegal in many places. If AWS advertises storage for $0.02/GB/mo but tries to charge Netflix $0.05 or refuse service, they're going to hear from a state AG.
> especially if, say, someone has infrastructure issues or decides to stop participating and removes their capacity?
The network uses Reed Solomon erasure coding to prevent against failures. You can pick your own redundancy scheme, but the default is 10-of-30 today. (3x overhead).
> Does the system allow those specific encrypted blocks to be removed
Hosts have the ability to remove specific blocks if law enforcement informs them that they are storing illegal material. The host must make the choice to remove it though, you can't just choose to take down data.
> How do you protect against correlated failures - i.e. does separate hosts rule out the same person operating multiple servers? Any geographic requirements so the same power outage, hurricane, etc. doesn't take out multiple copies?
A combination of proof of burn and ip address lookups help us guarantee diversity.
> The network uses Reed Solomon erasure coding to prevent against failures. You can pick your own redundancy scheme, but the default is 10-of-30 today. (3x overhead).
Oh wow, I misunderstood that completely. Very cool. Will this be a user configurable setting when uploading in the future?
Would it also be possible to calculate a sort of "odds of safety" using historical transactions of the whole network? If so, please consider implementing some sort of slider in the GUI between "cheap", offering whatever the failure rate of a single host may be to "safe", offering the failure rate of as many hosts as needed to match the guarantees of most cloud storage providers today.
In the case of Sia, existing services are unable to take advantage of unused disk on other people's machines that is of little value to them, but more value to someone else - making storage extremely cheap compared to other existing services. The virtual scarcity provided by the blockchain provides a completely decentralized way to sell this storage with no 3rd party involvement.
In the case of Namecoin, it removes the need for centralization of naming services and in doing so prevents external parties from interfering with naming services, the owner decides where it goes, not a registrar, not ICANN, not the US government.
Generally speaking, decentralization is in one way or another the major argument for services done this way. Blockchains enable decentralization of scarce resources - but that's it. We need to stop proposing them for everything when they're really not appropriate for everything.
Now that people are making money in bitcoin again, you'd think folks would relax on these "everything looks like a nail" unnecessary blockchain solutions.
In order for a decentralized and autonomous blockchain to live up to it's name it needs to provide value to those who verify the transactions on it (ie. the miners or those who hold a stake in case of PoS). So the two extreme outcomes are: Truly decentralized and autonomous blockchains will disappear an be replaced by private, regulated versions and the value of most current implementations (ethereum, bitcoin) will go towards zero. Or people really value blockchains which can't be controlled by any government and prices will remain high. Most likely we'll see the emergence of both kinds of blockchains - depending on the use case. So to me this is where the analogy to Linux breaks down. Linux became one of the most important - if not the most important - operating system because it was free, open source and had a non-restrictive licence. Truly autonomous blockchains on the other hand can only prevail if they are exclusive and not free.
interesting read, still if the author is correct and blockchain becomes the defacto standard for decentralized server structure for banks, etc it is a huge position to take and will open up space for a lot of innovative applications on top of it.
Consumers don't use the internet any more than they use Linux. They interact with Google, Dropbox, Facebook, etc., not tcp, ip and ssl. Only only engineers use the internet, just like Linux. Maybe I always saw it different than the author, but to me the analogy of Bitcoin being like the internet in 1996, has always been about infrastructure.
I don't even get how this is supposed to be a criticism? Like this guy considers Linux an also-ran OS overall because it is only a bit player in one niche of "desktop OS"?
His point is that people are investing in blockchain technology like it's the next Microsoft/Facebook (read: headlock on a monopoly source of thousandfold profits), when it's actually more like Canonical/SuSE/Red Hat (competitive services business with low margins).
If you scroll way down this is what you get:
- "a reserve/settlement currency" - Why?? certainly not for stability.
- "replacements for huge swathes of today’s financial industry" - Still not concrete!
- "namespaces (such as domain names)" - Also vague what it would improve.
- "implementations of distributed storage systems" - To which he adds "the centralized solution works just fine".
So... still waiting to hear a concrete, specific, cogent use case.