Ledger Live stores your accounts' master extended public keys, so it obviously knows the balance of your accounts even if your device is not connected. Since it knows your balance, it can tell you how much you can send.


You would probably be prompted to connect a different device.

         
Yes, you should now be 100% certain that you can control those coins. In fact, the ability to add the account you are talking about should have been a sufficient proof.                                                                                                                                                                                                                                    

My Lightning node will be down for a couple of days. I decided to move from a Raspberry Pi to a normal server. Unfortunately, LND does not support moving the channel database between different architectures, so I had to close all of my channels. I will reopen them gradually once I have configured my new server.

Bitcoin Core 0.21 introduced Torv3 addresses and made them default. BIP155 was needed so that other nodes could gossip Torv3 addresses across the network. Unfortunately, since it was introduced in the same release, old nodes won't propagate your address.

I have been experiencing the same problem since I have set up Tor on my node. A few days ago, I decided to manually connect to a bunch of nodes from this Reddit thread and I finally started getting incoming connections. Supposedly, I was not the only person to do that and my address propagated quickly across Torv3 compatible nodes. Use the following command to connect to some node.

bitcoin-cli addnode address onetry

You can replace "onetry" with "add" if you want to add those nodes to your local list. "onetry" worked fine for me. You can also connect to my node: 6gk54wewlpa54psxx2a2jprds7jkdjmwdjvy42qjaybcjbhjdvda66ad.onion

Fortunately, a lot of node operators might decide to update their nodes soon due to the taproot soft fork support which has been introduced in the recent 0.21.1 update.

Yes, it is. It takes just a few seconds for the Ledger Live to fetch your balance from their servers.


Ledger Live can do that only if your device is unlocked. So, if you delete accounts associated with your hidden wallet, someone would have to know your passphrase to be able to add those accounts again in the Ledger Live.

Aren't you worried that your VM backup might not reflect the latest state of some channel? Keep in mind that channels are updated not only when you send/receive transactions but also when you route payments.

By the way, the fee of the latest commitment transaction is periodically updated. I have two channels which have never been used. The first one was updated 19 times and the other one 31 times. I am not sure what would happen if I launched my node with an old backup of my channel database. Would a different fee be enough to trigger an uncooperative channel close?

I would like to point out a very important thing for node operators. In this post, I talked about what could possibly happen if you lost your channel database and decided to use a Static Channel Backup (SCB). Long story short, you should close channels which are offline for extended periods of time. Otherwise, you might not be able to get your coins back if your node's hardware ever failed.


I originally planned to use c-lightning, but I really liked how well LND integrates with Zap. I can easily spend coins from my node and open new channels without using a command line. Spark Wallet supports c-lightning, but it looks less appealing to me. I have used both LND and c-lightning before and I had a very similar (good) experience.

It's been available for about 3 years.


The lowest possible fee is 1 sat/vbyte (most nodes reject values lower than that). As for right now, you need to pay about 12 sat/vbyte to get your transaction confirmed in the next block. By the time you decide to send your coins, this value will have changed. The total fee depends on the size of the transaction. The more inputs and outputs you have, the more you are going to pay.

A transaction with 1 native SegWit input and 2 native SegWit outputs weights 141 vbytes. So, if you selected 12 sat/vbyte, you would pay a 0.00001692 BTC fee.


No one can be completely certain if you are sending all those coins to yourself. You can always use a mixing service if you are concerned about your privacy. For example, if you use ChipMixer, you will get a private key to an address with coins which were deposited sometime in the past. However, with your reasoning, it doesn't make sense much sense anyway.

You very likely imported some kind of backup which allows you only to close that channel. How did you exactly export your Lightning channel?

By the way, you should be extremely careful when using the same Lightning Network channel on more than one device. In fact, you should never do this. At some point, any of your devices might have an outdated state of the channel which would force the other party to close the channel uncooperatively.

