I might have phrased that slightly wrong, so let me explain it in more detail. If you are closing a channel uncooperatively, there are actually two on-chain transactions involved instead of just one.

First of all, the timelock is decided before the channel is established. By default, most nodes force the other peer to wait 144 blocks (~1 day). The maximum acceptable value by default is 2016 blocks (~2 weeks). I configured my node to create channels with their_to_self_delay = 432 blocks (~3 days), so if someone decides to close the channel opened to my node uncooperatively, they will have to wait 432 blocks (after the commitment transaction has been included in a block) before they can spend the output belonging to them. Those timelocks are relative which means that you do not have to sign a new commitment transaction whenever a new block is mined. New commitment transactions are signed periodically because their fees need to match the current state of the mempool. There is no point in paying 60 sat/vbyte when 1 sat/vbyte transactions are getting confirmed in just a few minutes. It also applies the other way around.

The first transaction is the commitment transaction. Let's say there's node A(lice) and node B(ob), and node A broadcasts the commitment transaction. That commitment transaction includes two outputs:

- output #0: 3 BTC (spendable by node B's private key) - reflecting node B balance
- output #1: 6 BTC (RSMC) - reflecting node A balance

There is one more important detail before we go any further. Whenever a new commitment transaction is signed, both parties exchange revocation keys for the previous commitment transaction so that they can both be sure that the other party is very unlikely to broadcast an old state of the channel.

RSMC is short for Revocable Sequence Maturing Contract. Such an output contains a relative timelock. This means that you can't spend this output until a certain amount of blocks have been mined since the transaction which includes that output was mined.

Let's say node B didn't change the default value of 144 blocks and the commitment transaction has been confirmed. There are two possible scenarios.

1) Node A attempts to cheat and broadcast an old commitment transaction. Node B has 144 blocks to spend the RSMC output using his and node A's revocation key which he got while they were working on a new commitment transaction.

2) Node A broadcasts the latest commitment transaction. In such a case, node B never got node A's revocation key for that commitment transaction, so he cannot spend that RSMC. Node A can broadcast another transaction spending that output after 144 blocks have been mined.

I know it sounds complicated. I am working on a thread which will explain it in a more understandable way.

The other party would very likely close the channel forcefully after some time. It would be possible because channel participants constantly sign new commitment transactions which can be used to settle the balance on-chain once a certain timelock has passed.

Unfortunately, in this case, the other party could attempt to cheat by broadcasting some old commitment transaction. Normally, you would be able to revoke it and publish a penalty transaction. A watchtower could also do that but it would have had to be set up beforehand.

However, not all participants of the network have malicious intentions. If the channel was closed using the latest commitment transaction, you would get all of your coins back to your on-chain wallet which you should be able to recover using your seed.

I am not sure how mobile wallets behave, but LND generates a backup file which lets you close your channels thanks to data-loss protection (note that in this case your peers have to cooperate with you). C-lightning users can use a backup plugin which makes a copy of the whole channel database whenever it is updated. If you have such a copy, you can easily recover your node without having to close any channels.

You should take a closer look at BlueWallet and Strike.

BlueWallet is a custodial wallet, but it handles the channel management for their users. The payment success rate is quite high.

Strike has taken a different approach. Their users don't have to own any coins or know the difference between Bitcoin and Lightning Network invoices. All they need to do is to scan the invoice. Strike will automatically pay it and charge user's credit card.

You can reach out to me once you have set up your node. I am willing to maintain channels with other forums members. What implementation have you chosen?

By the way, it is not cost-effective at all times. Assuming that it is a one-time thing, I would rather eat the loss than pay extra for an uncooperative channel close. Apparently, c-lightning will be taking that into account soon.

Also, if anyone is wondering how to open multiple channels in a single transaction (c-lightning), here's a command that I used a few moments ago.

lightning-cli multifundchannel -k destinations='[{"id": "03cde60a6323f7122d5178255766e38114b4722ede08f7c9e0c5df9b912cc201d6", "amount": 5000000}, {"id": "037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba", "amount" :1000000}]' feerate=1000perkb minchannels=2


