The Lightning Not-Work

Executive summary

The Lightning Network is the invention that, according to Bitcoin fans, will turn the miserable joke that is their wannabe payment system into a Visa killer. But it is a technological fraud: it cannot work -- and its developers know that.

Essential overview of the LN

If you already know how the LN is supposed to work, you may skip this section.

The LN is supposed to consist of nodes connected by (payment) channels in an ad-hoc network, with no predefined plan and no central authority. Anyone can create any number of nodes and then open channels from them to any other nodes. An LN node is an instance of a program that runs on a user's computer and understands the LN protocol. It keeps the node's LN wallet, a file that records the channels that connect that node to the rest of the network, and some other information for each of those channels.

The LN is usually assumed to be used for BTC, but in fact it could be used with almost any cryptocurrency, just as well or better. For convenience of exposition, we will assume BTC from now on.

An LN channel is basically a transaction of a certain kind recorded on the BTC blockchain, the channel's opening transaction. Let Alice and Bob be the two nodes on each side of the channel. The opening transaction has an unspent output (UTXO) with a certain amount of BTC, the channel's funding, that can be spent only by a channel closing transaction that is signed by both Alice and Bob.

Suppose the funding of the channel is 20 BTC, that was provided entirely by Alice; and Alice wants to send a payment of 3 BTC to Bob. She creates a closing transaction that takes that 20 BTC UTXO and sends 3 BTC to Bob's blockchain address and 17 BTC to her own address. She signs the transaction and sends it to Bob, e. g. by email, cellphone message, or by some special-purpose messaging protocol. If Bob wants the BTC immediately, he just countersigns that transaction and sends it to the miners. That would close the channel.

But that would be just a convoluted way to send the 3 BTC through the "raw" BTC network. The first key idea of the LN is that Bob does not send that transaction to the miners, but only saves it in his LN wallet; and Alice does the same. Then, if Alice wants to send another payment of 5 BTC to Bob, she creates another closing transaction that splits that same 20 BTC UTXO into 3+5 = 8 BTC sent to Bob's address and 20-8 = 12 BTC sent to her address. As before, she signs this transaction and sends it to Bob. She can do this immediately after sending the first payment, without waiting for any confirmation on the blockchain. Both delete the previous transaction from their wallets and store the new one instead.

Similarly, if at this point Bob wants to send 2 BTC back to Alice, he prepares a closing transaction that splits the same 10 BTC into 8-2 = 6 BTC to himself and 20-6 = 14 BTC to Alice. Bob signs this transaction and emails it to Alice. Again, he does not have to wait for any blockchain confirmation. This way, Alice and Bob can send infinitely many payments to each other, at very little cost per payment, as quickly as they can build, send, verify, and sign those transactions. When the most recent closing transaction, with both signatures, is finally sent to the miners, the original 20 BTC funding is split into the total net payment that Alice sent to Bob, and the remainder that becomes availabe to Alice. The state of the channel, at any moment is a pair of BTC amounts: the maxmimum that Alice can send to Bob, and the maximum that Bob can send to Alice, in a single transaction at that moment. Thus, in the example above, the channel state starts at (Alice:20, Bob:0). After each of the three payments above, it becomes (Alice:17, Bob:3), (Alice:12, Bob:8), and (Alice:14, Bob:6), respectively. We say that these two amounts are the (current) capacities of the channel in the drirection from Alice to Bob and from Bob to Alice, respectively. Obviously, the sum of these two numbers will always be equal to the channel's funding. One important point to note are that the sequence of payments using that channel must be such that, at any time, none of those two numbers can be negative. Also, at any moment, the net total payment that either user has sent through the channel cannot exceed his or her contribution to the initial funding. Another important point is that the whole initial funding remains locked -- so that it cannot be used or moved in any way by either party -- until the channel is closed.

That is basically how the LN works for two nodes that are connected by a channel. But the need to lock up funding means that an user cannot create a separate channel to each other user. The typical user is expected to create only a few channels, maybe just one. Here comes in the second key LN idea: multihop payments.

Suppose that Alice and Zeke are connected to the LN, but not to each other. To send a 2 BTC payment to Zeke, Alice must choose a payment path, one or more relay nodes -- say, Bob, Chloe, and Dave -- connected by channels into a chain: Alice to Bob, Bob to Chloe, Chloe to Dave, and Dave to Zeke. Alice then negotiates with those nodes a simultaneous set of 2 BTC payments through those channels. Alice will then lose 2 BTC, Zeke will gain 2 BTC, and each relay node will get 2 BTC from one channel and send 2 BTC through another channel.

The negotiation of a multihop payment uses some cryptographic magic to ensure that the operation is "atomic" -- that is, either all those channel payments happen (and the payment from Alice to Zeke succeeds), or none of them happens (the payment fails). The negotiation is not trivial, but a multihop LN payment can still be much faster than a payment on the BTC blockchain.

Technical problems

Existence of a payment route

In a multihop payment of N BTC, the chosen payment path must be viable, meaning that the relay nodes must all be running and willing to carry that payment, and the current capacity of each channel, in the relevant direction, must be at least N BTC. In the example above, Alice must be able to send 2 BTC to Bob, and ditto for Bob to Chloe, Chloe to Dave, and Dave to Zeke.

A major problem of the LN concept is that there may not be a viable payment route between the sending node and the receiving node. That is obviously the case if, for example, Alice wants to sent 10 BTC to Zeke, but all her channels currently have less than 10 BTC of capacity in the outbound direction. The attempt will fail also if Zeke does not have a channel with at least 10 BTC of capacity in the incoming direction. More generally, it may fail if every path in the network from Alice to Zeke includes some channel whose current capacity, in the path's direction, is less than 10 BTC. That would happen, for example, if Alice's neighbors are Bob, Bill, and Bruce, and every one of their outgoing channels (other than to Alice) have less than 10 BTC of capacity.

Alice could be able to remedy those situations to some extent by sending payments to herself along closed paths, that have the effect of shuffling the capacity among her outgoing channels. This trick may let her obtain the necessary capacity in one of her channels. Forexample, if she has 7 BTC of capacity in a channel to Mike, and 5 BTC in a channel to Nike, she could send 3 BTC to herself through a path Alice -> Nike -> ... -> Mike -> Alice. That would change the capacities of those two channels to 7+3 = 10 and 5-3 = 2 BTC, respectively. Zeke could use the same methods to shuffle the incoming capacity of his channels. Note however that such shuffling cannot increase the capacity of any channel above its initial funding. Note also that the shuffling path itself must be viable, and thus may not exist.

Alternatively, the two parties may agree to split the payment into parcels, each sent through a different path. However, the funding and current state of the channels obviously puts a limit on how much Alice can send to Zeke through the LN. In the language of graph throry, the maximum amount that Alice can send to Zeke, even in multiple parcels, is the minimum total outgoing capacity of any cut of the network that separates Alice from Zeke. The latter is the current capacity of the network from Alice to Zeke.

To make a payment above that limit, she would have to obtain additional BTC and open a new channel with that funding (possibly closing some of her current channels and adding their balances to the funding of the new one). That will require at least one transaction on the blockchain, with its inherent cost and delay. If the network's topology is "random" in the proper sense, a bottleneck that prevents a payment, either in single or multiple parcels, is more likely to be near Alice or near Zeke. The probability of the payment being impossible, and the expected distance from the nodes to the bottleneck, obviously increases with the amount to be sent.

Finding a payment route

The most obvious unsolved problem with the LN concept is that there seems to be no practical way to find a viable payment path between two arbitrary nodes, like Alice and Zeke. The opening transactions can be crafted so as to let anyone obtain the topology of the network -- the current set of nodes and channels -- by scanning the blockchain. With that information, one can find a potential path between any two given nodes, or even all such paths. However, there is no practical way to find a path that is viable. That's because the necessary information -- the current state of each channel -- is known to only the two nodes connected by it.

