The Lightning Network FAQ

[BlackHatCoiner]

which if there is a break in the route. like if bob goes offline chen doesnt get paid

It doesn't matter what Bob does after he's given Chan the script. Bob gives him the money under that one condition, that is finding a number that returns TRUE once OP_HASH160 <h> OP_EQUALVERIFY is executed. It is commonly said that the money go backwards (Chan -> Dina, Bob -> Chan, Alice -> Bob), but the money actually go forwards (or precisely, the ownership of the money). What does go backwards is the satisfaction of each node's condition.

[1713481707]

1713481707

[1713481707]

1713481707

[1713481707]

1713481707

[n0nce]

~ snip ~
and now you all know that Dina gets paid using chens money

which if there is a break in the route. like if bob goes offline chen doesnt get paid
thus alice keeps her funds too because she to doesnt pay bob. and now Dina has been paid walking off pretty happy to get free money and alice walks off happy knowing dina accepted payment for goods designated to go to alice, without alice paying..
thanks chen you paid for alices goods

That's actually wrong. As Bob already gave Chen the commitment to pay, when Chen can present the secret. If Bob goes offline, Chen publishes this commitment (and secret) on the blockchain and gets his funds. This effectively closes the channel between the two.

along with blackhat having issues of missing funds where he cant find the key to spend it via a simple methods.. and needing to hack his own wallet to find the keys(facepalm)

He actually did get the funds back. No 'hacking', just usage of the binaries as designed, just restored his node from backup files.
I unfortunately wasn't able to give him the correct command right away, as I have not had to attempt a restore yet.

yep LN is even more riskier and flawed than a pegged sidechain like Luna

There's less trust than in a sidechain, but more setup and overhead in terms of running a node and managing channels. Every L2 solution has its own advantages and drawbacks.

but its good you guys are now seeing, experiencing the flaws instead of the utopian dreams of XXXevent s earning XXprofit messages you previously only wanted to talk about.

It's definitely been helpful to go through the whole restore process on a real mainnet Lightning node. It seems to work fine if you know how, though!

bitcoin works. no stress. just put in the destination address and amount. and wait for confirm.. done..
imagine a average joe using LN. like a el salvador citizen using LN last year as the backnobe of chivo.. ooopps. LN failed thousands of times for thousands of people

do you now see why LN is not a "solution" or better than bitcoin...

Have you run the numbers on how many people can realistically transact on Bitcoin L1 at any given time? If a single country were to start using Bitcoin for all financial transactions, we would definitely have a harder time using it! Or at least, it would get a whole lot more expensive.

In general, the blockchain sadly doesn't scale, as it keeps every single (micro-)transaction on this eternal, decentralized ledger.
That's where Layer 2 solutions shine; though, as I said, they all have their advantages and disadvantages. There's no denying that.
In your example, I'd criticize the 'forced' / non-organic introduction of Lightning and the infrastructure (network of Lightning channels) that subsequently wasn't ready for it.
There's also a non-zero chance of deliberately making the initial release 'fail' to have an excuse for switching to a more centralized model (and have more control / give people less privacy); but that's pure speculation.

[CryptKeeper]

The LightningNetwork is at a capacity of 5,000 BTC!

 

[BlackHatCoiner]

5,000 BTC might seem a lot, but they're less than 0.05% of the total coins in circulation. I want to remain optimistic that this will gradually increase, and at some point it may increase exponentially. Just as a low-hanging fruit, we should wait and see.

I can give you a more detailed explanation on why that's necessary once you confirm that it has worked.

I'm just reminding this, because I honestly never understood what was the purpose of all this hassle and bustle. Funds' restoration should be rather trivial thing to do.

The software returned the private key in hexadecimal, not in WIF. This is why I made this: https://github.com/AngeloMetal/BitcoinJavascripts/blob/main/wif.js. For anyone interested, you're just feeding it a number (in hex), and it returns the private key in WIF. I couldn't find such program, didn't trust any site that does this conversion, so I just wrote it myself.

[cygan]

came across this article today, which explains offline Bitcoin lightning payments through the implementation of the new feature/upgrade eclair (trampoline relay) and wants to make it possible in the future

Éclair #2435 proposed a so-called trampoline relay that can temporarily hold funds until a node restores its internet connection. These nodes might include tablets, devices that automatically sleep, or any Lightning node with an unreliable internet connection.

Developers merged Éclair #2435 as an optional update for Lightning users. The developer-oriented Bitcoin Optech Newsletter describes it as a basic technology for asynchronous payments that enables trampoline relays. This basic implementation will allow experimentation.

https://protos.com/offline-bitcoin-lightning-payments-will-soon-be-possible/
https://github.com/ACINQ/eclair/

[LoyceV]

Éclair #2435 proposed a so-called trampoline relay that can temporarily hold funds until a node restores its internet connection. These nodes might include tablets, devices that automatically sleep, or any Lightning node with an unreliable internet connection.

