No, Lightning Network invoices are not reusable. Every payment invoice contains a hashed payment secret which is used to construct an HTLC.


The Lightning Network does not use addresses like the first layer. Implementations like c-lightning and LND support sending/receiving keysend (spontaneous) payments. Such payments do not require payment invoices; you just need the id of someone's node. Most wallets support only payment invoices.


Keep in mind that refill addresses are unique to BlueWallet. Their Lightning wallets are custodial. You don't have to worry about opening channels and inbound/outbound capacity.


No. Even though you are using a custodial wallet, BlueWallet has a limited number of channels with limited inbound capacity. Once they run out of inbound capacity, you won't be able to receive any satoshis. Any payment might also fail if: there is no route between BlueWallet's node and the sender or if intermediary nodes do not have enough liquidity to forward the payment. Large payments are usually automatically split into smaller chunks which are routed through different channels. It increases their success rate.


You would very likely have to manually generate an invoice with an amount specified by them. That's how withdrawals work on Nicehash, Bitfinex and other Lightning compatible services. You could also use BTCPay Server which would use your own Lightning node. However, you would have to learn how to manage your node's liquidity (incoming/outgoing capacity) which is difficult.


Unless you open a direct channel to them, your withdrawal will have to be routed through your other active channels.


Feel free to ask any questions! You may also find The Lightning Network FAQ and Basics of The Lightning Network useful.

Even though the average time between blocks is around 10 minutes, you can never be certain if your transaction will be mined within that timeframe. Sometimes, no block is found for 30-40 minutes. You can also get lucky and there might be a few blocks mined one after another in a short period of time. As for the fee, 1 sat/vbyte has been enough to get a transaction confirmed quickly for quite some time now. You should check mempool.space beforehand. It seems to have very accurate estimates.

Take a look at this blog entry. There are multiple ways of settling the balance of a channel on-chain. Here's an example of a dual-funded channel opening transaction.


The funding transaction output is locked with a simple 2 of 2 multisignature script. Before that transaction is broadcast by the funder, both parties sign the first commitment transaction which spends that output. Commitment transactions contain more sophisticated scripts, especially when there are unsettled HTLCs.


OP_RETURN would make the coins unspendable. There is no reason why Lightning would use it.

It's actually Alice who owned 10 BTC at the beginning but you get the idea. The first commitment transaction contains only one (RSMC) output. If Alice published it and it got confirmed, Bob could safely publish a penalty transaction within 144 blocks. I am not sure why you mentioned the HTLC here.


An unsettled payment is an HTLC which still hasn't been claimed using a payment preimage.


HTLC-timeout transaction is a transaction which allows the person who offered the HTLC to claim it back once the absolute timelock expires. We need HTLC-success/HTLC-timeout transactions to handle the dispute if something goes wrong while a payment is being routed (see "Broken channel" section of this article).


Sounds good.


No worries. Feel free to ask more questions or let me know if something is still not clear. It's a little bit late here so I will answer the question about revocation keys tomorrow.