This problem is easy to solve if there is a viable path with one hop or two hops -- that is, if Alice is a neighbor of Zeke in the LN network, or if the two have a common neighbor that can be used as a relay. In the second case, Alice and Zeke would identify the common neighbors by comparing their channel lists, excluding those with insufficient capacity. Then they would contact each of those nodes, until finding one that is willing to relay their payment.

If there is no viable one- or two-channel path, however, Alice and/or Zeke may have to try many potential paths in the network, inquiring the corresponding relay nodes about their willingness and ability to carry the payment. If the network is mostly random, and each node has only a few channels, the path will often have many hops. For example, if the network has a million nodes, each with an average of three channels, the shortest potential path (viable or not) between two nodes chosen at random is expected to have about 20 hops; and there may be an astronomical number of potential paths. Even if each negotiation is fast enough, the search may take a long time -- especially if there is no viable path.

Broadcasting requests does not work A solution that was proposed for this problem was for Alice to broadcast to the network a message "I am Alice and I need a viable path to Zeke for 10 BTC". She would send this request to those of her neighbors, and they would forward it to their neighbors, and so on. (The internet, and therefore the LN, does not support true broadcasting, where a single transmission reaches all receivers simultaneously -- as done by radio stations or GPS satellites.)

The broadcast would use only channels with at least 10 BTC of capacity, and nodes that are able and willing to realy the payment. Each node would append its identifier to the message before forwarding it. Once Zeke receives the message, he can notify Alice, and the two can negotiate the payment with the nodes listed in that message. Alice may also send out a higher-priority broadcast telling nodes to stop propagating the first one.

However, with this solution, every payment that requires more than two hops may cause a large number of nodes to receive and forward the corresponding message. If the network has a million nodes, each of them doing one payment per day on average, then each node may have to process hundreds of thousands of such messages per day -- even if, in the end, each node may relay only a couple dozen of them.

Moreover, even if Pete is willing and able to relay the payment when he receives the message from Alice, he may no longer be viable by the time Alice gets around to negotiate the payment, because he may have relayed some other payment in the menatime. That would force Alice to start over, with a new broadcast. And Pete cannot reserve the capacity that Alice asked, because that would result in most of the network's capacity being frozen for payments that will never happen.

Broadcasting states does not work Another early proposal to solve the path-finding problem was to have each node broadcast his current state to the network. Then Alice, to send 10 BTC to Zeke, would look for a path in the network's topology but ignoring all channels with less than 10 BTC of capacity. However, every payment that is executed would result in some 20 channel state change notifications being broadcast to every node in the network. ? The state like balance is shared just between 2 nodes that are connected and ones updating the channel, the existence/capacity of the channel that makers choose to make public is verifiable with on-chain channel opening transaction, the policy of what fee rate they charge is typically what's gossipped across the network. ?? CLAIM: It's pretty easy to do 100s of those attempts very quickly using heuristics like recent success rates of various paths you tried or instead of trying to find the cheapest path many others would try can choose to skip cheaper paths to ones that are more expensive but more likely to then be still liquid. ?? If every node in a 108 graph keeps state information about a local subgraph of 3000 nodes, then every channel is in the local subgraphs of thousands of nodes, and therefore every significant payment through a channel must be known by thousands of nodes. ?? Suppose that the network has 1000 nodes and Alice made 100 multihop payments in the last month. How does Alice's node get the information that it needs to find the next path to a node she has not made any payments yet? How does she find whether the nodes that she may need to use are online or not? ?? Last time I checked, the reference implementation just picks a route on the graph and tries to send the payment through it, repeating that attempt until it finds one that has enough clearance.

Fraudulent reversals

?? Channel payments can be reversed. To prevent that, they put settlements (channel closures) on hold for a couple of days, during which time the other party can issue a "punishment transaction" that frustrates the fraud. But you must then sync and check the blockchain at least once a day; or pay a fee to a Watcher and tell him every payment that you do. ?? "secure as long as both parties monitor the blockchain 24/7 and are able to promptly issue the penalty transaction before the deadline" is the same thing as just "secure". ?? That "security" model of bidirectional channels has other problems as well. If Alice loses her LN wallet, or is forced to recover it from a backup that is not fully up-to-date, she has no secure way to recover any lost transactions, or even to tell whether there were any. (That is unlike raw bitcoin, whose wallet can always be restored if one has the seed password.)

High open/close fees

?? Each channel costs two BTC confirmation fees (one to open, one to close). Gurus have been predicting fees up to $50 per transaction on the BTC network (as we saw during some backlogs). To make a good network, each user woudl need three channels on average. That is $300 fee (non-refundable) just to enter the system. ?? There is no off-chain "topping up" of a channel. What one can do is send the miners a transaction that combines a channel closure and an opening. The transaction in fact will be a channel opening that used as funding inputs the outputs of the previous channel opening, in addition to the new funds. The inputs of that transaction would be the two UTXOs of the channel in question as well as the UTXOs of the additional funds. The transaction fee will be less than that of separate closing an re-opening, but more than that of openting a new channel. ?? A top-up will be delayed to guard against fraudulent closures (see ??below), as a closure would. ?? Within the LN one can shuffle remaining balances among one's channels, but only up to the original funding. ?? CLAIM: batch transactions called channel factories that allow potentially hundreds of channels to be opened in one transaction. ANS: Each user needs to be individually identified. No amount of compression will change that. So those transactions save only part of the fee, because the fee is promportional to the size of the transaction. The cost PER CHANNEL is still expected to be tens of dollars. Also there is a fairly low bound of the reasonable number of users you can combine into one transaction. ?? CLAIM The members of a channel factory need to show proof that their data is contained in the merkle tree which is recorded on the blockchain as just one hash. The merkle tree itself is held off chain. ANS? What does this mean?

Nodes must be balanced

Another flaw of the LN is that it assumes that nodes will be balanced, that is, will end up sending as much BTC as they receive, averaged over a suitable time frame. If a node is not balanced, the outgoing or incoming capacity of its channels will soon be exhausted, and its owner will have to periodically issue transactions on the blockchain to create new capacity.

?? That has been implicit, and often explicit, in all discussions of the LN. If Alice receives $5000 salary each month through the LN, but only spends $2000 per month through it, her incoming channel(s) will saturate after she receives a couple of salaries. Her employer would have to open a new channel to Alice every 2 months or so. He would need another $5000 in bitcoins on-chain to do that; if his bitcoins are locked in the LN, he will have to close channels to get them. Suppose, for example that Alice is a migrant worker in the US who wants to send $200 of her weekly salary to her Mamacita in Palombia. If she joins the LN by opening a channel to some existing node with $200 worth of funding, the channel capacity will be exhausted after the first remittance; to send another $200, she would have to open another channel. Compared to using the BTC network directly, LN would only be an added complication.

As a another example suppose that Bob Scrooge is a landlord who owns 20 apartments, each of them rented for $1000 per month. However he is a very frugal man and spends only $2000 per month, saving the other $18'000. If he choose to receive the rent in BTC, via the LN, the incoming capacity of his channels would be reduced by $18'000 every month -- even assuming that he pays all his bils and groceries through the LN. Any reasonable funding that may have been provided for those channels would be exhausted after a few payments