Apart from what pooya87 has already said, there are some edge cases which not many people know about. For example, if you lose your channel database, you need to initiate DLP (data-loss protection) in order to get your funds back. You can do it as long as you have a backup file which was generated after you have opened all of your channels. That file contains all the necessary information you need to reestablish the connection to your peers and ask them to close your channels. Here are the possible scenarios:

1) Everything goes well and all of your peers immediately broadcast the latest commitment transaction of each channel. You will very likely get your funds back after 144 blocks have been mined.
2) Some peer takes the risk and closes the channel with an old commitment transaction. You cannot broadcast a penalty transaction because you lost all of your data.
3) Some peer is offline and cannot respond to your request. Unless they come back online, the funds are locked up in that channel which means that they are lost in a limbo.


That's why keysend should be required by the campaign manager. Unfortunately, it looks like it is supported only by LND and c-lightning so the participants would have to run either of these implementations 24/7.


Each invoice contains a hashed payment preimage. In order to claim the payment (or HTLC to be more precise), the preimage needs to be revealed to the payer. Thus, the campaign manager could prove that the payment has been claimed by revealing both the invoice and the payment preimage.


Last week, the participants got paid over 0.19 BTC in total. Currently, most nodes reject channels larger than ~0.1677 BTC so CM would have to either open multiple channels or a single channel to a large HUB which supports Wumbo.

This website should give you a rough idea what's currently going on with the mempool. As for how you can use it:


Note that both Electrum and that website use "sat/vbyte" now even though Electrum displays "sat/byte".

No, you need to create a new wallet. Keep in mind that transactions sent from your current (multi-signature) wallet will be more expensive than as if you were using a standard wallet. You should move your funds once the transaction fees go down to a reasonable level.

I am not aware of any Discord servers, but I have been in this Telegram channel for quite some time now. It is surprisingly active, but not on-topic all the time.


I think that you might have missed his point. I missed some LN threads, which I could have answered, because I mostly browse "Development & Technical Discussion" and "Bitcoin Technical Support" boards. If there was a dedicated section then there might be a higher chance of getting accurate answers just like you could get them on some LN related Discord/Telegram channel.

Dwa tygodnie temu pojawiła się nowa aktualizacja Electrum, która wprowadziła parę usprawnień do implementacji Lightning Network. Wprowadzono "multi-part payments", które umożliwiają podzielenie płatności na mniejsze części i wysłanie ich przez różne kanały, co zwiększa szanse na powodzenie płatności.

Zmienił się też trochę domyślny mechanizm otwierania kanałów. Nie trzeba już czekać aż nasz portfel pobierze informacje o wszystkich dostępnych węzłach i kanałach. Przy domyślnych ustawieniach, Electrum pozwala na otwarcie kanału tylko z trzema specjalnymi węzłami, które oprócz przekazywania płatności dalej, zajmują się znalezieniem odpowiedniej ścieżki dla płatności. O ile pobranie całej mapy sieci Lightning trwa teraz kilkanaście/kilkadziesiąt sekund, tak w przyszłości może trwać to znacznie dłużej.

Aby móc otworzyć kanał z dowolnym węzłem, należy pobrać mapę sieci poprzez zmianę odpowiedniej opcji w ustawieniach. Zaktualizowane instrukcje możecie znaleźć w oryginalnym wątku.

Sure. I will send you a private message in a moment.


Electrum might not have been the best choice for the first time, but you simply got extremely unlucky with the suggested peer. If you had opened a channel to a different node, I am quite sure that you would have had a much better experience. I would suggest you using either BlueWallet or Phoenix Wallet next time. I have been running an LND node for quite some time now and I haven't run into any major problems, but it's quite a bit more complicated than using Electrum.

If you decide to close the channel, I would appreciate if you could let us know here how much you ended up paying. I hope that the cooperative close will result in significantly lower fees.