Weren't you going to move your c-lightning node and keep it running?

Since the funds are locked in a 2-of-2 multi-signature address, both the "receiver" and "sender" hold the keys.


Both the "receiver" and "sender" exchange revocation keys (in an appropriate order) before signing a new commitment transaction. The revocation key can be used only if one of them broadcasts an old commitment transaction.


Your example is completely irrelevant. In this case, I would not be able to broadcast your transaction (because you never gave it to me) and you would be able to double-spend that UTXO fairly easily (since the funds are not on a multi-signature address). In the Lightning Network, both parties can broadcast a commitment transaction at any given time, they cannot send the coins anywhere without the agreement of the other peer and they can punish each other for any fraudulent behaviour. I wouldn't be able to do any of that.


You should not accept an HTLC if you did not negotiate a new commitment transaction which includes that HTLC as one of the outputs. "At a later time" sounds just wrong.

If you (or anyone else here) are concerned about the way I moderate this thread, feel free to PM me or create your own thread.


Let me throw a couple of random quotes at you as well!



An IOU does not specify the repayment terms? What is a negotiable instrument then?


That totally sounds like a commitment transaction to me.

In this case, Phoenix Wallet (or more precisely ACINQ) initiates the payment from their node rather than route it from you. They expect you to pay them back once the channel between you and them has become active. How can they trust you? Well, you are using their software which was programmed to do that automatically.


Under normal circumstances, it would not be possible. If you set up your own node then it's impossible for someone to open a channel to you without a valid on-chain transaction. In fact, by default, that transactions needs to have either 1 or 3 confirmations (it depends on the implementation) before the channel becomes active.

I am not sure what you would exactly expect from an Electrum-like Lightning wallet, but actually, Electrum has introduced support for the Lightning Network in the 4.x update. I even wrote a step-by-step guide. In short, a user can easily open a channel with any Lightning Network node. The only caveat is that the user has to either set up a watchtower or launch their wallet every few days to check if the other party did not broadcast an outdated state of the channel.

There are even more user-friendly wallets out there but most of them are custodial, for example, BlueWallet which takes care of the channel management so that users don't have to worry about incoming/outbound liquidity.

Let me throw in my two cents.

franky1 makes some good points. I am also a little bit concerned about large nodes which set the minimum channel funding value to ridiculously high values.

I don't agree with the statement that the Lightning Network as a whole consists of IOUs. I do agree that milisatoshis are backed only by trust, but...

I don't think that's a major issue. Putting the msats value aside, if you are the channel founder then you do not lose any money. The moment you decide to close the channel both balances are rounded down to whole satoshis and the remaining 1 satoshi is added to the transaction fee, which as a channel founder you have to pay anyway. If you are not the channel founder then... well, that's a negligible loss for you. By the time msats become valuable, the number of on-chain decimal places might have been already changed as a result of some hardfork.


While it's true that HTLCs are denominated in msats, they are still enforceable on the blockchain. The moment you send/receive an HTLC to/from someone, you also need to sign a new commitment transaction. Commitment transactions can include not only the current balance of both parties but also offered and incoming HTLCs. Both of these (locked) outputs obviously need to be rounded down to whole satoshis in order for the transaction to be valid.

I think that we have had enough. Please, move to some other thread if you wish to discuss it further. Feel free to quote me there. I will be removing any IOU related posts from now on.

Doesn't it contradict your "not interested in being liable for people's money" policy?


I don't think there is any up-to-date open-source LN explorer worth attention. Unfortunately, most projects were abandoned years ago. I'd love to host something similar to 1ml.com myself.

10%, 25%, 75%, 100%... maybe 200%? Who knows?


Yes. If you have your seed then you can even use third-party software (btcrecover) to guess the lost passphrase. It could take a lot of time, though.


Trezor devices reset after 16 invalid PIN attempts. Every time you enter a wrong PIN, the delay between attempts increases twofold. Ledger devices reset after 3 invalid attempts and there is no delay.