An unbalanced node could restored the capacity of its channels by using a third-party "LN bank" service that sends or receives payments to the node, through the LN, in exchange of equivalent payments outside the BTC and LN networks. In Alice's case, she would send the $200 in dollars to an LN bank, e. g. by credit card or bank wire, and the LN bank would then send the equivalent BTC to her node, recharging her channel. Bob instead would send the BTC worth $18'000 to an LN bank, via the LN, and the bank would deposit the dollars in his traditional bank account. But that requires (a) using a traditional bank and (b) ?? The LN assumes that the "LN economy" will be balanced at node level: namely, each user must spend through the LN precisely what it receives through the LN, over a sufficiently short time scale. In particular, if you earn $5000 every month through the LN, but only spend $2000 every month through it, your incoming channels will saturate after a couple of months. ?? At any moment, the forward capacity C of a channel with total funding (Alice:X,Bob:0) will be between 0 and X. Lacking any statistics of real behavior, let's model the evolution of C as a random walk with random steps, with barriers at 0 and X. That is, payment requests for that channel arrive with a Poisson distribution. Each request has a random amount V with a probability distribution that is symmetric about 0. with positive V being from Alice to Bob. If C' = C-V is between 0 and X, the payment is executed, and the capacity changes to C'. Otherwise the payment attempt fails and is "forgotten". Under this model, the probability distribution of C will have a peaks near 0 and near X. See figure ??. That biased distribution increases the probability that a payment attempt will fail due to saturation of channels. ?? If Alice receives $5000 every month through the LN, but only spends $2000 of it, she can remain balanced by sending $3000 each month to an "LN bank". However, the bank must be balanced too; therefore, it must send out an amount equal to the net inflow from all its clients. It could for example lend them to third parties, which would be fractional banking with a 0% fraction. ?? (This is an instance of a conservation law, which appears in all sort of systems and flows, like water or oil in pipes and tanks, charge in and electrical circuit, mass in a galaxy, people in a subway, etc. This is one reason why every software engineering curriculum should include a college-level physics course...) ?? She can use circular payments to herself to shift clearance among her channels; but she cannot change the total clearance (and the clearances cannot exceed the original funding). If her incoming channels have less than $5000 clearance, she cannot receive her salary, not even if split between separate payment paths. ?? More generally, if a node is not balanced (persistently spends more or less than it receives), that problem cannot be fixed with circular payments. ?? CLAIM: In the real world, an unbalanced node would be like a person with a net positive cash inflow who stuffs all the dollars under their mattress (or someone with a printing press). It doesn't happen. Instead the same paper money goes round and round. ANS: ?? In real life people do save money for years before buying a new car or home. In real life, most savers would put money in the bank. But cryptos were supposed to remove the need for banks. If LN is going to have banks, then one does not need the LN...

Long paths

?? The more hops a path has, the longer the payment will take, and the greater will be the chance that it will fail. ?? Payment paths are expected to have at least half a dozen hops in a modest-size network. Each intermediate node will charge a fee. The more hops a path has, the longer the payment will take, and the greater will be the chance that it will fail. ?? CLAIM: in a random power law graph with 100M nodes the average distance is ~8.5. ANS: False already in the current toy LN: 30'000 nodes, and half of the node pairs are 9 hops apart or more.

Centralization

?? No one wants to guess what the network's topology will be. If it will be random, payment paths will need too many hops. If it will have a few large hubs, they will have incentives to centralize. ?? The current LN already has half a dozen very large hubs and many nodes with only 1 channel.

Clearance fragmentation

?? If you have $100 of current clearance in each of your three outgoing channels, you cannot make an LN payment for $101, even though your total clearance is $300. ?? You may be able to shift credit from one channel to another, but only up to the original funding. ?? CLAIM: A single payment can be aggregated from multiple channels. ANS: It cannot. While in theory a valid flow (a "path" that branches and rejoins) may exist where a single valid path does not, finding and negotiating a valid flow is computationally much harder than finding a simple path. ?? In the current design, a payment too large to find a viable route must be split into independent installments. Each installment needs to use a separate payment path, that starts with a different channel and must be found and negotiated separately. Each installment thus will reach the merchant at different times, and may fail independently. The payment thus will not be atomic. An incomplete payment is much more inconvenient for a merchant than a payment that cleanly succeeds or fails. How many stores do you known that would let you pay half the amount with PayPal, and will wait for the other half to come by bank wire? ?? Similarly Alice could shuffle the clearances of other nodes by sending payments trough paths that loop back to them. However she does not know their clerances...

Funding fragmentation

?? User must predict how much it may spend through each channel. Not obvious. Will limit the maximum payment that can be sent in one path. ?? Clearance shuffling cannot change the original funding. If you have three channels which were initially funded with $100 each from your side, you cannot ever send a payment of $101, because the clearance of each channel will never be more than $100. ?? To allow largest possible payments, you should create only one channel and put all your funds into it. But if most everybody did that the network would be very inefficient and prone to disconnection.

Economic/business problems

Not competitive

?? It canno compete with centralized payment systems like VISA. ?? It is claimed to be better than Bitcoin alone. ?? CLAIM: it will be permissionless. You can create a wallet and receive funds just by running software. You can broadcast the location of your wallet just by giving people an address. ?? CLAIM: it will be censorship Resistant - no authority can decide which payments are sanctioned and which are not. ?? CLAIM: it will be enominated in Bitcoin. ANS: that is a huge flaw, not a feature. ?? CLAIM: it will be more "fungible" since lightning payments are processed off chain, and onion encrypted, there is no direct record of a payments origin and destination on the blockchain and very incomplete information known to the nodes themselves. ?? CLAIM: essentially Instant - possibly faster than a chip card currently verifies. ?? CLAIM: Support microtransactions, e.g. like car charging stations and various virtual goods like streaming video. ?? CLAIM: potentially Cheaper than incumbent payment networks.

Locked funds

?? Like debit cards, users must procure and lock bitcoins in advance in each channel, sufficient for the maximum net payment that the user expects to make through that channel. The funds remain unavailable for use on the BTC network until the channel is closed. The difference is that it is very expensive to open, close, or to-up a channel. ?? If Alice's payments sent and payments received are balanced only in a three month time frame, she must lock up, in advance, enough funding in her channels for the maximum inbalance. ?? CLAIM: channels are for making payments much smaller than the total size of the channel. ANS: That would make the locked fund problem much worse. ?? If you intend to use the LN only to pay $5 per day at the BarStucks coffee place, and you don't know if an when you will receive money through the LN, then you must open a channel with maybe a couple thousand USD worth of bitcoin. ?? In particular, large hubs will need to lock up lots of bitcoins of their own in their outgoing channels. For example, if a hub sits between 1000 consumers and 10 merchants, and each consumer locks $1000 in his channel to the hub, the hub may have to lock several million $ of its own in the channels to the merchants. ?? Even if the "random" selection of partner by a new node is biased towards nodes with higher degree (which is needed to ensure the appearance of large hubs), most of those default channels will allow sending from the "customer" to the "hub" only. So those hubs that form are likely to start with a lot of incoming capacity but only small outgoing capacity. ?? If you think that you will buy a $20'000 car in six months, you should open a channel now with $20'000 funding. But what if you don't have that money to start with?

Incoming funding

?? Moreover, each user also needs incoming channels, and the funding for each of them must come from the party on the other side; so it cannot be opened unilaterally with any random pre-existing node. Suppose Alice wants to set up an e-commerce site that sells alpaca socks, and she decides to accept payments in bitcoin through the LN. To do that, she will need at least one channel to some node Bob with positive capacity in the incoming direction. If she is not an LN user yet, she must create such a channel. If she creates the channel unilaterally, the initial state will be (Alice:X,Bob:0) for some amount X of bitcoins provided by her. A channel in that state cannot receive any payments. Therefore, she would have to somehow get Bob to fund her channel instead, so that the state begins as (Alice:X, Bob:Y) for some positive amount Y.

But then she can receive only $Y net through that channel until she makes her first payment. More generally, the amount she has received, minus what she has sent, cannot ever be more than Y.

So, must Alice msut convince Bob to not only lock some cois for her, but lock more than what she expect to receive befor or between spends. Maybe Bob will do that, if he is an individual and friend of Alice. But if Bob is ??

Pyramidalization

The are some situations when a new LN user Alice will negotiate with a current user Bob to open a channel whose initial funding is partly or wholly provided by Bob. However, most new users are expected to open channels unilaterally: new node Alice opens a channel to the already existing node Bob (e. g., a convenient hub) without his knowledge and consent, and therefore she will have to provide all the initial funding. That is, the state of such a channel starts (Alice:X,Bob:0).

Alice must be balanced in the long run -- namely, her total amount sent S, minus her total amount received R, will always be between 0 and X. Statistically, the expected value of S - R will be some positive number in that interval. Thus, at any moment the newest nodes will generaly have sent more than they received, while the opposite will be true for the oldest nodes. This a characteristic and damning feature of financial pyramids and MLM schemes. The extent of this general bias of the money flow is hard to predict, since it depends on the statistics of user profiles and usage. ?? Those unilaterally-funded channels always point from new users to old users. Therefore, at any moment in the future, the most recent users will have a positive balance through those channels towards earlier users. Flow in the reverse direction will depend on channels being explicitly opened and funded by the elders towards the newbies. ?? By default, the channels opened by the LND have funding only in the forward direction.

