The geeks to whom my post on probability was addressed responded exactly as I expected. "You don't understand the tech", they said. And they went on about network routing protocols and Dijkstra's algorithm. Someone even sent me a spec for an onion routing protocol for the Lightning network. I read it and sighed. They had completely missed the point. To be sure, I had made an incorrect assumption about Lightning. I assumed that Lightning devs respected property rights. It turns out that they don't even know what property rights are, let alone respect them. They see Lightning's pathfinding problem as entirely a technical matter. If it were, then solving it would simply involve developing algorithms to oversee the network and find the most efficient payment paths. I did mention this
Frances Coppola considers the following as important: banks, Bitcoin, law, lending, payments, property, trust
This could be interesting, too:
run75441 writes Sister Survivors
Mike Norman writes Brian Terrell — Two Interrogations, Gina Haspel and Adolf Eichmann
Dan Crawford writes A New Pareto Liberal Paradox (reposted from 2004)
Frances Coppola writes Arithmetic for Austrians
The geeks to whom my post on probability was addressed responded exactly as I expected. "You don't understand the tech", they said. And they went on about network routing protocols and Dijkstra's algorithm. Someone even sent me a spec for an onion routing protocol for the Lightning network. I read it and sighed. They had completely missed the point.
To be sure, I had made an incorrect assumption about Lightning. I assumed that Lightning devs respected property rights. It turns out that they don't even know what property rights are, let alone respect them. They see Lightning's pathfinding problem as entirely a technical matter. If it were, then solving it would simply involve developing algorithms to oversee the network and find the most efficient payment paths. I did mention this possibility in my post, in relation to recursive payment paths (emphasis not in original):
Payment routes could become very long and very complex without anyone knowing. They could even become recursive. Because this is a DAG not a tree structure, it is entirely possible that the same person could be asked to make a payment more than once in the same chain, by two different participants. Murch says this isn't possible, but unless there is some kind of Fat Controller preventing duplicate participation in payment chains, he is wrong.Creating a Fat Controller is exactly what the Lightning devs are doing. They don't call it the Fat Controller of course, though I really wish they would. It would be way more descriptive than "onion routing protocol". And more fun. Just picture an onion in a top hat and tails....
Enough of this levity. There is a serious point here. The devs' inability to see beyond the tech to the humans that will use this system creates an enormous problem. It fundamentally undermines the whole purpose of Bitcoin. I've said before that they are effectively creating a banking system. Their decision to introduce a Fat Controller reinforces my point.
The heart of the matter is property rights. In a traditional banking system, depositors lend their money to the bank. Lending is a temporary transfer of property rights to the borrower. So the bank can do whatever it likes with the money, and the depositor has no guarantee that they will ever get their money back. The interest rate on the deposit is, in part, recompense for the risk that the depositor takes in transferring their property to the bank.
Deposit insurance significantly reduces the risk of loss, but does not eliminate it. This is true even if the deposit insurance scheme is pre-funded by means of a levy on banks. No deposit insurance scheme in the world has enough funds to pay a simultaneous insurance claim from every bank depositor. Deposit insurance is fractionally reserved, just like the banks whose depositors it supports. The "insurer of last resort" is the government. And if the government can't pay, depositors lose their money.
Bitcoin was designed to eliminate this risk. Coins in wallets are not like bank deposits. Even if they are held on an exchange, they remain the property of their owners. And people can only spend coins they own. This, of course, is why Bitcoin is illiquid. Liquidity is always scarce and expensive when there is no lending.
Inevitably, Bitcoin's principle of pre-funding and escrow has been watered down by exchanges that offer marginal lending facilities. Banks always pop up wherever opportunities to make money from lending appear. But exchanges aren't part of Bitcoin's payment protocol. They are users of it.
Lightning is designed to sit "on top" of Bitcoin as a second layer payment network, enabling large numbers of small payments to be made without clogging up the main Bitcoin blockchain. It is touted as providing a solution to Bitcoin's severe transactional liquidity problems. Thus, it should be regarded as an extension of Bitcoin's payment protocol, rather than a user of it.
In keeping with Bitcoin's principle of escrow, Lightning's bilateral payment channels are pre-funded. The agreement between the two parties is governed by a smart contract which in effect says that the coins placed in the channel belong to both parties. It's like the "pot" my brother-in-law keeps on his mantelpiece. He and his wife both put cash in the pot, and either of them can spend it. Although they fund the pot individually, they regard the money as belonging to both of them. In Lightning, this "what's mine is yours, and what's yours is mine" principle is enshrined in a legal agreement - the smart contract.
A bilateral agreement to share property does not entitle anyone else to borrow that property. Yet borrowing that property is exactly what the Fat Controller will do. Furthermore, it will do it without the consent or even the knowledge of the owners of that property. The spec for the "onion routing protocol" says that when it identifies a payment path, it will override the keys of the nodes on that path and force those nodes to transmit the payment.
Taking someone else's coins without their agreement, even momentarily, is theft. So the smart contract for the bilateral channels will need to include a clause that permits the Fat Controller to use coins in the channels for whatever purpose it wishes without specific consent from their owners. This, I'm afraid, is a lending agreement. The coins in the channel are effectively lent to the Lightning network, which can do whatever it likes with them. The payment channels have become deposits - and even though the risk of not getting the money back is small, it is not zero. In trying to solve Lightning's pathfinding problem, the devs have turned it into a bank.
To be fair, this was inevitable. Banks operate in the way that they do for very good reasons. Lending creates liquidity. If no-one wants to lend - and let's face it, lending is the last thing most Bitcoiners want to do - the payments system seizes up. So depositors have to be forced to lend. The difference between a bank and Lightning is that banks reward depositors for lending to them, either by paying interest or by providing services. Lightning does neither, presumably because the devs haven't yet figured out that no-one will want to put any money into Lightning payment channels if they think it can be hijacked at any moment to pay other people's bills, unless Lightning gives them a really good reason to do so, such as paying them.
In line with Bitcoin's spirit of decentralization and censorship resistance, we employ an onion routing scheme within the Lightning protocol to prevent the ability of participants on the network to easily censor payments, as the participants are not aware of the final destination of any given payment.Excuse me, but in what parallel universe is refusing to allow an algorithm to use my money to pay for a total stranger's pizza "censorship"?
Even more worryingly, they go to great lengths to ensure that people don't know what their coins are being used for:
Additionally, by encoding payment routes within a mix-net like packet, we are able to achieve the following security and privacy features:This looks like a money launderer's paradise to me. Though why on earth anyone would put coins into a payment channel if they knew they could be used without their knowledge to launder money is beyond me.
- Participants in a route don't know their exact position within the route
- Participants within a route don't know the source of the payment, nor the ultimate destination of the payment
- Participants within a route aren't aware exactly how many other participants were involved in the payment route
- Each new payment route is computationally indistinguishable from any other payment route
A Fat Controller is essential for networks such as railways or roads, where you don't want things bumping into each other. And network maps are essential for pathfinding, as anyone who has tried to find their way round London without a map knows to their cost. But mapping a system and controlling traffic on it requires centralisation. And when payment routes through a network are centrally controlled, people have to be willing to lend their money without knowing the purpose to which it will be put. That requires trust - the very thing that Bitcoin was trying to render unnecessary.
Compromising property rights and expecting people to trust a centralised Fat Controller may make Lightning work efficiently as a payments protocol. But it painfully highlights, once again, the fundamental conflict that lies at the heart of Bitcoin.
Fat Controller image from YouTube.