Topic: The Lightning Network FAQ - page 8. (Read 32058 times)

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!

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.

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!

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.

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.

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/

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.

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.

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.

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

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

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'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.

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

 

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.

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.

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.

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!

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.

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 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.

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

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)

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

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.

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...

If she doesn't reveal it, Chan's 'payment' doesn't 'get through', as the channel state update script requires Dina to reveal R to receive the payment. Chan commits to the payment, under that condition and can't revoke this commitment either.
Commitment schemes in general, are a pretty great invention for this type of stuff!

Similar thing: Chan only actually 'gets the payment' from Bob if he reveals R.
After that, 'turtles, all the way down'.

The 3 minutes of this video starting at 13:15 explain it quite well:
https://youtu.be/yKdK-7AtAMQ?t=796

I'm reading lnbook - onion routing, and I feel that the authors, while they've done a great job, don't make this clear enough. My question is: How do you ensure transaction finality with onion routing?

Alright, so let's take the same example. Alice wants to send 100,000 sats to Dina, and Bob & Chan are intermediaries.

 1. Dina sends Alice her secret R's hash (H).
 2. Alice tells Bob that if he pays Chan 100,100 sats, she'll pay Bob 100,200 sats if he gives her R.
 3. Bob tells Chan that if he pays Dina 100,000 sats, he'll pay Chan 100,100 sats, if Chan gives him R.
 4. Chan pays Dina 100,000 sats, if Dina gives him R.

Now, this is the step I don't quite understand on how we eliminate trust. Once Dina receives the 100,000 sats, what forbids her from denying to reveal R to Chan?

Secondly, if Chan gets the secret R, what forbids him from not giving it to Bob (so he can later give it to Alice)?

Thirdly, as far as I can tell, the user who firstly moves money is Chan (to Dina). Then, Chan expects from Bob to get the 100,100 sats. What forbids Bob from denying to give it to him?

I'm 99% sure that I lose it when it comes to the OP_SHA256 H OP_EQUAL scripts. How do Alice, Bob, Chan and Dina eliminate trust, ensure that R will reach Alice, and all that with every sat being sent rightly? Is there a chance the money "get stuck" in the middle?

This is also impressive: https://bl.ocks.org/tyzbit/d1c83732d2767bb955125d41f5921888