System security problems

Malicious nodes

?? The LN depends on users informing their state truthfully to many other users. It is not known how it will react to malicious or faulty nodes lying or failing to report about their status. For instance, a node could place itself so as to atract many paths, and confirm its mediation, but pull out (or just pretend to go dead) at the last moment before committing to any transfer. If many nodes do that, the may considerably slow down the network for everybody. ?? Payment paths are expected to have at least half a dozen hops in a modest-size network. Each intermediate node will charge a fee. The more hops a path has, the longer the payment will take, and the greater will be the chance that it will fail. ?? CLAIM: When it doesn't match what we heard through gossip or it lacks liquidity, that attempt fails, and mission control doing the sending and deciding paths degrades the score of the node/hop that failed for whatever reason and just sends out tx through different path. ?? CLAIM: DoS attacks cannot make a profit so they will not occur. ANS: DoS as blackmail are real. There is plenty of profit to be had from DoS attacks. ?? CLAIM: Most nodes will be honest. ANS: That cannot be assumed in a network that carries money.

Legal problems

Money transmitting laws

?? Largish hubs (processing tens of thousands of $ per month) will probably be considered money trnsmitting services. In that case they will need to comply with KYC/AML rules, ?? CLAIM: And if this were true the companies that need to run big hubs, like Coinbase, already do KYC/AML. ANS: That wouldlimit the LN to US users. ?? Money transmitters must register with FinCen no matter how much they process. In particular, systems like Hawala and Hundi are considered money transmitting businesses.

(Non-)privacy

?? The LN fanbase seems to be mostly Ross Ulbricht orphans; so much so that the LN devs spent time implementing onion-style path obfuscation in the negotiation protocols, even before having a decent path finding algorithm or Watcher services. (And now they are discussing going back to non-obfuscated path negotiation, and then implementing onion routing as an optional layer on top of that.) Or maybe the onion version was too obviously inefficient, whereas the efficiency of the current method cannot be evaluated without realistic simulations.

Development problems

No real testing

?? The people testing it are mostly BTC fans who want to maintain the illusion that the LN will solve the obvious crappiness of the base BTC network. The LN is indeed fast and free if the two parties are connected by a single channel. It is a bit slower and more expensive if they are connected by a two-channel path. Most tests that are reported by believers can be assumed to be in these two cases -- with amounts smaller than the remaining capacities in those channel(s). ?? Testnet is not instrumented.

No network or user demand model

?? The developers did not start with any network model, not even a qualitative one. ?? When one points out that in a decentralized network it will be imposssible to find valid paths, they say that the network will be dominated by a few large hubs. When we point out that large hubs have censoring and monitoring power, and require absurd amounts of funding they chaim that the network will be a decentralized network with no large hubs... ?? They did not start with any user activity model, not even a very rough one. ?? Joseph Poon, one of the two inventors of the LN, estimated that BTC would need 100 MB blocks just to accomodate the expected channel open and close transactions.

Refusal to simulate

?? We are asking for the designers to specify the parameters above for a possible network with at least a million users (about the estimated number of BTC users today) and minimally realistic usage patterns. WIth that data, we can do the simulations ourselves. ?? No one wants to guess what the network's topology will be. If it will be random, payment paths will need too many hops. If it will have a few large hubs, they will have incentives to centralize. ?? Current toy LN is not representative of the hypothetical real one. ?? The data that one would need to simulate the network: at the minimum, the number of nodes of various classes (consumers, merchants, employers, renters, hubs), the topology of the network, the distribution of channel counts per class, and the frequency and distribution of amounts of payments per class. ?? That numeric scenario does not need to be a prediction, not even a probable or reachable future. It only needs to be minimally realistic (e. g. cannot assume that each consumer will buy from only one merchant, or always buy the same amounts from the same set of merchants). Then we can simulate the system and measure failure rates and such. ?? Diane Reynolds did such a simulation six months ago, but she used a very small network with a highy unrealistic topology (a square toroidal grid) and unrealistic usage patterns. Why haven't the LN proponents done something like that, but with more realistic numbers? ?? Given their refusal to provide such a scenario in all these years, I claim that the LN authors have not been able to find such a scenario that does not immediately fall apart when simulated.

Failure to admit that the problems are unsolved

?? I've watched engineers fail. It's not pretty. It takes them waaaay too long to come to the obvious conclusion that they've failed. They tend to cling on for far longer than they should, painfully grasping at straws. Is that going on with LN? Is that why this is taking so long? ?? Even if the developers are not lying, the people watching them definitely will lie their assess off. ?? The developers are not financially motivated to solve this problem, but only to make it look like that a solution is coming -- "Just 18 months away" (a joke that is already tired). The motivation comes from their salaries and/or them being invested in BTC.

But it exists and it works -- just try it!

Bitcoin promoters will often reject criticism of the LN by claiming that "it is there and works"; often with "testimonials" like "I just paid for a taco in San Salvador and it took only a few seconds" or even "I just sent 1000 payments and they all succeeded and completed in minutes".

But, first, an LN payment will indeed be instant and free if the two parties are connected by a direct channel. It will be just a little slower, and very cheap, if they are connected by a two-channel path with a cooperating middle node. Assuming, in both cases, tha all channels have sufficient capacity. In these situations, one can also send 1000 payments back and forth between the two nodes, quickly and cheaply. But the path-finding problem and other flaws only arise when the necessary path has three or more hops, or when the channels do not have enough capacity. Thus tests mean nothing if they are done by believers, between nodes of their choice. Similarly, tests by skeptical users would be pointless, because they would be dismissed as done on intentionally bad artificial situations "that will never arise in practice".

Second, more importantly, the current LN has less than 20'000 nodes at the time of this writing, and it is hardly growing -- in fact, it has recently started to shrink. And that in spite of the claim that millions of people in El Salvador are using it to pay for tacos, tatoos, and baseball caps with the visor on the back. That is not only much less than the hundreds of millions that the LN is supposed to serve, but tiny even compared to the number of people who own a significant amount of BTC, estimated to be a few million. That network is too small to give any clue about the performance of a hundred million node network. For one thing, the topology of the current LN network can be encoded in less than 1 MB of data, and thus can be stored in every LN node; and the average number of candidate paths between two random nodes is still small, compared to what those numbers would be in a network 10'000 bigger.

Moreover, few if any of the current LN nodes belong to people who were attracted to the LN for its hypothetical advantages as a payment method. The currency is too volatile, and there are practically no merchants or services that accept LN payments. Since one must own some BTC in order to join that network, it is safe to assume that practically all its "users" are BTC believers who joined only out of curiosity, or to help the LN developers, or just to help sustain the illusion that the LN "is there and is working". Because that illusion is essential to prop up the price of their coins.

For the same reason, the current LN is unlikely to have any malicious users who would try to sabotage it. And even if there were saboteurs, and they succeeded in rendering that LN unusable for days at a time, no one would know apart from the affected users -- who would not want to publicize their troubles.

----------------------------------------------------------------------

Channels can in fact be topped up.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]biglambdaspecial needs investor. 1 point 4 years ago In another comment, BigLambda claimed that the LND code opens three random channels by default, and that most users will not bother changing the defaults. That may be what the test version does. Since each channel requires locking up a bunch of bitcoin, obviously the real version will not open three channels at random by default.

No. There is no difference between the test and the distribution software other than what blockchain it talks to, and yes by default all nodes, even mobile ones will open and maintain at least 3 random channels. This is analogous to the fact that every Bittorrent node uploads data while it's downloading even though the users only probably care about downloading. The software default makes the network work and 99.999% of users follow the default.

