[Klathmon]

2 isn't true at all, routing isn't nearly that complicated and I don't know why everyone thinks it is. Most routes are expected to be under a few hops. But regardless we will find out soon as the number of nodes on the live system is very rapidly growing.

3 doesn't really apply, as channels can be used as middle hops to rebalance.

If I give money to you for a good/service and drain my channel. Then I buy more Bitcoin from coinbase, coinbase can route that BTC to me through you to rebalance our channel so it is all on my side.

4 isn't true, as "locking the BTC up" is basically making it available. Would you consider depositing cash into a checking account "locking it up"? Because that's the equivalent here. But also locktimes are normally a few days.

[lalaland1125]

2. Where is the evidence of this? Sure, routing can be easy and short if it's centralized and the number of hops is small. But, if it's centralized, then what's the point of using Bitcoin? Where is this mystical routing algorithm that will work in the presence of constant capacity changes over a decentralized network?

3. The issue here is that the flow for all channels across the entire network needs to be about balanced for things to work out properly. Once someone starts either net accumulating bitcoin or net dispersing bitcoin, then there will be problems somewhere on some link.

4. I can take money out of my checking account at any time at no expense.

[Klathmon]

About 2, like I said we should know soon if it will work. I just don't think that most channels will be updating as quickly as you think, and even if they are, a channel will know of someone is trying to route through it, so it can avoid trying to route another tx for the duration of the first.

3. Fees can and will help balance things out. If a channel is really unbalanced, negative fees can strongly incentivize rebalancing in many cases. If it starts to get unbalanced again, fees can increase to help reduce the speed that it unbalances.

4. You can also take money out of LN at any time (assuming your counterparty I cooperative). Only in the case of non-cooperation do you need to wait for locks to expire, and in that case you get ALL money from both sides of the channel, and need to wait for the lock to expire.

Id love it if my bank could give me 2x my money if it takes more than 3 days for me to get my money...

[JumpCrisscross]

> You can also take money out of LN at any time (assuming your counterparty I cooperative)

This isn’t what people mean when they imply liquidity. Needing consent and being able to unilaterally demand cash are different domains. The former is e.g. a holding in a fund or coins in a LN, the latter is a consumer checking account.

> Id love it if my bank could give me 2x my money if it takes more than 3 days for me to get my money

Or lost 90%. We had this in the era of free banking, i.e. pre Federal Reserve. We then split the speculation and transfer functions of our financial system and ended up better for it.

[Klathmon]

>This isn’t what people mean when they imply liquidity. Needing consent and being able to demand cash are different domains.

I don't understand what you are trying to say here. You don't need "consent" if you want to wait the 3 days, but if you get "consent" from your counterparty you can get it instantly. 3-days is about as fast as ACH. But if you want, you can feel free to open channels with shorter locktimes if needed.

>Or lost 90%. We had this in the era of free banking, i.e. pre Federal Reserve. That history is one Bitcoin is presently replaying.

But you can't lose money if LN is working correctly. The whole idea is that you sign the transactions saying "if this is broadcast under these conditions, you get all of my money" when you open the channel. It's literally not possible to fractionally lend on LN, because all money MUST be there, and signed, for you to use it.

I've had conversations with you before, and I'm fairly sure you don't understand the basics of Bitcoin as you keep repeating these things as fact, so I'm going to stop replying here. Please make an effort to understand it before you start denouncing it. Or at least explain why you think these apply to the conversation in ways that someone like myself who isn't well-versed in traditional banking systems but understands Bitcoin technically will understand.

[JumpCrisscross]

> if you get "consent" from your counterparty you can get it instantly. 3-days is about as fast as ACH

You said, like a checking account, one “can also take money out of LN at any time.” I clarified that when people say “take money out at any time,” they mean unilateral liquidity. You can unilaterally demand cash or an instantaneous Fedwire transfer, the latter which costs 3 to 69 cents [1] (though some banks heftily upcharge this service), against your checking account balance. It takes a good deal longer to settle a LN balance (theoretically).

TL; DR The Lightning Network has some neat features, but pitching its liquidity as analogous to a checking account’s is disingenuous.

> you can't lose money if LN is working correctly

This applies to anything. In finance, things never work correctly because someone, somewhere, can be trusted to be an arsehole.

> It's literally not possible to fractionally lend on LN

The number of Americans who have lost a single U.S. dollar to this threat since the FDIC was formed is basically zero. The number of Americans who have nuked substantial fractions of their net worths speculating on Bitcoin is significantly greater.

[1] https://www.federalreserve.gov/paymentsystems/fedfunds_corep...

[wan23]

> This isn’t what people mean when they imply liquidity. Needing consent and being able to unilaterally demand cash are different domains. The former is e.g. a holding in a fund or coins in a LN, the latter is a consumer checking account.