It is possible to build more layers on top of the Lightning Network. For example, Sphinx Chat takes advantage of the way LN transactions work and provides a decentralised encrypted messaging service.


The Lightning Network was not designed for one-time payments. You are supposed to use your channels multiple times before you close them. You have to pay an on-chain transaction fee for both channel opening and closing transactions. Since LN fees in most cases are extremely low, those channels will quickly pay themselves off if you use them more than once.


I am not sure if I understand your question correctly. Lightning Network payments are not recorded on the blockchain. Instead, both participants of the channel update its balance without broadcasting anything to the Bitcoin network. If your Lightning payment is routed through multiple nodes then it becomes nearly impossible to track your transaction. Once you decide to close your channel, the closing transaction will include only yours and your peer's address (or either of them).

If you are worried about your node going down then you can set up a watchtower on some cheap VPS or a Raspberry Pi at a different location. The watchtower can publish a penalty transaction if the other party attempts to cheat while your node is offline. By default, one has to wait 144 blocks (~ 1 day) before an uncooperative channel close can be settled. Mobile wallets usually force the other party to wait 2016 blocks (~2 weeks).

Also, you don't need to run your own node. If you are comfortable with using a custodial wallet then you can consider using BlueWallet. You wouldn't have to worry about launching your wallet every now and then since you wouldn't be managing channels on your own. It's not a good choice if you want to minimise trust or want to earn money through payment routing.


It can be more than that if the remote peer changes that default maximum value. Still, ~2 weeks is more than enough.

He was probably referring to PGP signed messages and not Bitcoin signed messages.


You don't have to move at all; that's what WSL is for. After following my instructions, launch Ubuntu through WSL (you should be able to launch it easily by typing in "Ubuntu" in the search bar), create a new key pair using Trezor's instructions, type in explorer.exe . and put the files you want to sign/encrypt or verify/decrypt in the new explorer window, follow Trezor's instruction again and you should be able to copy the output files from the same explorer window.

Trezor does not provide any instructions for Windows. You can follow these instructions for Linux if you use Ubuntu through Windows Subsystem for Linux. I managed to get trezor-cli to work this way. I don't think there is any easier workaround.

The problem is that you can't expect everyone to take advantage of the potential financial independency. Simply put, people are lazy and seek the easy way of doing things. Most of them might never use a non-custodial wallet.


That depends on what you think that the average customer is more likely to value. For example, Bitcoin transactions are irreversible. Assuming that most merchants will use third-party payment processors, this probably won't be a problem if they have some refund policy like Visa or MasterCard. Otherwise, there are going to be a ton of complaints. Unless governments push CBDCs and negative interest rates, I don't think that ordinary people have any significant incentive to switch over.


That's a good remark. I see Strike as a necessary product for the transitional period where more and more merchants start accepting Bitcoin while users are slowly catching up.

What about the Mycelium board then?


I have been already doing it for 3 years! Take a look at the FAQ thread (there is also a non-self-moderated version). Both have 49 pages in total which could make up quite a lot of separate threads.


Still, those topics could be moved to the Lightning section where they could be answered by more people. Right now, I am using ninjastic.space to keep track of new threads and I sometimes miss some of them. I am afraid that some users might get too frustrated if they don't get an answer, and they might give up on the LN.

Na pewno nie będzie to poziom XMR. Nadal będzie wiadomo kto jest nadawcą i odbiorcą płatności oraz jaka jest wartość transakcji. Adresy taproot będą korzystały z sygnatur Schnorra, które pozwalają na agregację sygnatur. W praktyce oznacza to, że transakcje z adresów multisig będą nieodróżnialne od zwykłych adresów.

Nie jestem zbytnio fanem dyskutowania o cenie, ale jestem ciekaw Waszego zdania. Jak myślicie, jak duży (o ile w ogóle) będzie wzrost ceny po aktywacji Taproot w listopadzie? Podejrzewam, że im bliżej będziemy aktywacji, tym więcej ludzi zacznie mówić jak bardzo jest to ważna aktualizacja i, że możemy spodziewać się wzrostów podobnych do tych po aktualizacji SegWit.