The rest of your response is as much based on bullshit assumptions as this one. You don't in fact know anything about the actual network and continue to make arguments based on frankly dumb assumptions that reveal a serious lack of proficiency.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 1 point 4 years ago* by default all nodes, even mobile ones will open and maintain at least 3 random channels I suppose that you will not care to explain where the funding for those random channels will come from, right? Especially the funding in the incoming direction?

You don't in fact know anything about the actual network

I suspect that you know less than I do, and a lot less than what you pretend to know.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]biglambdaspecial needs investor. 1 point 4 years ago* What I know comes from reading the code, reading the mailing list, and talking to the developers directly. Have you done that?

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 1 point 4 years ago*

It is a pity that those LN explorer sites do not give the total in and out funding of a selected node, nor the current state of channels. But they do show that a large fraction of the ~1000 nodes currently on the mainnet LN have only one channel, and a significant fraction have zero channels (zoom out to see them).

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]BrangdonJ 1 point 4 years ago The bank sends the money to Alice's employer, so she can be paid with them again. The Bitcoins go round and round. Each time a number in Alice's account at the bank goes up, and her employer's account goes down.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 1 point 4 years ago* The bank sends the money to Alice's employer Why would the bank do that?

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]BrangdonJ 1 point 4 years ago Why would the bank do that?

Because Alice's employer needs money to pay Alice.

A user cannot do that easily, since it does not know the clearances (or balances) of any channels besides her own.

The router needs to know the balances to plan a route, otherwise it will try to send more money through a channel than the channel can handle.

More generally, if a node is not balanced (persistently spends more or less than it receives), that problem cannot be fixed with circular payments.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 1 point 4 years ago Because Alice's employer needs money to pay Alice. I did not know that banks were charities for employers. 8-)

The router needs to know the balances to plan a route, otherwise it will try to send more money through a channel than the channel can handle.

That apparently was the original idea, but it would obviously fail to scale and would make all payments visible. So now the nodes don't know any balances except their own. The sender just pick a path in the graph and tries to send though it. If it fails because some channels have not enough balance, the sender strikes those channels out from the graph and tries again.

No use asking them how many paths must be tried before one succeeds, or how often the process ends with no path found...

In the real world, an unbalanced node would be like a person with a net positive cash inflow who stuffs all the dollars under their mattress (or someone with a printing press). It doesn't happen. Instead the same paper money goes round and round.

Well, i

And moreover the same balancing requirement would hold for the bank: it must lend or invest all the deposits it receives, within a month or so; otherwise its channels will saturate too.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]BrangdonJ 1 point 4 years ago I did not know that banks were charities for employers. 8-)

They aren't, and don't need to be. The money to pay Alice has to come from somewhere. If it makes it easier, consider that when the company's customers pay the company, some of those payments are routed through the bank.

But cryptos were supposed to remove the need for banks.

People will still want many of the services of banks, including protection against theft. And it doesn't have to be a bank. It could be a service with the specific role of rebalancing channels, if necessary using off-channel transactions, even fiat transactions.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 2 points 4 years ago Again, it is a necessary assumption of the LN that the LN payments of each node are balanced on some time scale (like a month). On-chain and fiat payments do not count for that purpose. If Alice receives a $5000/mo salary through the LN, she is forced to spend $5000/mo through it, even if to deposit them in a bank, or exchange them for fiat or on-chain bitcoins. And the same goes for her bank, her employer, and every merchant.

Since the idea came up, I have been debating the LN with many gurus and fans -- including Adam, Luke, Mark Friedenbach, and Poon himself. The assumption that the LN would be a closed economy with balanced nodes was always implicit or explicit in those discussions. If employers have to close channels and use on-chain transactions every month or week to pay employees, the scaling problem comes up again.

Recently it seems that the LN developers have realized that the LN will not be the scaling solution that has always been assumed (and most bitcoiners still believe). When pressed on that point, the LN devs now seem to say that the LN will only help reduce the scaling problem by taking over only some payments...

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]BrangdonJ 1 point 4 years ago On-chain and fiat payments do not count for that purpose.

My meaning was that Alice could send $3000 a month through the channel to her bank, or an exchange, and they would send her $3000 back in fiat or on-chain.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 1 point 4 years ago I understood that, But Alice would still be forced to spend $5000/mo through the LN. It is secondary whether she gets food, dollars, or on-chain bitcoins in return.

Note that she would have to trust the bank or the currency exchange. While LN payments themselves are "secure" (in the weak LN sense), nothing ensures that the exchange will send her the dollars after she sends $3000 of LN-coins to it.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]BrangdonJ 1 point 4 years ago Sure. The same is true for on-chain transactions. Bitcoin can't guarantee the counter-party will deliver the goods or services you think you are paying for.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 2 points 4 years ago However, the bitcoin protocol does not require you to engage in such transactions to keep your earnings and expenses balanced. On-chain, you can receive a million bitcoins and keep them for years, without affecting your ability to receive more.

More generally: the LN is considerably more complicated, inconvenient, constrained, and unreliable than plain bitcoin. Its only supposed advantage is that its transactions would be off the blockchain, thus (supposedly) saving fees and time.

Frankly, from what I have seen, I don't think the LN will be viable at all. I suspect that the LN developers are finally beginning to realize it too -- but obviously cannot admit it.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]BrangdonJ 1 point 4 years ago It's not a panacea. If people who hadn't realised that before are realising it now, that's a good thing. And if it reduces on-chain transactions 10-fold or 100-fold, while making the off-chain transactions faster and cheaper and enabling new use-cases like micro-transactions, that will surely be very worthwhile.

For me the key question is where on-chain fees will end up. If under $1, then it all works. That's affordable for largish on-chain transactions, and a reasonable cost for opening and closing channels. If it's over $100, then it all relies on LN performing superbly and even then it has a high cost of entry. I have tried to find out before where Bitcoin influencers think fees will be, without much luck. High fees now make some sense to encourage more efficient use of the blockchain - multi-output transactions, SegWit, Lightning Network - but when that is done, the fees have to drop to a reasonable level. If the Bitcoin inner circle are now realising that, it's a good thing.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 2 points 4 years ago It's not a panacea.

I believe it is much worse than that: it is a water-fueled car -- a clever idea that seems to work when described in words, but falls apart as soon as one looks at the numbers.

And if it reduces on-chain transactions 10-fold or 100-fold

At present, the most optimistic predictions are much more modest. I would be really surprised if it gets a million real users and carries one payment per month per user, on average. More likely, it will never get more than a few thousand users, out of curiosity, and they will all give up after a few attempts.

If it's over $100, then it all relies on LN performing superbly and even then it has a high cost of entry. I have tried to find out before where Bitcoin influencers think fees will be, without much luck.

I have been discussing with some of them for two yars now, and they often predicted $50 or more.

Ari Paul and Tuur Demeester have recently claimed over $100. But, granted, they are bogus "experts" even by butter standards. Adam Back and Bruce Fenton did not quite predict, but recently said that they would find $100 reasonable.

High fees now make some sense to encourage more efficient use of the blockchain

The high fees and huge delays of BTC are artificial: a consequence of an intentional choice of the Core devs to implement Greg's plan to reform bitcoin into his two-layer design. The rational course of action by real users (as opposed to hodlers and traders) would be to use other coins like BCH, LTC, ETH, etc.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]TotesMessenger 2 points 4 years ago* I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit: [/r/btc] 11 points of criticism of the Lightning Network [/r/lolnet_uncensored] Lightning network sounds a bit wack. Is it? (jstolfi) • r/Buttcoin If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)

permalinkembedsaveparentreportgive awardreply

[–]unitedstatian 5 points 4 years ago Nodes will have to be online 24/7 with a hot wallet.

It's the chicken and the egg, the network has zero utility without everyone already using it.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 6 points 4 years ago the network has zero utility without everyone already using it.

Yes. That is a big problem too: the LN will only reduce on-chain payments if a large majority of bitcoin users are LN users.