That's very likely. As far as I remember, even if you select "Close channel" instead of "Force-close channel", you won't be able to specify your own transaction fee. I believe that a cooperative close (the first option) should use a much lower fee, but I am not that familiar with Electrum implementation of the Lightning Network so don't take my words for granted

I have just found a similar case to yours on the Internet. It looks like some other people had the same problem with this particular node.

It took me a while to figure out what could possibly be wrong.

Since I don't have any open channels in Electrum at the moment, I experimented a bit with my LND node. I have recently spent 0.00591658 BTC on a channel opening transaction. Right now, I can spend 578 053 satoshi through that channel and its reserve is 5916 satoshi. 578 053 + 5916 = 583 969 satoshi, so it turned out that I was also missing some coins. I found an additional parameter called "Commit Fee". This value tells how much money you are going to pay for the closing transaction fee if either you or the other party broadcasts the current commitment transaction (a transaction which records balances in the channel). In my case, it was equal to 13 605 satoshi. 578 053 + 13 605 = 591 658 satoshi. Great!

So, it looks like both you and the other party signed a commitment transaction with an unnecessarily high fee. I am not sure why that happened - transaction fees are extremely low at the moment. Theoretically, the commitment transaction fee should be updated once you send an off-chain payment, but I am afraid that the node you are connected to might still force you to sign another commitment transaction with a huge fee.

I don't remember if you can specify the closing fee manually if you close the channel cooperatively in Electrum. In my opinion, this would be the best option for now. I can help you choose a better node next time.

It should show the correct value from the beginning. I don't think anything is going to change once you have sent a transaction. As you can see on my screenshot, I also opened a 0.002 BTC channel and I was able to send about 90% of the funds.

I suspect that this might be because of the node you are connected to. It sounds as if the required channel reserve was extraordinarily large. Would you mind sharing the id of your peer either here or via a private message? No one will be able to find your channel because Electrum creates private channels which are not advertised across the network.

That sounds weird. Can you share more details? What node did you connect to? How big is your channel? You can also share a screenshot of your channel details with blurred funding outpoint and channel id if you want to.

In the first channel, Alice has 10 mBTC and Bob 0 mBTC. In the other channel, Charlie has 10 mBTC and Bob 0 mBTC. Bob is an intermediary between Alice and Charlie, so theoretically both of them should be able to send payments between each other through Bob. However, it's not going to work in this case.


The only way to do that is to pay Bob for something. Let's say Bob has a coffee shop. Alice and Bob went there together. Alice bought a coffee for 3 mBTC and Charlie bought a cake for 2 mBTC. Now, the balance sheet looks like this: Alice (7 mBTC) -> Bob (3 mBTC). Charlie (8 mBTC) -> Bob (2 mBTC). Now, let's say Alice owed Charlie 1 mBTC. She doesn't have a direct channel with Charlie, but she can route her payment through Bob. Alice sends her transaction and the balances change again. Alice (6 mBTC) -> Bob (4 mBTC). Charlie (9 mBTC) -> Bob (1 mBTC).

If Alice owed Charlie 3 mBTC, she wouldn't be able to send him that much because Bob has only 2 mBTC in the channel opened by Charlie.


You need to make sure that all payments are enforceable on the blockchain in an efficient way. Neither is achieved here. Let's say Charlie transacted this way with a couple more people. The final transaction would have the same amount of outputs as the number of people Charlie transacted with. Also, why would he need to transfer his funds to a multi-signature address since you didn't even mention Bob? How would Alice be sure if Charlie was not going to cheat?

The trick is that Alice updates the balance of the channel with Bob and Bob updates his channel with Charlie the moment he routes the payment. This way, Alice needs only to be sure that Bob is not cheating. She doesn't have to think about Charlie anymore.

I have just updated the guide to reflect the changes made in the recent update. The biggest change is support for trampoline nodes which are now used by default. While it doesn't take much time to download the network graph right now, it is a significant improvement which will be more useful in the future. I also added a short FAQ section. If any questions come to your mind, don't hesitate to ask them and I will put them there.