Is it really true that you can get easily the money out of your checking account if your bank declines to give it to you? In a traditional bank account, it is possible to place a hold on an account for various reasons, mostly when compelled by the government.

[JumpCrisscross]

> In a traditional bank account, it is possible to place a hold on an account for various reasons, mostly when compelled by the government

The traditional hierarchy of liquidity goes first cash, then Treasuries then checking accounts. Checking account balances (i.e. senior, registered claims on a bank) are junior to the first two (i.e. senior, registered claims on the U.S. Treasury and senior, unregistered claims on the Federal Reserve, respectively) for the reason you specified. I still contend a checking account will more reliably produce immediately-available funds quicker than a LN "deposit," even if one is a criminal.

This sidelines into why I believe illegal markets are the only place blockchains have a shot at being a currency. Shadow economies are substantial, between $1 and 3 trillion in the U.S. alone [1]. It's a different pitch from "replace the U.S. dollar," but it's more realistic. (I am not advocating anyone do anything illegal.)

Stepping back, it's pertinent to look at the Two Generals' Problem [2] which Satoshi's paper solved. It's a problem of exchanging information, not value per se. Blockchains are here to stay, but not--in my opinion--as currencies. Libor on a blockchain or legal documents "Docusigned" on a blockchain are far more compelling than "we'll make our light-speed payments system less reversible and better for illegal activity". They're also use cases which become difficult to justify if the "tokens" underlying them rise in value.

[1] http://www.imf.org/en/Publications/WP/Issues/2018/01/25/Shad... Table 4, page 11

[2] https://en.wikipedia.org/wiki/Two_Generals%27_Problem

[freejulian]

Lightning uses the same routing algorithm as tor — it’s an onion router. It has the added benefit of no one in the network knowing where transactions are from or whom they’re to.

With regards to channel capacity — fees in lightning are proportional to the amount of the transaction. If you are sending a transaction which consumes a large amount of capacity, you pay a high fee. Note how this is a fundamental difference from onchain transactions where fees are proportional to the amount of block space used.

Lightning is more akin to an atm. You pay a fee to take out cash, but you can then transact instantly all day with nearly no fees.

[philipwhiuk]

Tor has a centralised list of exit nodes.

[Klathmon]

which doesn't apply to tor hidden services, which work fine without an exit node.

[shazow]

Sounds like you're familiar with the tech, maybe you could answer a couple of questions:

> If I give money to you for a good/service and drain my channel. Then I buy more Bitcoin from coinbase, coinbase can route that BTC to me through you to rebalance our channel so it is all on my side.

Could you point me to details about how cross-channel rebalancing happens?

Since lightning network channels are purely 1:1 (per the whitepaper); say you drained your channel to me, how does your channel with Coinbase allow you to route BTC to our channel without reopening a channel (requiring on-chain transactions)?

The whitepaper mentions hops, but I can't find any details on how they actually work.

> But also locktimes are normally a few days.

Does that imply that every channel needs to make an on-chain transaction every few days to reopen/keep the channel open?

[Klathmon]

>Could you point me to details about how cross-channel rebalancing happens?

Lightning transactions are less like TCP packets, and more like water in a pipe. If I put 1 ml of water in a pipe full of water, 1 ml comes out the other end, but it's not the same water.

It works like this:

I can give you 1 apple, but I contractually obligate you to give 1 apple to my friend Bob, and if you don't you get penalized. You won't actually give Bob the apple I gave you, you'll give him another apple that you have, and if you don't know exactly where bob is, you could give an apple to someone else, telling them to eventually give an apple to bob "or else". (in LN, the "or else" is actually cryptographically secure pre-created transactions)

Because of this, each 1:1 channel is actually a network of 1:1 channels that can move in both ways.

In my first example, there was an unwritten implication that you would have a connection to coinbase somehow through another channel. So if I paid you 1 BTC for something, and you have a connection with coinbase (either directly, or through another channel), then if I buy from coinbase they can send that money "through" you to recharge our channel, without you really "spending" any money. And you are more than happy that happened, because now I can buy more from you directly through our channel, so you might incentivize that kind of routing by setting an extremely low, or even zero, or even NEGATIVE! fee.

>Does that imply that every channel needs to make an on-chain transaction every few days to reopen/keep the channel open?

No, locktimes only come into play in the case of non-compliance. If we have a channel with a 3-day locktime, on day 2 we can agree to re-up our lock for another 3 days (really at any time we can), we can also agree to close it right now if we want, all off the blockchain. Only when you either try to cheat, or become non-responsive do locktimes come into play.

[shazow]

Sorry, I didn't mean in layman metaphors but the actual mechanics. (I am technical and fairly familiar with Bitcoin, I'm just having a hard time convincing myself from reading the Lightning whitepaper and I'm hoping to find some alternative explanations that are clearer.)

