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.
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.
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.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.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...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 ??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.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 nowBitcoin 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 agopermalinkembedsaveparenteditdisable 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 LikesDoctorOrrery
@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