https://protos.com/offline-bitcoin-lightning-payments-will-soon-be-possible/

My first thought after reading the link: who runs a LN node on their phone? And would it really be that bad if LN is only available when both parties are online? I have a client on my phone, and it works fine if I use it. But most of the time, it won't be online, so I don't think it can receive a payment unless I run the app. But for LN to become mainstream, and for people to use their own node, it should indeed be possible to receive payments even when it's not online all the time, without resorting to a custodial wallet. And it should indeed be possible to run your own node on your phone to use it all day long.

I don't understand the technical part (like most of LN), but if they can pull this off, it may bring LN one step closer to mass adoption.

[BlackHatCoiner]

One thing that is missing is a user-friendly and safe method to back up your Lightning node. Unfortunately, and oppositely to layer 1, you can't back up your wallet in a piece of paper. It is required to have both the hsm_secret (which can be represented as a seed phrase, and recovers on-chain funds), and lightningd.sqlite3, which is the database of commitment payments and revocations.

You need to back up the latter every time you make a payment, and hence, it has to be done automatically. One option is to have a separate external device, along with the blockchain hard drive, that will just keep the back up, in case the hard drive stops working. The problem is that, even if you do this, you can't restore your funds somehow, because you need to access the Bitcoin Core. Hard drive not working means blockchain not syncing. But access to Lightning is provided given that blockchain is syncing.

What happens in that case? Do I have to wait until it re-syncs the entire chain from a new hard drive? In poor connection areas, or in poor CPUs this can take up to 2 weeks. Recovery of funds from uncooperative channel closure might not be sufficient, even if it's 2016 blocks, security speaking.

[NotATether]

One thing that is missing is a user-friendly and safe method to back up your Lightning node. Unfortunately, and oppositely to layer 1, you can't back up your wallet in a piece of paper. It is required to have both the hsm_secret (which can be represented as a seed phrase, and recovers on-chain funds), and lightningd.sqlite3, which is the database of commitment payments and revocations.

In the case of the latter file, it can be recreated as a series of SQL statements, but I don't know how long that can be. It is more compact than moving around the SQLite file directly, and is less susceptible to corruption.

Believe me, database corruption from sudden shutdown is real - I had to rebuild my RPMDB on Red Hat one time because it's SQLite database was corrupted by a sudden shutdown.

Back to the point:

From this we can compact the size even more by compressing the file (gzip, or LZMA/xz). Whatever is left, can be exported as a series of BIP39-style mnemonics, and we just compute and append a checksum of that, padding the output with zeroes if necessary. And we put a four-byte int at the beginning that specifies the length of the compressed data - the checksum is of constant length, and the rest is zero padding.

[dkbit98]

I found new interesting exchange on Lightning Network called Kollider, and they introduced Kollider Synthetic Stablecoins Euro and USD that are backed by Bitcoin.
There is Light and Pro version of Kollider exchange, and I didn't find any information about them asking any kyc verification, and you can log in with Lightning LNURL-auth.
I am going over Docs page and I see there is Karma feature for unlocking hidden stuff and for getting discounts.
They are also working on Kollider wallet, that is currently in alpha stage, but it works for quick swap, send and receive.
Anyone tried Kollider so farand what do you think about it?

Website: https://pro.kollider.xyz/
Docs: https://docs.kollider.xyz/docs/
Wallet: https://pay.alpha.kollider.xyz/

[CryptKeeper]

[PrimeNumber7]

One thing that is missing is a user-friendly and safe method to back up your Lightning node. Unfortunately, and oppositely to layer 1, you can't back up your wallet in a piece of paper. It is required to have both the hsm_secret (which can be represented as a seed phrase, and recovers on-chain funds), and lightningd.sqlite3, which is the database of commitment payments and revocations.

You need to back up the latter every time you make a payment, and hence, it has to be done automatically. One option is to have a separate external device, along with the blockchain hard drive, that will just keep the back up, in case the hard drive stops working. The problem is that, even if you do this, you can't restore your funds somehow, because you need to access the Bitcoin Core. Hard drive not working means blockchain not syncing. But access to Lightning is provided given that blockchain is syncing.

What happens in that case? Do I have to wait until it re-syncs the entire chain from a new hard drive? In poor connection areas, or in poor CPUs this can take up to 2 weeks. Recovery of funds from uncooperative channel closure might not be sufficient, even if it's 2016 blocks, security speaking.

You can backup your private keys (hsm secret) on a piece of paper. This is what must remain private, as it will allow anyone with access to this information to spend your coin via LN.

A current listing of commitments and revocations needs to be backed up, but the damage resulting from this information being made public is limited to your privacy. This means that you can backup this information in the cloud without risking the theft of your coin.

In the case of the latter file, it can be recreated as a series of SQL statements, but I don't know how long that can be. It is more compact than moving around the SQLite file directly, and is less susceptible to corruption.

