Ugh. He completely misunderstands what PoW (or PoS) are for. The entire point of PoW is deciding between two valid & correct blockchain states.
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.
What I do not understand is why we couldn't build this onto a web of trust + proof of stake. It may require some more state during resolution, and might even require falling back to automatic service denial if there is a severe network interruption (say in the event of nuclear war), but I can't figure out why we couldn't have miners just sign a growing dag of transactions and once a subset of the dag is accepted by 51% of the stake that network can prune the excess data (all the signatures). Work timestamps into the signature process and pin the keys used to sign the dag as only those belonging outside the current resolution. If a key is used to sign a transaction that conflicts with it's own "Verified & Locked" signature then it's coins are burned, including for it's own transaction. 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.
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.
> I can't figure out why we couldn't have miners just sign a growing dag of transactions and once a subset of the dag is accepted by 51% of the stake that network can prune the excess data (all the signatures)
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?
Short of an adversary having greater than 50% of the coins I don’t really see how a sylbi attack is relevant.
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.
> What I do not understand is why we couldn't build this onto a web of trust + proof of stake.
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).
Hey said this about proof of work.. is it wrong? It sounded good to me, but I never got into blockchain stuff.
>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.
> 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.
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.
I think the point is that, hypothetically, some non-financial systems don't require ordering or conflict resolution and thus such systems don't need PoW.
Actually I appreciate the defense, but that's not what I'm claiming. I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain. Single nodes don't have the problems of uncertain ordering or conflict resolution because they can provide strict consensus.
> I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain.
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.
A proper hash function provides a lot more than a timestamp. A service with a B-tree (or other traditional database) can rewrite history. Even if have a copy of the db, it's difficult to prove that your version is the service rewrote their version.
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,
> A proper hash function provides a lot more than a timestamp. A service [...] can rewrite history.
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.
> 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.
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.
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.
How do you "switch" from a global shared ledger that everyone uses to a shared ledger that no one uses? I mean, you an, you can fork Bitcoin and start your own, but what does that get you? No one else will use your coin. There will be no market for it and it will have no value.
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 .
I think you're right that handling catastrophic failure is the key question for a hosted ledger. You have to find a way for the network to agree on who will rehydrate the balances, so to speak, into a replacement host, and you need to do it quickly. The whole network has to agree on 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.
the post is talking about using blockchains as a systems tool to build a distributed ledger, not how to create a new cool crypto currency that will be more 31337 than bitcoin.
> 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
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.
There is value in a blockchain beyond a ledger of currency, and some of that value still remains when using a centralized service.
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.
Where does the blockchain come in? As long as you have a signature from the central authority over two conflicting transactions, you can prove it has defrauded you.
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.
The catch is at the end: "There are some downsides to losing decentralized consensus. A ledger-backed service could manipulate the order in which it handles requests, or reject some requests altogether, and clients would have a hard time proving it." Calling that a "secure ledger" is kind of a stretch.
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.
Security can be extremely simple and efficient when you just have to trust a third party. The author is describing Linked Timestamping [1], which has been detailed since the early 90's.
Removing the need for trust is what takes all the energy.
Well, no, I'm not describing Linked Timestamping (hereafter LT), because LT is a system for creating trustable timestamps, and I'm talking about a system for auditing the state and operation of a service. Hash/block chains are common and going to get more common. LT, Git, Certificate Transparency, Bitcoin, and now what I'm describing.
And, further, I'm not suggesting you trust a third party, but if you feel I am, please point specifically at where.
It's fun to see this here after I've just spent some of the afternoon 'pitching' 'Centralised Ledger Technology'. Single source of truth, verifiable, secure, permissioned, efficient, scalable, the advertising copy writes itself (or would if you needed it to, rather than just taking any of the copy from hyperledger or simlar and fixing it up a bit). Any of the people selling private block chain solutions will generally tell you that there needs to be a strong political actor within a 'business network' that can insist on the use of the distributed ledger. The truth of course is that Mr Car Loader or Mr Fruit Picker who is lent on to run a node on the distributed ledger really couldn't care less about whether they are verifying other peoples transactions or not, they'd be just as happy with a web site that they fill the details in, or a signed email system. Indeed, they might ask - why should I be expected to run computation to secure bits of the value chain I never see, I just care about confirming what I've received and what I've passed on, and I can do that by digitally signing a transfer note.
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.
So if there is no proof of work how do you avoid forks? The author says something about splits being detectable but that doesn't really help us decide on which side of the split is correct.
You don't use decentralized consensus in this model. It's a single node that's maintaining the blockchain state. Monitors actively watch the blockchain to make sure the node doesn't deviate from the code contract. If there is a fork in the blockchain, that'd be because the single node created that fork in an attempt to create two versions of the state-- that's a break in the contract and it would be viewed as a fatal corruption event.
Semi-trusted. You have total transparency into whether the node is following the rules of the code contract. The node could not, for instance, change values in the DB without doing so via the contract, and that would be logged for all to see. Very important for something like a key server.
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.
Sure it can - it can just start reporting different things to different validators.
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?
Choosing another node won't involve consensus in the way that consensus is described in distributed networks. You'd handle that ideally by a prior agreement -- eg, "if this node corrupts, it's going to go into arbitration via a trusted third party, who will then decide who will resume operating the network."
IMO this new design is "fine w/me" in the way that ethereum is "fine w/me." If people want a not-so-decentralized cryptocoin that's not-so-trustless, then so be it.
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.
If I can make a suggestion, you might want to look into the structure of the blockchain networks that use a network of known super-nodes to watch and verify each other.
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 called delegated byzantine fault tolerance, and what blockchains like NEO and ARK use this, or a variation of it to provide consensus. Token holders basically "elect" the super nodes, and if any begin to act untrustworthy they are "voted out." I'm a fan of this consensus styles because blockchains become semi centralized over time. Maybe not in the technical full validating node way, but certainly politically centralized.
Yes, if you can handle forks as long as you can detect them, centralized consensus is a decent solution with much lower costs that PoW.
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.
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.
In the specific case of currency, practical double spends are a real issue.
'Merging' the state after a double spend requires either forcing the double spender to pony-up, or taking back money from those who received it without being aware of any wrongdoing. That is, unless you are fine with people printing their own currency.
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.
Everybody prints their own currency all the time. Currency is just promises made. Double spend is when you duplicate somebody else's promises that you are holding as an asset.
How are you going to merge if you have different spends on the forks you're trying to merge? It's not a matter of whether or not you care about ordering. It's a matter of one branch's spend being invalidated by the spend in the other branch.
If the answer is to stop caring about double spend, how do you anticipate that working?
Yes, stop caring about double spend as long as it happens in long term forks. After some point, two different forks become two different communities. Similarly when you restrict gene flow between species which are physically separated, they often can't interbreed anymore. It's called allopatric speciation. There is evidence it happens in nature.
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.
Well, if there is a period that your transaction might get reversed, then the seller can't send you the stuff. Or, maybe you need a reputation system for buyers and sellers and so on (what eBay does) along with chargeback systems figuring out whether to let the transaction be reversed.
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.
I would agree that many use cases that imply a distributed ledger, do not need a proof-of-work.
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.
The author apparently doesn't understand sh&t about the computer science
background of blockchain, since he constantly throws "decentralized consensus"
term to mean as a wrong thing. Blockchain does not do that (consensus problem,
as stated by computer science, requires the protocol to actually terminate
with an output; then, Lamport et al. in their original paper over thirty years
ago proved an impossibility theorem that blockchain would break if it was
solving the stated consensus problem).
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.
>it would be profitable for Bitcoin miners to burn through over 24 terawatt-hours of electricity annually
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.
>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
Straw man. Blockchain consensus algorithms don't only use proof of work. We have proof of stake, delegated proof of stake like LISK, proof of Correctness like Ripple (my personal favorite), and so on.
No need for a wasteful arms race just to elect a leader who can be DDOSed.
A very quick look at ripple leads to my following interpretation.
"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.
I absolutely do respond to alternatives to proof of work in my post, thank you very much! And I agree that they may be valuable, but I'm skeptical, and you can reread my post to see why. And, by the by, the DDOS argument is a strawman, because we already survive DDOSes in services every day.
You're right, you do mention proof of stake and dismiss it quickly. There is also delegated proof of stake, where validators can elect a leader without needing a proof of work arms race.
But you should really look at Ripple's consensus and study it:
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)
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.