If only 50% of the bitcoin users are LN users, and the current payments between bitcoin users are equally likely independently of whether they are LN users (L) or not (B), then 25% of the payments will be B-B, 50% wil be L-B or B-L, and 25% will be L-L. Only the latter will be removed from the blockchain. The L-B and B-L payments will probably require creating or closing existing LN channels, and therefore each of them will imply TWO on-chain transactions. Thus instead of 100 on-chain transactions there will be 125 on-chain transactions...

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–][deleted] 1 point 4 years ago No crypto currency should call itself a currency. None of them are being used as currency right now. None. At the very best you might get a business interested in getting their name in the newspaper because BITCOIN. The amount of people in the world that have ever bought something online with Bitcoin more then once I'd say is less then 100 000.

But nobody ever shares any stats. So you can take tx and then have stats of sales done in Bitcoin or any crypto for that matter.

The crypto economy is some buying of VPN, a lot of buying of drugs. A borderless settlement tool, handy for when your legitimate business also does a bit of heroin trade here and there. Then you can fire your swiss banker guy and that's once prick less then can screw you over.

And so 95% of crypto TX is day trading. If we leave out stuff like STEEM and possibly Ethereum.

Anyway I am ranting again. If only the entire space could be a little self honest and stop with the whole deception thing, that would be marvelous. And we can all be a little more realistic and actually get somewhere instead of trying to sell each other castles in the sky.

permalinkembedsaveparentreportreply

[–]jstolfi 1 point 4 years ago No crypto currency should call itself a currency. None of them are being used as currency right now

Bitcoin still is being used to some extent as a currency to buy drugs and other illegal payments. I suppose that counts as "currency".

The amount of people in the world that have ever bought something online with Bitcoin more then once I'd say is less then 100 000.

There may be a million people who used it once. For more than once, 100'000 seems too much...

That estimate seems too high even if one includes purchases with BitPay and the like, which are not actually "using bitcoin",

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–][deleted] 2 points 4 years ago Bitcoin still is being used to some extent as a currency to buy drugs and other illegal payments. I suppose that counts as "currency".

Yeah that's true. Tipping. VPN. Some services on the internet. I just wish I had some data on what tx are used for what.

permalinkembedsaveparentreportreply

[–]jstolfi 1 point 4 years ago That is another big problem to worry about when investing in bitcoin: there is no reliable and meaningful information at all on the "bitcoin economy". It is quite possible that 90% or more of the traffic on the blockchain is not payments, but mixing, gambling, wallet housekeeping, deposits to/from exchanges, etc. -- or even just spam by shillers. (There are hints of that -- for example, that the total BTC moved per day has been roughly constant since 2012, even as the price rose and fell by orders of magniture. If they were payments, one would expect thet USD amount to change slowly instead.)

The LN will be even worse. Until last week there was a main-net LN explorer that showed ~1000 nodes and a couple thousand channels. But it did not show the LN transactions or channel balances -- so one could not tell whether whether paths were succeeding, channels were being saturated, etc. In fact one could not even tell whether that LN was being used at all.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]In_der_Tat 1 point 4 years ago It's a medium of exchange, not currency nor money.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 2 points 4 years ago Oh no, the Definition Monster attacks again... ;-) [–]ProgrammaticallyRIP 3 points 4 years ago It seems to me that trying to fraudulently close a near-depleted channel (say 99/1) using the opening state (50/50, say) can be pretty profitable since at most the cheater can lose 1 unit but gain 49 units. Since cheating becomes more profitable the more unbalanced a channel is, rational participants will be unwilling to let their channels become very unbalanced, thus limiting the effective channel capacity further.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 2 points 4 years ago Yes, see this other comment.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]ethereumfail 1 point 2 months ago* If both outcomes were equally likely, yes it would be profitable to risk little to get a lot. And it might work if targeting just novice ln users not following best practices. But penalizing is very easy, usually.

Routing nodes (ones that always online) have to_self_delaysetting of usually of >=1 day (144 blocks) to penalize old secret being used to force close channel and phone wallet more client oriented nodes have it as high as 2016 (2 weeks) to get penalty tx in. A typical phone ln client node just has to be online more than once every 2 weeks to check.

you can also share your penalty transactions to anyone whatsoever as they are useless unless the attacker force closes and creates the utxo the penalty is trying to spend. which is where thing called watchtowers come in, which are just random people collecting people's penalty transactions and if any of those become spendable, they just broadcast them at no cost to themselves. can add as many watchtowers as you want to do that for you including your own nodes. Attackers simply don't really know who and how many watchtowers are being used by other nodes.

(didn't see the date sry)

permalinkembedsaveparentreportgive awardreply

[–][deleted] 4 years ago [deleted] [–]jstolfi 2 points 4 years ago* LN fans say that the problem can be "solved" by requiring each party to fund the channel with some extra "penalty reserve" above the amount that she intends to send though it. However, besides adding to the inconvenience of the advance locking, that reserve will only reduce the payoff of the fraud a little.

For example, suppose that the channel betwen Alice and Bob is funded with $1000 both ways, and they agree on a $100 "penalty reserve". Then Bob should refuse to accept a payment from Alice through that channel if it would bring the net payment above $900, and vice-versa.

So suppose that, at one point, the balance of payments is $900 in favor of Bob. If they close the channel normally, Alice gets $100, Bob gets $1900, and that supposedly is fair given whatever goods or services Alice received from Bob.

If Alice tried a reversal fraud at that point, using a previous state where the balance was $900 in her favor, and Bob reacts with the "punishment transaction", she would receive $0 and Bob would receive $2000, which is a $100 loss for Alice relative to the "fair" closure above. On the other hand, if Bob fails to react, Alice would receive $1900 and Bob $100, which is a $1800 gain for Alice relative to the "fair" closure.

So, the fraud could pay $-100 or $+1800 to Alice, depending on Bob's reaction. The fraud will be worth trying if Alice thinks that there is a 6% chance that Bob will be unable to issue the punishment transaction in time.

permalinkembedsaveeditdisable inbox repliesdeletereply

[–]mossmoon 1 point 4 years ago To make a good network, each user woudl need three channels on average. That is $300 fee (non-refundable) just to enter the system.

Is this true? I thought one on-chain tx can open up to 5 channels.

permalinkembedsaveparentreportgive awardreply

[–]jstolfi 2 points 4 years ago The on-chain miners fee is proportional to the size of the transaction. You can save some bytes by packing several transactions in one transaction, but only if you open the channels at the same time and the funds of two or more channels come from the same UTXO.

If you have thirty $10 UTXOs in you wallet and you want to open three channels, each with $100 funding, you will not save any significant fee by doing it in one transaction instead of three.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–][deleted] 3 points 4 years ago My dad is going to be pissed. We just got an understanding of decentralised networks vs centralised networks in the context of a financial system. I told him that once he understands Bitcoin we will be armed with some knowledge for the future. But I never said: oh wait dad, they are constantly going to make it more and more complex until you might as well stay with your bank anyways cause even your son would not be able to help you with crypto anymore.

permalinkembedsaveparentreportreply

---------------------------------------------------------------------- Phew!

I must commend Archprofessor Big Lambda for the effort. A pity that his conclusion "[the LN] not 100% finished but the engineering challenges that remain are tractable" is a flat-out lie, and no amount of analogy can change that.

The reason you drive calmly down such a road every day is because you know that if an oncoming car swerves into your lane and kills you, they risk killing themselves, destroying their vehicle and potential legal consequences. ... [LN users can't reverse their last payments] without risking their entire stake in the channel.

And that is why the "two cars on a road" is an inappropriate analogy: because, in a bidirectional payment channel, one or both parties can profit a lot, without any legal consequences, if they know that the other party will not be able to "swerve out of the way" in time.

In particular, once Bob's funding is exhausted, he has nothing to lose and a lot to gain by trying to close the channel with a stale cheque.

More generally, if he has X unspent bitcoins left in his channel, and he has an old cheque T that would return him Y bitcoins, sending the latter to the miners will will be a good gamble if p Y (his expected worth after doing that) is greater than X (his worth if he does not do that); where p is his probability that Alice will fail to react in time.

Since the bitcoin network is assumed to be congested (otherwise the LN would make no sense), p will definitely be nonzero -- even if Alice is a computer-savvy expert bitcoiner who keeps her computer up and connected 24/7 for the sake of the LN.

(But I am aware that algebra is a clumsy and unenlightening tool that Professors are obliged to use, whereas Archprofessors can get by with words like "larger" and "huge" instead. Especially Archprofessors of Game Theory.)

the computers that we are calling Alice and Bob

Once again: Alice and Bob here are people. Often one uses "Alice" as a shorthand for "Alice's computer", but the two are different things.

In practice phones are not likely to be used for bidirectional payments, they don't have enough connectivity.

Did your beloved bitcoin whoreporters ever mention that in their "layman expositions"?]