Like what kind of transactions/operations need to happen between nodes for two channels to get rebalanced?

> No, locktimes only come into play in the case of non-compliance. If we have a channel with a 3-day locktime, on day 2 we can agree to re-up our lock for another 3 days (really at any time we can), we can also agree to close it right now if we want. Only when you either try to cheat, or become non-responsive do locktimes come into play.

Right, I understand that it's for non-compliance, that's why I was assuming that this part has to happen on-chain.

Aren't timelocks enforced on chain? How can we agree to extend our timelock without committing that agreement to the blockchain?

I understand that the premise of timelocks is that if there's a conflict, the channel collapses and the timelock buffer period allows the victim a period to claim restitution (hence needing to stay online or have a service do it on their behalf).

[Klathmon]

>Like what kind of transactions/operations need to happen between nodes for two channels to get rebalanced?

So "rebalancing" is kind of a word for a side-effect of normal routing.

It's all based on fees. So if you have a channel with "the network" (either through 1 or more channels to a big hub, or some other way), and I have a single channel with you, then another channel with "the network".

Our channel started off with .5 BTC from each of us. Then I paid you .4 BTC so the channels are:

You: .9 BTC, Me: .1 BTC.

Nodes broadcast fees, so you would broadcast that for me to send money from me to you (either directly, or through a "hop"), it will cost 20 satoshis. But you can also broadcast that for someone to send money the opposite direction (from you to me), it's free right now. Someone that wanted to pay a 3rd party unrelated to us would try to find a route that went from you to me then to the rest of the network.

So really "rebalancing" is just incentivizing someone else to rebalance your channel by exploiting their selfishness and want of low transaction fees and to include you as part of a hop. Fees can even go negative, which would make it super beneficial for someone else to include your channel in their transaction (even if it's out of the way, or doesn't serve any real purpose) to get a bit of money from it!

Who actually broadcasts the fees can be found by looking through popular node software (each node only broadcasts one direction of the channel, and I don't remember which it is right now), as well as the broadcast system (which I genuinely don't know off the top of my head).

>Aren't timelocks enforced on chain? How can we agree to extend our timelock without committing that agreement to the blockchain?

Yes and no. They are "enforced" on chain in the sense that they can't be accepted into a block until a specific block number. But they aren't ever broadcast to anyone else until you are ready to use them. In essence all LN transactions are created, but kept secret until ready to be used. The whole concept of LN relies on the fact that if we make a transaction but never broadcast it, did it really happen? If you and me agree to make a new transaction saying "this expires in 3 days from right now", technically the original transaction is now valid once 3 days pass from it, but if you try to broadcast the tx that forces all the money to you, I can broadcast the transaction that proves that we did something else after that (our second "update the locktime"), and then gives all the money to me.

Every time we do something to transact, we also create a set of transactions that serve as proof that the old transactions are in fact "old" and shouldn't be accepted, and if anyone tries to broadcast them, we can invalidate them (and enforce a "penalty" to dissuade anyone from trying to cheat).

[IncRnd]

That's fine, but if #1 is true, Lightning is far from workable.

[Klathmon]

#1 isn't strictly true, you don't need to be "always online", only online at some point within the locktime (normally 3 days right now).

You can also hand your "revocable delivery" transactions to a 3rd party (or multiple 3rd parties) who can monitor and broadcast them in the case of cheating, but can't actually spend any of your money themselves.

So you could have a group of people watching the blockchain always online that can punish non-compliance, but you yourself are only online when you want to transact.

[lalaland1125]

Of course, someone could pay off that third party to stop watching your channel.

[Klathmon]

And you could have multiple "watching" services that can prevent any one "watching" service from betraying you.

Obviously controlling your own "watching" system is most secure, but the vast majority of people aren't going to want to do it themselves.

And again, if the biggest worry is that someone will pay off multiple "watchers" then publish a previous version of a channel to steal money from you and hope that your proper node isn't online at any point during the locktime (or DoS your node to prevent you from seeing the bad transaction) to punish the thief and "steal" all the money back. I think we are doing a pretty good job!

[IncRnd]

According to you own words, the answer to poor transaction times is to make transactions less reliable and to introduce centralization.

I have to ask the million dollar question. Has this been threat modeled?

[Klathmon]

I don't know where you got all that from!

Transactions in LN are just as "reliable", and don't introduce centralization in any meaningful way.

As for the "modeling", I'm not sure what you want. The threats have been outlined in the whitepaper, and successfully tested in some capacity on testnet. And now they are being tested as lightning network is being rolled out on mainnet. There might be some formal "threat modeling", but i'm not familiar with what that would even look like or mean.

No better way to "threat model" than to try it out in a hostile environment where bad actors that have some kind of "exploit" can already use it to gain BTC.