There are a very limited number of operations, so you don't need the actual SQL statements. All you really need is a CSV file (or series of CSV files) that contain enough information needed to create the SQL statements. For added redundancy, you can also have a script that parses your CSV file(s) and converts the information into a SQL lite DB, as part of your backup.

[darkv0rt3x]

Hello.

Anyone here uses to rebalance channels manually from the command line in CLN?
What have been your experience with fees chosen? I have performed my last rebalance a couple of weeks ago with maxfeepercent=0.025 but right now seems that not even maxfeepercent=0.065 is enough. I'm using 1800 seconds as the time frame for the rebalance to be running!

[n0nce]

Hello.

Anyone here uses to rebalance channels manually from the command line in CLN?
What have been your experience with fees chosen? I have performed my last rebalance a couple of weeks ago with maxfeepercent=0.025 but right now seems that not even maxfeepercent=0.065 is enough. I'm using 1800 seconds as the time frame for the rebalance to be running!

I do rebalance from the command line and don't usually specify a fee rate. Sometimes works, sometimes doesn't, then I just try again later.

[darkv0rt3x]

Hello.

Anyone here uses to rebalance channels manually from the command line in CLN?
What have been your experience with fees chosen? I have performed my last rebalance a couple of weeks ago with maxfeepercent=0.025 but right now seems that not even maxfeepercent=0.065 is enough. I'm using 1800 seconds as the time frame for the rebalance to be running!

I do rebalance from the command line and don't usually specify a fee rate. Sometimes works, sometimes doesn't, then I just try again later.

I always use fee rate. Always try to start from something like 0.025 or so and work the wya up. And it usually works after some time, however, this time is not working at all for the past 3 days I've been trying. And tbh, I didn't want to go over 0.07.
I think this value is 0.07%, meaning 0.07 / 100 of the amount being transferred but it's still a consierable amount taking into account the fees we usually do with forwarded payments!

[Rath_]

IMPORTANT: LND users should update their nodes to either v0.15.4-beta or v0.14.5-beta. You can learn more about the fixed vulnerability here.

I'm just reminding this, because I honestly never understood what was the purpose of all this hassle and bustle. Funds' restoration should be rather trivial thing to do.

Sorry about that! I have been extremely busy with my new job. I will try to find some spare time this weekend!

[CryptKeeper]

[darkv0rt3x]

I think I found (actually someone sent me) a very interesting article about how to improve success in LN and our nodes in terms of forwarding payments!

Read here and let me know your opinions:
https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/

I quote the abstract just to increase the interest in the read:

Abstract: Valves are an important tool for flow control in fluid or gas networks. We investigate the possibilities to set up valves on the Lightning Network to improve flow control and reduce expected payment failure rates. We show that good asymmetric choices for `htlc_maximum_msat` on a channel can reduce the expected payment failure rate significantly. We assume that the potential benefits from carefully selecting `htlc_maximum_msat` as a valve seem not to be fully exploited by routing node operators and Lightning Service Providers yet to optimize their flow control and improve the reliability of their channels. We analyze the power of valves on the Lightning Network mathematically by using Markov Chains. These can be used to model the uncertainty about the liquidity in a channel that arises from drain in the depleted channel model. Using these techniques we show theoretically that properly using valves may statistically lead to a more balanced channel and expected payment failure rates drop from two digit numbers below 3%. We provide two experimental algorithm ideas and encourage Lightning node operators to investigate the potentials from utilizing this tool that is already being shipped with the protocol.

[darkv0rt3x]

Anyone interested in opening a dual funded channel (CLN) depending on the capcity?

In the meantime I decided to open a channel to someone! Offer is off! :p

[BlackHatCoiner]

In which manner do you guys back up your C-Lightning node? I've thought of connecting a separate USB to the Raspberry Pi, but I haven't find the time, and the money I'm risking aren't much. I've backed up the hsm_secret obviously, because it can be done on paper. Is encrypted cloud back-up an option? I've thought of sending my channel states encrypted to some cloud service as well; sometimes, you trust the service more than your hard drives.

The backup plugin doesn't seem suggested according to the dev team:

This has the advantage compared to the backup plugin below of requiring exactly the same amount of space on both the main and backup storage. The backup plugin will take more space on the backup than on the main storage. It has the disadvantage that it will only work with the SQLITE3 backend and is not supported by the PostgreSQL backend, and is unlikely to be supported on any future database backends.

[n0nce]

In which manner do you guys back up your C-Lightning node? I've thought of connecting a separate USB to the Raspberry Pi, but I haven't find the time, and the money I'm risking aren't much. I've backed up the hsm_secret obviously, because it can be done on paper. Is encrypted cloud back-up an option? I've thought of sending my channel states encrypted to some cloud service as well; sometimes, you trust the service more than your hard drives.

I do it as described in my guide.
The disk is just a local NAS network share (redundant), and you shouldn't upload to a cloud, because...

Do note that files are not stored encrypted, so you should really not do this with rented space (”cloud storage”).