The Fat Controller of the Lightning Network
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.
Some interesting thoughts but it seems to me that a warning or checkbox saying, "this channel and funds available to it may be used for routing payments on the network" would allay all your fears.
ReplyDeleteI'm also not sure that's necessary. A user of LN necessarily gives her consent (otherwise why wouldn't they simply set up private bilateral payment channels not connected to LN?). Instead, they purposefully make their channels and funds available for routing; their nodes advertise that availability(!) and they can even charge a fee! There are no property rights issues when a person decides to do that.
I also think "coins in the channel are effectively lent to the Lightning network, which can do whatever it likes with them" is a gross exaggeration. It ignores the preexisting relationships with both the preceding and forward nodes. Changing the balances of preexisting channels is a far stretch from "can do whatever it likes with them"! Similarly, the money laundering concern is overblown (or no worse than a normal person's existing web of financial relationships). I don't see how you could possibly be held accountable if your channels with Iza Kaminska and Chris Cook are used by one of Chris's dodgy friends to launder money.
And how do you reach the conclusion that, "payment routes through a network are centrally controlled"? Who in your mind chooses the route for a payment? (I have not seen a correction to your previous article; has your opinion not changed at all, despite the feedback?)
A warning or checkbox would be a good idea. People notoriously don't read the small print when entering into legal agreements. Compensation awarded for mis-selling often arise from marketing information not making the legal implications clear. Lightning is steering dangerously close to this in my view.
DeleteI don't agree with you that the relationships with forward and backward nodes limit Lightning's use of funds. If it did, then every time node relationships change, nodes would need new legal agreements. This is unworkable. Much more likely that there would be a blanket agreement that Lightning can use funds in channels to make payments in whatever way it chooses. That would ensure that a change in node relationships did not mean new legal agreements all over the network.
You absolutely can be held accountable for funds laundered through your channels, whether or not you know about it. That's why KYC rules for banks now extend to KYCC (know your customer's customer). The banks used "I didn't know their customer was dodgy" as an excuse for facilitating money laundering. Governments have now cracked down on this. Not knowing is no defence.
I would also point out that creating a system whose design encourages money laundering is just asking for government crack-down.
The sender's ability to choose the route depends on there being an up-to-date and accurate network map. Who do you think maintains this?
I am not going to "correct" my previous article. The tech design has moved on precisely because the devs are trying to solve the problems I described. I was behind the curve technically, but the pathfinding problem hasn't gone away. The tech design now is legally suspect for the reasons I describe in this post. It is laughable to create a legal agreement that requires people to commit their funds without their knowledge to payments about which they know nothing, while pretending this isn't lending. Let's have some honesty, please.
> The sender's ability to choose the route depends on there being an up-to-date and accurate network map. Who do you think maintains this?
DeleteAs a LN user, *you* build and maintain your own network map i.e. each person's node constructs and maintains a network map based on each other node broadcasting the availability of its channels and relaying the broadcasts of others. I don't think that constitutes a centralised figure or Fat Controller. Different nodes may well have different views of the network.
> I am not going to "correct" my previous article. The tech design has moved on precisely because the devs are trying to solve the problems I described.
The tech design moved on _before_ you wrote the article. You don't acknowledge that in your second article either (despite starting so promisingly with, "To be sure, I had made an incorrect assumption about Lightning.") It's your call, of course, but readers are likely to accept and run with the few bits of your article that are wrong.
> I don't agree with you that the relationships with forward and backward nodes limit Lightning's use of funds. If it did, then every time node relationships change, nodes would need new legal agreements.
The point being that no one can force your node to open a new channel with a hitherto unrelated node. They can only utilise the preexisting channels you have open (and advertise). In my view, any "legal agreement" you have with a channel partner necessarily provides (at the outset) that any channel partner may, at its option, commit funds to you (in its channel with you), plus an amount to cover fees (if any), and require you to commit an equal amount (plus or minus fees) to any one of your other (specified, preexisting) channel partners (the forward node), and pass on a message to that node. I think that makes for a perfectly valid agreement between you and your channel partner. In that sense, a multi-hop transaction is merely execution of a chain of preexisting agreements. Nothing unusual there.
Re money laundering: points taken. It's an interesting problem (potentially -- but I don't think it can or should hold up development).
It's clear that the coercive element in Lightning goes far beyond simple mapping. I am standing by my use of the term Fat Controller.
DeleteI'm not going to "correct" my previous piece because I am not discussing the tech, either in that piece or this one. The whole point of my piece is that Lightning's pathfinding problem is not simply a technical issue to be solved by some clever code. By trying to reduce it to that, you are missing the real issue, which is that the original functional design is unworkable. If I were doing a design review, I would demand that the original whitepaper be rewritten. Tech should not be expected to compensate for fundamental functional design flaws. Devs are getting WAY too big for their boots.
You do not have any legal agreement with nodes 10 steps removed. I pointed that out in my original piece. You don't have any right to construct a path that coerces remote nodes with which you have no agreement to forward your payment without their consent.
"You don't have any right to construct a path that coerces remote nodes with which you have no agreement to forward your payment without their consent"
DeleteFrances Coppola: You do understand LN works based on unresolved smart contracts, right? These are like post dated checks. Unless something has changed the idea was that before that future date if problems arose one could simply post to the actual block chain at a greater fee. If a node acknowledges receipt without intent to send, either it gets there first via another path, wasting their computation time (no profit), or stalls and gets posted on the blockchain, which then likely causes other nodes to severe ties where it stalled.
These are essentially dynamic sidechains, and in contract terms more like the bid submittal process.
Hi Stephen,
DeleteI do now! I have been talking to Lightning devs. It seems my first post was broadly correct: senders may choose the path, but they can't force nodes to participate. If nodes don't participate, the payment fails and the sender must choose another path.
Mapping and testing the route up front eliminates the recursion and "wandering" problems that I identified in my first post, but it doesn't eliminate the "no viable path" problem. Clearly the fallback position must be for the payment to go via the blockchain if no path can be found, but you are the only person who has said that this could be automated. I am wondering if the Lightning development community is a tad divided on this, or whether they simply haven't yet taken on board the fact that they need to plan for such exceptions.
There is potentially another issue too, which is rather more serious. If the effect of nodes declining to participate results in multiple attempts to make payments and payment routes becoming longer and more complex, then I would expect network performance to be degraded, possibly seriously so. I discussed this at some length in the first post, with a somewhat playful example to help people understand. Again, I have not so far seen any constructive discussion about this. Some people suggested that network performance could improve as the number of channels increases. I don't necessarily disagree, though this must depend on transaction volumes and channel choices as well as number of channels, but it doesn't address my point. Do you have a view on this?
The thesis in this post, that the network is essentially coercing people into committing their funds without their knowledge, is wrong. But it was based on criticisms of my previous post (link at the head of this post) from people who claimed to be knowledgeable about Lightning but actually did not understand the functionality - as indeed some people commenting on this post don't, see dominion's comment above. What I've learned from that is that not many people really know how Lightning works. Understanding the technology is not the same as understanding the functionality.
That said, even without the coercive element, the nodes are still lending. I don't think your analogy of post-dated cheques (note the spelling, I am British!) is accurate. Post-dated cheques don't show in a bank balance. They can't even be submitted to the bank for clearing. In contrast, intermediate payments encumber a channel balance. The balance includes the unclaimed payment, but it can't be spent. I think a better analogy is cheque processing. The ledger balance on the account is updated with the amount of the cheque as soon as it is presented to the bank, but the cleared balance - the amount you can spend - is not updated until payment is received from the counterparty's bank.
I don't think you can equate making a payment with submitting a bid. The first involves committing funds. The second does not. The key point of THIS post is that this distinction is crucial. Committing funds involves transferring property rights, even if only on a temporary basis. Encumbering part or all of the channel balance until the final payment is made means that the owner is temporarily deprived of their right to enjoy their property. That may (or may not) be a very short period of time, but it is not zero. Legally, they have lent the coins. The smart contract must recognise this.
> You do not have any legal agreement with nodes 10 steps removed. I pointed that out in my original piece. You don't have any right to construct a path that coerces remote nodes with which you have no agreement to forward your payment without their consent.
DeleteWhy would you need a legal agreement with a node 10 steps removed? You do not need node 10's consent; only node 9 needs node 10's consent. You need to have an agreement with node 1 (your channel partner), who has an agreement with node 2 (their channel partner), who has an agreement with node 3, and so on. If node 10 inexplicably denies the request from its preexisting channel partner node 9 (which I think would require modified software), then of course the path fails and a new route must be found.
I'm afraid the sender does need agreement from every single one of the participating nodes in order to proceed with a multi-hop payment. That is what I was told by a Lightning dev yesterday.
DeleteIt is blindingly obvious why remote nodes require a legal agreement with the sender, and I explained it in the post. The design as it stands is a money launderer's paradise. Intermediate nodes are blindly forwarding money whose source they don't know to a destination they don't know. If the design were coercive as I discussed in this post, then they could at least argue they had no choice but to forward the payment. But as they can choose whether or not to process the payment, they would be held legally responsible if the funds they forwarded turned out to be fraudulent. Therefore, they need a legal agreement that the sender bears all responsibility in the event of a lawsuit. "I didn't know the money was dirty" is not a defence.
There is a second reason why remote nodes need a legal agreement with the sender, and that is the fact that they are committing funds which will be encumbered until the final payment is made. They can't make a reasonable decision whether or not to commit their funds unless they know who the sender is, the recipient is and the length of the chain. Blinding the intermediate nodes destroys their ability to make a reasoned choice. It might as well be coercion.
Many of your concerns seem to apply to TOR (The Onion Router) in a similar fashion.
ReplyDeleteWho in their right mind would set up their router as a node in a network allowing connections to peers not of your choosing, and without knowledge of the content in the data packets - which could include illegal content!
Surely no one would do this and it would invite government crackdown instantaneously?
Empirically, those concerns didn't seem to pan out as expected, with many bridging and exit nodes across the world run mostly by people who believe in privacy and censorship resistance and no government able to stop the network.
Is this a fair analogy with the money laundering concerns being in the same vein as the trafficking of illegal drug trades (and worse...) - which didn't stop the network? And one could argue that being a node in the Lightning Network is even less altruistic than participating in the Tor network, as at least the LN nodes can collect fees for their participation and benefit from instantaneous microtransaction capabilities?
It is indeed analogous. It is also somewhat curious that Tor is allowed. Technically it can be banned, using the same processes as used for say taking down child porn hosts (as there is a global consensus, anyone doing it openly gets shut down).
DeleteIt seems that so far the powers that be in enough Western countries have decided that a little bit of child porn and drug trading (a drop in the ocean compared to street dealing anyway) is worth paying for the positive uses of Tor as a weapon against censorship-prone regimes.
It's not obvious that they'd be as tolerant of underground payment systems... If LN takes off it's likely there will quickly be 2 of them: because the channels involves trust and trust is transitive, it will only take a few major players within the KYC-sphere for transitively everybody in the network being taken in, excluding dark net use, which is still the main use case for cryptocurrencies.
Next step is a second LN network (no technical reason to have a single instance) that is the opposite: where nodes get kicked out if they are known to collaborate with the clear world. But then the dark-only LN is an easy thing to ban (make it illegal for clear shops to interact with it, possibly criminalise use by punters).
It is interesting Coppola keep challenging the Bitcoin phenomenon on economic and legal dimensions. Some remarks:
ReplyDelete1. "and even though the risk of not getting the money back is small, it is not zero" - can the author point to the source in support of this statement? It is my understanding that risk is zero, by way of how the multi-signature transactions are used in the LN. Either the bitcoins you pledged into the LN channel are yours or the recipient's and the transfer happens in an atomic (indivisible) transaction, regardless of the number of hops between. And if you don't transfer funds over the LN, you can always get your bitcoins back just by closing the channel.
2. The argument that a participant of the LN is helping money laundering can be extended to : all network routers in the world wide internet transfer child pornography too, routers are indifferent to the purpose of the packets they transfer. I've never heard someone claiming routers, that have similar roles as LN's nodes, must be held responsible for the content they relay.
I agree with point #1. However, point #2 has a small problem. Internet routers & TCP were not designed to intentionally obfuscate source and destination. Participating in a network of barter transactions which knowingly obfuscates the true parties in a transaction for profit is the definition of money laundering. I understand the feature's purpose (ala net neutrality), imho the transaction should deobfuscate at the point of resolution (I haven't checked this part yet, will look into if it does).
DeleteTering Nering,
DeleteRisk is never zero. It is extremely foolish to assume that it is. Developers are not gods. They do not know everything. If developers assume there is no risk, they will not defend against that risk, and that can be disastrous. They should defend against risks they don't expect ever to happen, simply because in some state of the world they could happen. Financial systems should be built to defend against all identifiable risks, however unlikely they appear. I speak as a former financial systems designer and developer.
On your other point: I agree that network routers are "blind" to the content they transfer. But Lightning goes beyond that. It deliberately conceals participants from other participants. That amounts to designing money laundering facilities into the system.
> "Risk is never zero."
DeleteThere's no counterparty risk in the usual sense though, because the protocol guarantees atomicity of transfers i.e. the protocol only allows two outcomes, either the transaction (and all adjustments/whatever inbetween) happens, or nothing happens. There will never be a situation where one or more intermediary nodes are sitting on pending balances or similar, waiting for the ultimate recipient to receive payment, for example.
There is always the risk that the protocol itself is broken/has bugs, of course.
I think it is good to stress the point that there is, at this point anyway, no formal distinction between fat nodes/hubs and 'normal' or user nodes. A hub is just a node as any other node, but with larger funding and lots of connections. So hubs are emergent: they can come into existence, even maybe for a few days or hours, and then shrink again to lesser nodes, or completely disappear. There's a gliding scale between the smallest node and the biggest hub. Any size in between in possible. The market will dictate the optimal distribution of node sizes.
ReplyDeleteMaybe in the future LN software _will_ make the formal distinction between different kind of nodes (a bit like the current Master Nodes of Dash). Interesting to see how that will play out.
Taking someone else's coins without their agreement, even momentarily, is theft.
ReplyDeleteNo it isn't. Theft is:
"Dishonest appropriation with the intention to permanently deprive property belonging to another"
Momentarily is not permanent.
Taking someone's car without their agreement, even temporarily, is theft. That is how it is regarded in legal systems throughout the world. Why do you think coins should be different from cars?
DeleteNo, that's why specific legislation was passed to cover temporary appropriation of vehicles. (Sec 178 Road Traffic Act 1988). It's commonly called "Taking without Consent". because the Theft law can't be applied to a taking a vehicle when there is only an intention to Joy Ride and later dump the vehicle.
DeleteTheft of a motor vehicle (under the Theft Act 1968) is usually charged for cases where the vehicle is stolen for resale or export, ie. where there is an intention to permanently deprive.