You seem to be slightly confused about how the Lightning Network works. Timelocks that are used in commitment transactions are relative (except for the HTLC outputs which also contain an absolute timelock but that's a rare case) which means that they are safe to use for an indefinite amount of time. Despite that, commitment transactions are resigned periodically, even if there isn't any activity in the channel, to update the on-chain fees based on the current mempool state.

Revocation keys can be used only if the other party publishes an old commitment transaction which had been revoked. If the latest commitment transaction is published, the transaction immediately refunds the other party their coins and the person who published the transaction has to wait a specific amount of time (144 blocks by default) before they can spend their output to themself in another transaction. Commitment transactions should not be used if both parties are online and willing to cooperate. They can agree to close the channel at any time without any delay.

I will take a look at your thread later today.

I explained an uncooperative channel close in this post. I think that you should read it before reading my reply further.


An uncooperative channel close always involves at least two transactions. The first one is the commitment transaction and the other one spends the RSMC output. There might be more transactions; two for each in-flight HTLC.

Things get a little bit complicated when we are talking about unsettled payments. Bob asks Alice to sign a commitment transaction with the following outputs:

- a standard output; 8 BTC to Alice's address
- HTLC; 2 BTC that can be spent on the following conditions: Bob can spend this output using the payment preimage and HTLC signatures (HTLC-success transaction); Otherwise Alice can spend this output using revocations keys or HTLC-timeout transaction.

Note that this is what Bob's commitment transaction looks like. Alice's transaction looks like this:

- RSMC; 8 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Alice can spend these coins; otherwise Bob can use his and Alice's revocation key to unlock this output.
- HTLC; 2 BTC that can be spent on the following conditions: Bob can spend this output using the payment preimage and HTLC signatures (HTLC-success transaction) or using the revocation keys; otherwise Alice can spend it through the HTLC-timeout transaction.

Note: The HTLC-timeout transaction contains an absolute timelock (cltv_expiry) to give the other party time to claim the funds with the payment sercet. The outputs of HTLC-success and HTLC-timeout transactions contain another locking script with the same relative timelock as the RSMC output (to_self_delay).

Once all of the in-flight payments are settled, the final commitment transactions look like this:

Bob's commitment transaction:

- a standard output; 8 BTC to Alice's address
- RSMC; 2 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Bob can spend these coins; otherwise Alice can use hers and Bob's revocation key to unlock this output.

Alice's commitment transaction:

- a standard output; 2 BTC to Bob's address
- RSMC; 8 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Alice can spend these coins; otherwise Bob can use his and Alice's revocation key to unlock this output.


Alice constructs a new commitment transaction and asks Bob to sign it. Bob signs Alice's commitment transaction. Then, Bob creates his own version of the latest commitment transaction and asks Alice to sign it and revoke her previous commitment transaction. Once Alice signs Bob's transaction, he can safely hand her over his revocation key for the previous transaction.

Maybe it's a server related issue. Have you tried changing the server you are connected to a few times? Some implementations do not work well with the built-in Lightning Network functionality. You can also report your problem here if you still can't get it to work. You can also enable logging and share the logs with us.

Yes, it is. You won't be able to recover your wallet if you mess up the order of the words. If someone finds all of your words in a scrambled order then that person needs to check 12! (479001600) seed phrases in the worst case. It should take only a few hours on a modern PC with a mid-tier CPU using a tool like btcrecover.

A CTO of Bitfinex shared some data in June on Twitter.


Bitfinex has two Lightning nodes. They even share their current liquidity here. At the moment, they have ~90 BTC inbound capacity and ~311 BTC outbound capacity.

You might also find this list useful. There are some entries which are not listed in your thread. It seems to be updated as soon as some exchange implements or announces support for the Lightning Network.

Well, those companies need to run and maintain specialized nodes. For example, Bitfinex charges 0.0004 BTC (~$22) for on-chain withdrawals and only 0.000001 BTC (~$0.05) for Lightning ones. That's 400 times cheaper even though the latter one includes the cost of running a Lightning node and the routing fee paid to other Lightning nodes.

Manager: Hhampuz
Nazwa kampanii: Catena X | Experience the Future of DeFi
Ile do zarobienia/tydzień / ilość postów: Hero member/Legendary - $70 w BTC/tydzień
Jakie rangi: 14x Hero member/Legendary
Dodatkowe informacje: Minimum 25 postów tygodniowo. Lokale liczą się.

You need to change the gap limit. Go to the Console (enable it first by selecting View -> Show Console) and type in the following command.

wallet.change_gap_limit(number)

No, liquidity is not advertised across the network. That would be a privacy infringement. It knows the total channel capacity, though.


Locally: Check out this comment. There are apparently five possible causes. lightning-cli listforwards returns the exact error if a transaction fails locally.

Remotely: Some node might fail a transaction locally or suddenly go offline. There might be some other causes that I am not aware of at the moment too.

It's completely normal. I have successfully routed 84 transactions and I have 357 failed ones.


"Failed" means that the transaction failed at some further point in the route. If your node fails to route a payment then you will see "Local_failed" instead. You can't really do much about it. If you see a lot of 10, 10k, 100k sat failed payments then someone is very likely probing your channels. It can be done with any other amount as well.

W innym wątku wywiązała się dyskusja co do ceny tego urządzenia i jest ona... powalająca. Za $429 można złożyć już całkiem sensowny domowy serwer, który będzie mógł służyć nie tylko jako węzeł BTC + Lightning. Rozumiem, że jest to rozwiązanie skierowane do osób, które niezbyt się na tym znają, ale jeżeli ktoś zabiera się za węzeł Lightning, to raczej byłby w stanie kupić na własną rękę Raspberry Pi i nagrać odpowiedni obraz na kartę microSD.

W cenie zwykłej malinki można też kupić używanego laptopa, który wydajnościowo powinien być lepszy (na plus jest też wbudowana bateria działająca jako UPS). Stawanie czegoś więcej niż węzła BTC i Lightning na malince zakrawa o masochizm, a o dziwo Umbrel pozwala na instalację masy dodatkowych aplikacji.

I don't think that Eclair Mobile has ever been capable of routing payments. I believe that it creates only private channels. You would be required to keep the app active in the background all the time. Your available balance might have been slightly shifting because new commitment transactions with different fees are signed periodically. The founder of the channel always pays the closing fee so that's why it's deducted from your balance.

As for the Zap, you can actually download and run lncli to manage the built-in LND node. See this guide. Once you have installed it, you should be able to use lncli updatechanpolicy command to modify the fee policy of your every channel.

Może są jakieś ograniczenia ze względu na zastosowane proxy? Nie jestem w stanie wytłumaczyć dlaczego za jednym razem ten sam obrazek dodaje się bez problemu, a za drugim nie, ale na pewno musi być jakiś maksymalny dopuszczalny rozmiar pliku.

That's very likely the cause. You should check if those large nodes have channels between themselves.


I have a channel to both Bitfinex and Nicehash. I routed quite a few large payments between these two nodes at the beginning. It turned out that they are connected directly so I guess their channel was often unbalanced at that time. Unfortunately, Bitfinex has changed their fee policy and I very rarely see any activity between those two channels now.

I am running ElectrumX and its database currently takes up exactly 71 GB of space! That's... a lot. Is anyone here running a different implementation so that we could compare the numbers?

By the way, n0nce are you going to set up your own node any time soon?