the phrase cryptomagically linked is disingenuous

Why "disingenuous"? Your "clarification" is exactly what I wrote.

A transaction passing down the chain does not increase this burden

An LN payment with N hops has basically N times the computing and bandwidth cost of a single-hop one, including its "watching" burden. The end nodes have the same cost, for any N, while each middleman has twice that cost.

To that basic BCP cost one must the extra cost of finding the path, negotiating the atomicity of the N payments, and the fees of the N-1 middlemen. The latter are paid by the end nodes and benefit the middlemen.

But we aren't assuming that.

You may not be, but the LN fans in general are.

By the way, much of what I wrote about the LN was confirmed to me by top Blockstream people and even Poon himself, in direct debate here on reddit. And, you see, they have this funny idea that the "scaling problem" is about how to get hundred of millions of people to use bitcoin regularly. So, they generally know that it is not realistic to expect them all to keep their computer up and connected 24/7 just to avoid being scammed with bad "cheques".

Likewise it storing coins in multiple BPCs doesn't affect how payments can be combined from them

You are conflating UTXOs and bitcoin transactions with BPCs and LN payments.

If you have four BPCs with $20 of outgoing clearance in each, you cannot make a $70 LN payment using three channels together (as you would do with bitcoin). You must make at least three separate payments, which will go through separate routes, each costing its middleman fees.

The same holds for each of the potential middlemen, and for the final node too. If would-be middleman Charlie has three channels with input clearances $200, $250, $0 and output clearances $50, $100, $80, respectively, he cannot relay a $110 payment, even though he could receive up to $250 in one payment and could send a total of $230 out. If the final recipient Zelig sells her car to Alice for 10 BTC, but he has only three input channels with 5 BTC clearances each, Alice will have to make at least two payments to him.

Now you will argue that this is not a problem, because that payment splitting task can be automated. And I must agree. That is the big advantage of relying on a non-existent routing algorithm: it can find a suitable set of paths to make up a desired amount just as easily and quickly as it can find one such path. And it also will be able to make all those payments atomic, so that there is no risk of running out of paths after sending half the amount.

if the node you share a BPC with is not malicious, it will just close the channel upon request.

It is a well-known fact that only evil people will disconnect their computers from the internet, or will be reluctant to pay channel-closing fees at the whim of the other party.

But wait, forget it -- How could I dare to argue about node availability with an Archprofessor of network engineering?

no one is attempting to [find an optimal route], what they are attempting to do is create a metahueristic or stochastic solution that finds as large a set of sufficient paths as possible and picks the best among them.

Metaheuristic! Ah, that is the key! If anything can get the LN working, it is that buzzword!

Seriously, I could explain what the word "metaheuristic" means, and tell some funny anecdotes about it. But in fact it is inappropriate here, because what the LN needs is just a simple (optimization) heuristic: a procedure that will find a path, that, while not optimal, is usually not too bad.

(It actually needs something better, because a heuristics that returns a 100-hop path on 5% of the cases will not be OK at all. But let's not be picky.)

So think of how a colony of insects organizes itself for example, each local actor has limited knowledge but collectively they create a desired outcome.

The algorithm that an ant colony uses to find food is roughly this: Hundreds of scouts leave the nest in random directions, wandering along random paths, so as to cover their whole "territory". Each scout uses visual clues and/or chemical markers to remember its path. When it finds food, it immediately retraces its path to the nest, leaving behind a special chemical trail. It then signals success to the other ants that remained in the nest, and these then follow its trail to the food.

This is pretty much the optimal algorithm for that problem, if each scout (LN node) has only a local view of the terrain (BPC network) and the colony (payment sender) has no idea where the food (payment receiver) is located.

This is the method that was assumed at the very very beginning of the LN saga. Its biggest problem is that it does not scale: in a network of 10 million payment channels, finding one payment path would require about 10 million node-to-node messages. if each node makes one payment per day, then each node would have to receive and forward 10 million messages per day. That is, the total work is quadratic (or worse) on the number of users.

Moreover, since all the channels in the desired path must have a specified clearance, each channel balance must remain unchanged (at least in one direction) after some "scout" has consulted it, until the path has been chosen. Thus, the entire LN network can only search for one path at a time, and must be frozen in the process. Another flood of messages must be propagated to unfreeze it after each search.

Better algorithms have been proposed since then, trading some centralization and increase in path length for a reduction of total cost o finding the path. FLARE is one such proposal, by researchers at BitFury. But any centralization requires constant messages from the nodes to the routing servers, to keep the later informed about changes in the channel capacities. That (like the Watcher concept) would destroy one of the originally alleged advantages of the LN -- the privacy of its transactions.

Before the Archprofessor of Entomological Networking mentions it: the routing problem of the internet is completely different, and it was the first thing that the designers solved when they set out to design it. In fact the internet is the solution that they invented to the problem of efficiently connecting many computers for the exchange of arbitrary data. And it relies on IP routing tables that are physically distributed but logically centralized.

There are still big questions about what eventual topology of the network will look like, what the final routing protocol will land on, what the duration of the average channel will be and what the fee structure will look like.

And that is a clear sign that the LN is a pipedream: the assumed topology and routing process change whenever one points out specific problems. "Routing can't work", say the critics. "But it will be centralized with one big hub", they say. "How will the big hub fund its outgoing channels", we ask. "It will be fully distributed so the users themselves will fund the channels". And so on an on, in circles...

[–]jstolfi 3 points 4 years ago* But the main point that I made is that you wrongly assumed that we need a globally optimal solution and we don't. I expliclty wrote that you don't need an optimal path, only a "good enough" one. (But you need a good enough path, that works, more than 99% of the time. If the LN says "sorry can't" once every 100 payments, no one is going to use it, even if it did not have all the other problems.)

But as I said in my original post, we don't know what this algorithm is yet, despite some good proposals, and that is an issue.

Good, at least you acknowledge that an essential part of the project is still missing. I hope you have noticed that no one even knows whether such an algorithm (like a solution to the concentration of mining problem) will ever be found.

In the late 1980s, since bitcoin and Wikipedia had not been invented yet, I spent my procrastination time on space exploration forums. The enthusiasts there were fueled by several "lightning network" like memes, such as the space elevator, electromagnetic launcher, asteroid mining, and the interstellar fusion ramjet.

Like the LN, the space elevator had been all figured out, except for one key detail: someone needed to invent a material that was strong enough and could be made into a flawless 40'000 km long, foot-wide ribbon.

But I am being unfair. Those space elevator enthusiasts actually did produce a complete design -- with all the essential numbers -- leaving out only details that were obviously doable, and that little issue of the cable's material.

Whereas the LN fans apparently cannot even begin to provide a sketch that makes sense. Not even say whether it will be centralized or distributed...

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]jstolfi 5 points 4 years ago* Alice is not going to allow the channel to be exhausted before demanding that the direction switch. This caveat is in even in the original paper. Aha. So, not only you must lock up in advance the money that you may want to spend in the next six months, but you also need to lock up 10% extra as a guarantee against you cheating. Which you may still be able to do anyway,

the amount of exhaustion that Alice will allow is based the number of timeout blocks in the contract. So this probability p is essentially built into the contract.

Because of course Alice can predict how long her computer will be disconnected from the internet, and how long the backlog on the Gregcoin network is going to last.

Alice could have thousands of blocks to confirm her transaction and more importantly she has a big incentive to raise the fee to recover here money.

