On blockchains and why secure ledgers don't require proof-of-work(pfrazee.github.io) |
On blockchains and why secure ledgers don't require proof-of-work(pfrazee.github.io) |
Alice owns a bitcoin. Alice validly signs a transaction transferring that bitcoin to Bob. Alice also validly signs a transaction transferring that same bitcoin to Charles.
WHICH IS CORRECT? Neither is a forgery. Both signatures are valid. If Dave downloads the blockchain, or receives both transactions, he can't just look at them and determine one of them is fake. Neither is fake. He needs a way of arbitrating who actually has the bitcoin now - Bob or Charles.
PoW is that arbitration process. Dave looks at the competing blockchains (one with Bob having received it, and one with Charles having received it) and can trust that everyone in the world will respect the chain with greater PoW behind it.
Paul's system has no way of addressing this other than "trust the central authority to process transactions in the order they receive them". Thanks, pal, that's called e-cash, and was invented by David Chaum in 1983.
I'm sure there is a reason, and I vaguely recall some people talking about proof of stake a couple years ago, but I'm surprised we're still melting icecaps running ASICs out of China for new coins.
Because of Sybil attacks.
> So in your example, if Alice signs both transactions and she doesn't have the funds to fulfil both of them the transaction causes Alice to lose 100% of her money.
Remember, the goal isn't to punish Alice. She's losing 100% of the bitcoin no matter what happens. The goal is to assure Bob (or Charles) that the transaction they receive will be recognized as valid by the rest of the world.
If you're Bob, and you know that Alice can invalidate the transaction (e.g., burn the bitcoin you just received) by signing a second transaction in the future, why would you ever accept Bitcoin?
Don't punish Alice. Assure Bob.
Because the incentives of nodes in a web of trust is not to tell the truth about how much money they have; their incentive is to prefer whichever chain says they have the most money.
With proof-of-stake, an arbitrary number of valid chains can be created from scratch in no time. How do we decide which is the right one? All nodes will prefer the chain that says they’re the richest, and the nodes that most efficiently can coordinate their lying will end up with all the money.
Proof-of-stake solves the wrong problem: the problem isn’t to decide who gets to extend the chain, the problem is deciding which chain to extend in the first place (there can be millions of valid PoS-chains).
>What is proof-of-work? Proof-of-work is a system for establishing “decentralized consensus.”
Agreeing about the order of events is very difficult in computer networks, especially if you can’t trust the other computers involved. Unfortunately, it’s also very hard to establish trust in a global network which aims to provide open participation. So, we need a way to agree on the order of events without establishing trust.
Proof-of-work solves that problem by putting the network on a trustworthy clock. It’s a kind of computation which takes a predictable amount of time to run, and which can’t be forged by a bad actor.
With proof-of-work, you can have multiple computers make additions to a blockchain without having them trust each other. That’s decentralized consensus.
Decentralized consensus is intended to mean that one entity can’t control the blockchain network. Any newcomer can participate, and ownership is equally distributed among the participants.
That’s not right. PoW takes a completely unpredictable amount of time. It’s not about a clock ticking, it’s about making the presence of two incompatible versions of history as expensive as possible, thus forcing the network into consensus.
If you don't need trustless time ordering of data, you don't need a blockchain. You just need... a database
Flatly wrong. Decentralized consensus is not a necessity to create trustless operation. Monitoring service operation via a secure ledger provides trustless operation. As I said, the point of PoW is to provide strict transactional consistency in a decentralized network. You're just describing that process mechanically.
I hope we're not talking at past each other, but I read your post as proposing a system where there's a central party that computes transactions "in the open" in a way that third party observers can verify.
That's hardly useless, but it's not a replacement for Proof of Work. PoW is for decentralizing the ability to choose between competing valid blockchains. It prevents double-spending by making the benefit of double-spending (the value of the your transaction) far less than the cost of double-spending (the electrical cost of 51% of the mining power for 1 hour or so).
Your system uses a centralized host (see "Services with Secure Ledgers", paragraph 2), and (I presume) third-party observers can verify a "secure ledger" by seeing which one has been more recently signed and time-stamped by the single host.
I mean, sure, centrally hosted servers are more efficient than Proof of Work. No one who know what they're talking about disputes that. But the whole point of PoW is to allow decentralization without a single host.
The block reward incentivizes participants. Why should I run a monitor node for this new cryptocoin? Who will allocate the coins and how?
> Am I certain that I need strict global consensus?
Perhaps not but IMO it makes things much simpler to design as a result.
Specifically, if you want to offer a service where you can guarantee non-repudiation a centralized blockchain is a great solution. By non-repudiation, in the scenario of a double-spend whomever signed both transactions is 'on the hook' for both. This doesn't work for currency but works for systems where it is sufficient to prove your servicer screwed you over.
Blockchains specifically solve decentralized consensus. It’s expensive and slow compared to using a central authority, but the advantage is that the system doesn’t suffer from a central point of failure.
See my response to hagreet. Neither of those problems are unfixable.
https://www.hyperledger.org/ https://www.r3.com/
There are lots of other 'private blockchain' distributed ledgers being pitched right now to financial institutions and to me the distributed aspect of them seems like a bit of an inconvenient and unnecessary complication for those use cases.
Removing the need for trust is what takes all the energy.
And, further, I'm not suggesting you trust a third party, but if you feel I am, please point specifically at where.
I don't particularly think that using a central secure ledger is surprising or new, but I do think that politically the furor around DLT (and who knows, maybe one day CLT too) has provided us with a fantastic political opportunity to actually fix some of the horrendousness in financial software systems.
To my mind, even if the relevant technological change is pretty minor or nonexistent, this is an opportunity for us to replace a bunch of miserable systems duct taped together with more modern systems that have externally accessible APIs baked in from the start.
Perhaps cryptocurrency still need it, but not many of the 'non-cryptocurrency' use cases.
My argument is centered around a following nuance:
If the use case allows to assume that 'originator' of a particular event is trusted, then the distribution of that event across multiple untrusted servers/access points, does not require a proof-of-work.
The example of how this works is explained in paper " Balloon: A Forward-Secure Append-Only Persistent Authenticated Data Structure
by Tobias Pulls and Roel Peeters
Abstract: We present Balloon, a forward-secure append-only persistent authenticated data structure. Balloon is designed for an initially trusted author that generates events to be stored in a data structure (the Balloon) kept by an untrusted server, and clients that query this server for events intended for them based on keys and snapshots.
All that blockchain does is to timestamp documents (transactions), the purpose of which is to tell which of the two documents was earlier. Then, the only purpose of proof of work and its derivatives is to artificially slow down signing the documents (transactions), so everybody would have about the same processing speed. This single assumption (that no single entity has computing power comparable to a significant portion of all the others combined) is what allows to choose longer chain in the case of double-spend incidents. When this one breaks, the whole protocol breaks.
There are also other dumb ideas, like that "blockchain is supposed to have a single linear history of transactions". It's not. It would if there was only one party that issues the transactions, so of every two transactions one would be marked as earlier than the other. It's wrong, since there can be incomparable transactions (usually concerning unrelated wallets).
> With proof-of-work, you can have multiple computers make additions to a blockchain without having them trust each other. That’s decentralized consensus.
No. That's distributed timestamping. Again, consensus is totally different problem (and well-defined at that), but author apparently doesn't know that.
> Instead of a network of miners, you use a single host. That host maintains a secure ledger which contains the host state and its activity log, including all requests and their results. That ledger is then published for clients to actively sync and monitor.
Congratulations, you have developed a centralized timestamping service and you have discovered that centralized service is functionally equivalent to a distributed one. Mind you, you're not the first to think about those.
So 0.02%[1] of the global per annum energy consumption? <snore> I'll gladly trade that to run an economy without violence and bring financial inclusion to 6 billion unbanked people.
[1] 24/109613*100 https://en.wikipedia.org/wiki/World_energy_consumption
>Because you don’t need permission to buy hashing power and participate in Bitcoin, there’s no way a “51% attack” can be stopped, except by outbuying your competitors
Incorrect, this author doesn't understand the miner<->node relationship. Miners do what users value or else users change the consensus system they value. DoubleSHA256->Script or Equihash etc etc
>In Bitcoin, acceptance of a change is signaled by the miners - once some percent of the miners agree, the change is accepted. This means that hashing power is used as a measure of voting power, and so the political system is essentially plutocratic.
Incorrect again. The author is mistaking how consensus-level changes, that users want, are coordinated among miners. BIP 9 was a method where users said "we'll wait for you all miners to coordinate amongst yourself a consensus change" which was used to delay. In the future Bitcoin will use BIP 8 which is "Miners prepare to have your old consensus rejected at flag point X or else your blocks will be orphaned.
>Bitcoin has been wildly unstable, with controversies and forks happening quarterly.
The bitcoin network is stable as a table. Bitcoin can't deny anyone from creating their own fork from consensus. This is a critical feature not bug, to be able to easily exit from the system. It prevents lock in that plague trusted third parties.
>I’d explain proof-of-stake here, except that I don’t totally understand it yet.
If you don't understand the second most prominent proposal for decentralized consensus, why are you writing a critique about blockchains? PoS is inherently broken from an economic perspective because it is no more "efficient" than PoW. Marginal Cost = Marginal Revenue.
If you have an incentive mechanism that says, "Do X and you get Y money" you're going to spend X<Y amount of economic work to get Y money. http://www.truthcoin.info/blog/pow-cheapest/
PoW = destroy X value in fiat space to gain Y value in Bitcoin space PoS = destroy X value in Ethereum-PoS space (via TVoM, meat-space work) to gain Y value in Ethereum-PoS
The value in PoW is that it's very hard to 'more efficiently' consume electricity than your competitor. All that PoS does is push that wasted work into hidden area or human space.
>Instead of a network of miners, you use a single host. That host maintains a secure ledger which contains the host state and its activity log, including all requests and their results. That ledger is then published for clients to actively sync and monitor.
Ah, So digicash. Which when it went out of business the market died because there was no coordinator any more to check double spends. Let's assume that the business never can go out of business. If I want to destroy the network, I can compromise one system and control the entire state of the database. Ok let's assume the system is uncompromisible. Oops the state just censored your 'secure' ledger because someone did something with it that the political class didn't like. "We'll host it in a country with 'just' laws" There is no such thing as "the public good" where all people benefit from a certain action. There will always be winners and losers in any policy decision. Now value is sapped from the system by constantly having to pay lawyers to defend your rights from encroachment by the state.
The author is right to question if everyone application needs to run on a blockchain (hint: they don't). But if you need trustless, robust, decentralized, uncensorable state to be agreed on by multiple parties, you're gonna need a blockchain
No need for a wasteful arms race just to elect a leader who can be DDOSed.
"ripple is voting with a consensus level of 80%, so it can tolerate byzantine failure of 20% of all nodes". My question is then, how does this deal with sibyl attacks. That is, how does it prevent me from just creating a large amount of participants. Similarly, what happens when nodes 'leave' the system.
Say we have 200 nodes, then the consensus level is 160 nodes. What happens when 10 nodes stop responding? Are we forever stuck with the consensus level of 160 or does it ever drop to 152 nodes? In the first case, we are inevitably careening towards faulty nodes forming 20% of all required votes. In the second, we can enforce consensus by censoring other nodes.
But you should really look at Ripple's consensus and study it:
https://ripple.com/build/xrp-ledger-consensus-process/
As well as HashGraph. Both of these do NOT require proof of work!
But in any case I think consensus is the wrong long term goal for technology powering currencies and other things. See my other comment in this thread regarding that (https://news.ycombinator.com/item?id=15646385)
Forks are ok as long as they can be merged in the short term.
If something forks for a long time and stays forked, there is hardly any reason to establish a total order during the merge!
Think of an IRC netsplit for example. One that happens for a few seconds may attempt to merge back the chats in some fair order they were made, in diff forks.
But if the netsplit happens for a whole day, or month, no one really gives a crap about ordering messages across forks. The merge is too complex! In fact, the resulting conversation would be MORE nonsensical than if you correctly rendered the split conversations as a DAG in the client.
Similarly, if bitcoin forks into bitcoin cash or whatever, and enough validators accept it, I get to "double-spend" my new money now. Proof-of-work is no panacea. If we religiously want consensus then no transaction can ever be truly confirmed - there is always a chance some larger fork comes along and undoes all transactions on my fork going back a whole month. Interplanetary File System has to deal with this.
The problem is that we still haven't evolved our thinking about currencies as DAGs and keep worrying about the double spend problem and turn to global consensus to fix it.
This is rather unique to the case of currency though. Specifically, the history of transactions determines which future transactions are possible. Instead a system that only records promises (but doesn't allow transfer of such promises) would work without centralization. If I promise something to 2 different people I remain on the hook for that promise. The fact that I am effectively 'in debt' on the system isn't an issue because the system gives no guarantees on people meeting their promises.
If the answer is to stop caring about double spend, how do you anticipate that working?
That assumes you know what Y money is worth, when in reality you don't.
If you do X then Y money is worth X by definition because you won't let go of Y money for any less than X value in exchange unless you are forced to.
As for Bob isn’t he assured once he sees inclusion of his transaction into the 51% signed dag? Also Alice’s punishment is only for double spending before inclusion into the dag. On second thought it should go to the miners, not just get zapped into the void.
Wrong. Blockchains specifically timestamp documents. Consensus is a different problem and blockchains don't even touch that.
Do you also claim that a one-way hash function only gives a minor gain over a B-tree? Because document timestamping and establishing consensus are different problems.
If a service wrote all transactions into a log in a way that allows for easy verificatio9n of the validity (including order), and the parties using the service regularly check that log, those parties can demonstrate that the service is acting correctly.
Questions about transaction order and consensus are separate problems, which may not be necessary, depending on the nature of the service. The point, I believe, is that some problems only need some of the features usually associated with "blockchains". We are only beginning to find the interesting uses for Merkle trees, and thus shouldn't blindly use the current bitcoin-style design when the current problem could use something similar,
I think you should verse yourself in cryptography before any discussion about it, including talking about blockchain. You seem not to understand what cryptographic timestamp is and what purpose it serves. Wikipedia has a nice introductory article approachable by a layman under "trusted timestamping" title.
My argument is that decentralized consensus is actually a political solution. It has technical merits -- it makes it easier to deal with a host that breaks the contract, because there are lots of nodes, so you just 'route around' the faulty host's output. But that's a technical solution to a political problem: how do you deal with a bad actor. And we deal with that every day with existing services, by switching away from bad actors. You handle bad behavior politically. If we can lower the cost of a switching, and we can build accountability into the system, then we're getting the same kind of value that decentralized consensus provides at substantially lower system cost.
I mean if you're REALLY lucky you'll start something that's as popular as Litecoin and it will be worth 1% of what your Bitcoins were worth.
Bitcoins are only worth anything because you can go anywhere in the world and people will accept that there is one and only one blockchain, and if you own bitcoins on that blockchain then you own them, period.
Proof of Work allows you to solve bad actors without switching away to a new network and losing all your Bitcoins. Your solution doesn't. If you have a centralized system that centralized party could refuse to honor your bitcoin holdings and wipe out your balance.
This really isn't a new solution. I was serious before when I said David Chaum's ecash (from 25 years ago) was an approximation of this .
This isn't impossible to solve. You can establish, in the ledger itself, the process for migration after a catastrophic failure. You can set a party which will mediate the issue and decide on the solution. You set up rules for how to reconfigure the network, and trigger them when a corruption proof is published.
I agree it's less elegant than what decentralized consensus provides for handling bad nodes, but you really have to balance this against the expenditure of proof-of-work. The cost of a handling every ledger failure ever will almost certainly be less than the cost of proof-of-work.
Part of my point is also that it's a gamble, which I find questionable, that Bitcoin will become "the blockchain" in the future, because it still has a political reality, and that political reality has involved plenty of forks. So, my point is, between the cost and the political instability, PoW doesn't sustain it's claim.
How do you decide whether a host is faulty unless there’s consensus on what constitutes non-faulty? And how do you reach this agreement in a distributed manner without distributed consensus?
You can’t switch away from a bad actor in a decentralized system unless you have a decentralized way to establish who’s a bad actor.
What you should do is have each community have its own internal currency, and then have global payments be powered by a federated system. Like the internet works.
Typically, that period is until the next consensus. In Ripple, the consensus eventually takes place but sometimes may take up to a minute. In Bitcoin it may take 30 minutes. You are never quite sure that everyone "phoned in", but presumably if the network participants announce themselves on the network then you can know when a supermajority has "phoned in". If they haven't - you've got a fork baby.
You can also get a fork if they phone in but start a second consensus somewhere else lol.
There are two things you have to trust, which I mention in the post.
1. That the node is not denying writes. (What's sometimes in blockchains called censorship.) If the node just didn't run your request, you'd be locked out with no evidence. It's not unsolveable, though - you could combat this by using a 3rd party proxy which records the traffic, and thus can back up your claim that you're being censored.
2. That the node won't just shut down. To combat this, you'd need a procedure for moving to a new hosting node. Not impossible either, but you'd need to decide for your userbase what kind of process would make them most comfortable. The blockchain state is there to be cloned at any time.
At this point the validators compare notes and gossip a proof that the node's been acting up. And then they need to elect another node, which requires... consensus!
Oh and the central node can also become unavailable and DDOSed, how are you going to add transactions to the ledger then?
If you have hundreds of known, diverse nodes distributed globally (run by very different institutions like Harvard, Bank of America, the Vatican, the Red Cross, the Gates Foundation, the House of Saud, etc. etc.) they can all watch each other, and the odds of them all going offline at the same time or cooperating to deny a specific user's transactions are very low.
This is essentially how CT-logs work, where we consider it sufficient to detect a falsely-issued certificate, even though we cannot prevent such issuance.
If it handles transactions faster, better, cheaper, and with less emissions, then so be it.
Unfortunately bitcoin's popularity/ubiquity makes it superior (for the time being) and hard to unseat. Other (decentralized) altcoins make really great improvements over bitcoin but never became (and perhaps never will become) as popular as bitcoin.