If there are 100 people trying to board a bus that only takes 60 people, 40 of them will miss the bus, no matter how high a bribe they offer to the driver. I know that Greg cannot understand this fact, but an Archprofessor of your caliber might, perhaps?

No. The computations needed to approve a transaction are minimal. Just checking a signature basically. The watch list grows per channel state change, not per transaction.

An LN transaction through an N-hop path consists of N separate bidirectional channel payments -- with some overhead for the atomicity, fee negotiation, etc.. So, whatever the costs of a BCP payment are, an N-hop payment will cost at least N times as much.

Again it sounds like these costs are minimal.

Of course the cost of finding the path is minimal: that is another advantage of using a non-existent routing algorithm.

especially if we optimize for multiple payments down the same path.

How often do you pay the same guy with your credit card or PayPal? Your restaurant, once a day, perhaps? Will the LN compete with Visa for that use? Or even with old bitcoin sans Greg?

You cannot expect that the same path that worked last week will work this week too. Oh, but of course the middllemen in the path will be big bitcoin banks. For this paragraph, at least.

You may be thinking of micropayments. They have been a solution in search of a problem for more than 25 years. They never caught on with centralized servers. Why would they catch on with a horribly more complicated and costly LN?

Every source I've looked at, including the Van Wirdum article I pointed to, is pretty clear that the system is optimized for smaller payments. Larger payments are better with their own transaction. It remains to be seen what the average channel size and duration is.

So you cannot receive your salary or pay the rent with the LN, or buy a new computer, or pick up the tab of a dinner for four... You cannot buy a plane ticket or pay a hotel bill abroad... You cannot buy a pound of weed or 10 grams of lambdacaine...

What will be the point of the LN then?

The LN will only work if it is a closed economy, in which each user receives through the LN pretty much what he spends through it. This is one of the things that the gurus (Luke, IIRC) told me when I pointed out that the channels would run out of funds pretty quickly. If the economy is not closed, channels will have to be closed and re-opened too often.

Suppose for example that you get your salary through an on-chain transaction, open just one BCP with it, and spend most of it over the next month. Then you will need to pay two on-chain fees every month, which (according to the top Gregonomists) may be $120 per year. Per channel. Is there a credit card that charges that much in fees?

Even with a closed economy, you will have nodes that receive far more bitcoins that they spend. The coffee shop has 200 customers who spend $10 per day each through the LN, but the owner only spends only half of that on supplies, salaries, and his own living expenses. So the channels leading to him have $1000 net flowing in his direction every day. The other parties of those channels must open one new channel per day and lock $1000 of their own into it, or open one channel every month and lock up $30'000 into it, etc. To get those coins, they must periodically close their own incoming channels; and these closures will ripple over the network.

So, how can one expect a closed economy if the payments are limited to $20 or whatever? [Metaheuristic] is not a buzzword, it's the word that best describes the type of algorithm I'm talking about.

I can assure you that it is not.

permalinkembedsaveparenteditdisable inbox repliesdeletereply

[–]jstolfi 2 points 4 years ago This just means you switch directions more often.

Meaning: Bob must refuse to receive further payments through the BCP when the net payment from Alice is 90% of the funds that Alice locked into that channel.

What is the difference between that and : "Alice needs to lock up 10% extra as a guarantee against her cheating"?

The whole point of this rebuttal is to get you to acknowledge that you can't.

Limiting the payment to a fraction of the capacity does not prevent cheating; it only raises the bar. The alternatives are still p Y against X. The probability p can still be arbitrarily large depending on the circumstances.

Suppose that the channel was funded with 10 BTC on both sides, and both sides refuse further payments if the clearance is less than 1 BTC. Then one can have Y = 9 BTC, X = 1 BTC. If Bob thinks that there is 15% chance that Alice will fail to react, trying to cheat will be his best option.

It just means that the streaming applications have a lot less overhead

Streaming applications were the obvious use case for micropayments, and yet it did not happen.

But we've already established that the actual overhead is pretty minimal so it's really a digression.

No, we haven't established that at all.

Even if the path is reused multiple times, each of the middlemen will still want to be paid for each LN payment that goes through them.

What do you think will be their minimum fee per payment? $0.01? Then each payment through a 6-hop path will cost $0.05 in fees. That pretty much kills micropayments, doesn't it? [Non-closed economy] means some users will need more settlement transactions. Again, this isn't hard to understand.

Yes, and that is what I wrote. That is why the fans of the LN must provide a scenario with numbers, so that we can simulate and get actual numbers rather than just words like "some users" and "more settlements".

That's why the implementations mix LN and normal bitcoin transactions. Again, this isn't hard to grasp.

What is apparently impossible for you to grasp is that LN users cannot open and close channels all the time, because then the LN will be pointless. It is essential that the net flow through a BCP remains close to zero, for most channels and on the long-term average.

The very heart of this conversation, is so that long term channels can rebalance without settlement. That's what we've been talking about for a trillion words.

So you are saying that I cannot understand what I had to explain to you?

If your intention is to just spend money then a mono-directional channel is more appropriate

But a unidirectional channel cannot rebalance. That is why the LN gave up on them, already in the pre-history of the project.

If bitcoin is so successful that everyone is paying $5 fees just to open channels

Didn't you see fees go up to $5.00 for one simple transaction, just a month ago? Didn't you see Blockstream gurus talking about on-chain fees much higher than that?

A $2.50 fee for an on-chain transaction means that each channel (uni- or bi-directional) will cost $5.00 in miner fees, no matter how many LN payments it carries.

It's not supposed to be closed.

Tell that to Luke and other Blockstreamers.

It's supposed to be a caching layer that helps minimize on chain transactions.

What is that on the moon? It looks like a goalpost --- how did it get there?

permalinkembedsaveparenteditdisable inbox repliesdeletereply

---------------------------------------------------------------------- [–]jstolfi 2 points 4 years ago

permalinkembedsaveparenteditdisable inbox repliesdeletereply

---------------------------------------------------------------------- Thread See new Tweets Conversation DoctorOrrery @DoctorOrrery A lot of people claiming the “lightning network” will save #bitcoin are referring to two completely different ideas and networks, one decentralised, the other centralised. Neither one works, but for very different reasons. (1/17) 🧵 7:31 AM · Mar 14, 2022·Twitter Web App 5 Retweets 2 Quote Tweets 6 Likes

DoctorOrrery

@DoctorOrrery · Mar 14 Replying to @DoctorOrrery First, the decentralised version. This is the original layer 2, first proposed in 2015. It’s meant to solve the fact that bitcoin’s blockchain is slow, expensive and hilariously limited. It has many problems but the two most obvious are pre-funding and spanning (2/17) DoctorOrrery @DoctorOrrery · Mar 14 To use LN you must prefund a channel between you and the counterparty. Eventually this will settle on blockchain, but you want to wait as long as possible to avoid the blockchain fees, so maybe you prefund a month’s worth of transactions. (3/17) DoctorOrrery @DoctorOrrery · Mar 14 If you want to do this for multiple businesses it becomes expensive quickly. Say the cafe, ($100), local eatery ($200), supermarket ($500). This is the opposite of a credit card, you shell out BEFORE spending, but there are still fees (4/17) DoctorOrrery @DoctorOrrery · Mar 14 So you don’t want to open too many channels. That’s fine, you can rely on the network to pay people you don’t have a direct channel with. But that’s problem number 2, spanning. The system has to find the shortest, cheapest link between you and your recipient (5/17) DoctorOrrery @DoctorOrrery · Mar 14 This is a solved problem in graph theory. One solution is Dijkstra’s algorithm. It says a network with N nodes and C connections can be solved in order(C + N log N). Order refers to the amount of computation and therefore time required. (6/17) DoctorOrrery @DoctorOrrery · Mar 14 Trouble is, with a global network these numbers get very large, very quickly. Even at just 100k users, N log N is getting big. Your phone is unlikely to be able to find the shortest route in anything like real time. (The longer the route, the more expensive it is). (7/17)

Last edited on 2022-11-04 19:08:11 by stolfi