As one of the people who frequently argue with him, I think that we should leave him be. It is sometimes tiring to confront him. I keep him away from The Lightning Network FAQ thread as I don't want to see tens of pages of "whether or not Lightning is Bitcoin" discussion every few weeks there, but I try to reply to most of his arguments in other threads.

He does spread a lot of blatant lies like: it costs $3 to open a Lightning channel, Lightning is not Bitcoin and he has recently done something that I would call a trolling attempt but our related posts got deleted twice.


That's pretty much why I am still answering his posts.

In case someone still doesn't know, both c-lightning and LND can open multiple channels in a single transaction. The former has a dedicated command to it and the latter requires you to construct such a transaction manually. Mobile wallets users are out of luck for now.

As n0nce has said, I am not really doing it to make a ton of money. If that were the case, I would open far many more (large) channels.


You seem to be stuck in 2017/2018. Transaction fees have been extremely low for quite some time now. Even 1 sat/vbyte is enough to get a transaction confirmed quickly. The smallest possible opening transaction with change weights ~152 vbytes (transaction; channel). The cost of that transaction was only $0.07.

Stop making things up.


6700 payments over 5 months means an average of about 44 payments per day. Note that TheJuice's node has less than 10 BTC capacity and there are many nodes with far more channels and capacity.

What kind of messages in your opinion nodes use to signal that they are able to route a payment? funding_locked is used only to signal that the funding transaction has reached enough confirmations for the channel to operate safely.

The "path finding gossip" is used to maintain an up-to-date local graph of the network which is then used to construct (not test) possible routes. Path-finding is implementation specific; it is not standardised in any way.

You need to offer an HTLC via update_add_htlc to learn if your peer has enough liquidity to forward your payment.

How do I know that? Well, I can clearly see what's going on in my node's debug log. Here's what happens when my node does not have enough liquidity to forward someone's payment:


03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e asked me to forward a payment to 037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba, but I didn't have enough coins on my side in the outgoing channel. The rest of the log is much longer than that, but it mostly consists of signature generation and exchange.


I can tell when a payment fails due to no liquidity in one of my channels, but I can't tell the exact reason if the payment fails at some further point in the route.

I have seen many unconfirmed transactions drop from the mempool. Does it mean that Bitcoin is a failure too?


If the payment eventually goes through, the path-finding algorithm might as well be blamed. Those algorithms could favour larger nodes, which usually have enough liquidity, to speed up payments, but that would eventually lead to centralisation. Still, large payments usually take only a couple of seconds to complete.


Liquidity is not advertised through gossip. So, the path is chosen based on its length and cost. As I have already said, I keep my fees fairly low which encourages wallets to include my node in the path. They don't know if I have enough coins on my side to forward the payment. If my node fails the payment due to no liquidity then they have to try another route.

I also responded to his pizza experiment argument here, but it looks like we have a different understanding of what a "failed payment" and "payment success" are.

I can't really answer that. From my own experience I can tell that it's not that uncommon, especially if you open channels to large nodes. If the other party is the founder, it makes sense for them to wait for you to come back online as commitment transactions usually pay a higher transaction fee than cooperative closes.

Lightning channels do not expire. You are probably referring to a relative timelock of the commitment transaction. If the other peer is honest, you can come back online after a few months and you still will be able to use your channel. If you suspect that the other party might cheat, you just need to open your wallet slightly more frequently than every 2 weeks. A penalty transaction will be broadcast if your wallet detects a fraud attempt.

Also, the default CSV timelock is 144 blocks for regular nodes and 2016 blocks for mobile wallets.

Oh, I wrote that post on the 31st December and I meant to publish it on the very same day. "This month" obviously refers only to December and not January.

Two out of seven of my channels are used mostly for outgoing payments. On the 7th December, both of these channels became extremely unbalanced. I can route only a few thousand satoshi through them now. Once I rebalance them via circular payments, my node should start routing payments again (I have been getting a lot of failed attempts due to no liquidity since that day). I also need to adjust my feerate in those channels based on the rebalancing fee so that I can make a profit or at least don't lose any money.

December might look kind of underwhelming to you given my previous stats. I quickly ran out of liquidity this month and I didn't have much time to think about rebalancing my channels. I might end up letting the rebalance plugin run in the background to avoid this kind of situation again.

Number of nodes =/= number of users. It is not mandatory for nodes to advertise themselves publicly. Mobile wallets usually run either eclair or LND and they are not included in any metrics. They are also far more easier to use, so I wouldn't be surprised if 32 thousand users was a great underestimate.

Istnieją także fizyczne klucze 2FA (np. Yubico). Trezor oraz Ledger działają na podobnej zasadzie, ale mają też ekran, na którym dodatkowo możesz upewnić się jakiej stronie udostępniasz klucz.

The number of unconfirmed transactions has nothing to do with the interval between blocks. As more miners join the network, new blocks are mined more frequently. The protocol aims to sustain 10 minute intervals by adjusting the difficulty every 2016 blocks. Blocks have a fixed maximum size (4 vMB), which can be changed only through another soft/hard fork.

Manager: sujonali1819
Nazwa kampanii: OWL.GAMES l Crypto Casino For WEB 3.0 l Signature Campaign
Ile do zarobienia: Hero Member/Legendary - $3.2/post w BTC
Jakie rangi: 15x Hero Member/Legendary
Dodatkowe informacje: Minimum 10 postów tygodniowo, w tym przynajmniej 5 w sekcji Gambling. Maksimum 25 postów.

Użytkownicy portfela Trezor One mogą zacząć używać dodatkowego hasła (passphrase) aby załagodzić skutki ataku. Użytkownicy Trezora T mogą skorzystać z wbudowanego slotu na kartę microSD, która w połączeniu z PINem może zostać użyta do zaszyfrowania pamięci portfela. Atak wymaga fizycznego dostępu do sprzętu, więc większość osób raczej nie musi się tym przejmować. To samo dotyczy klonów Trezora.

W tej chwili najbezpieczniejszymi portfelami są te oparte o Secure Element, ale właśnie z tego powodu mogą być tylko częściowo open-source. Trezor jakiś czas temu zapowiedział Tropic Square, czyli firmę, która ma za zadanie stworzyć SE, który będzie open-source na tyle na ile to będzie możliwe.

Polecam zacząć zabawę od testnetu. LN nie wybacza błędów i jeżeli przypadkiem uruchomisz starą kopię węzła albo dwa identyczne węzły jednocześnie, to niektóre kanały mogą zostać przymusowo zamknięte i możesz stracić pieniądze. W praktyce coś takiego raczej nie zdarza się. Jeżeli potrzebowałbyś pomocy przy wyborze implementacji, to możesz śmiało pisać w tym temacie.


Nigdy nie będziemy mieli dokładnych danych. Nie jesteśmy w stanie powiedzieć ile transakcji dziennie przetwarza cała sieć, więc musimy polegać na statystykach, które okazjonalnie udostępniają większe serwisy. W sierpniu tego roku osoba odpowiedzialna za integrację Lightning dla Bitfinex udostępniła trochę statystyk na Twitterze. Sam używam LN przynajmniej raz w miesiącu do zakupów na Bitrefill i zaoszczędziłem masę pieniędzy na opłatach transakcyjnych. Zazwyczaj wydaję około $10 i płacę mniej niż 10 satoshi za transakcję.

HTLCs are used only in commitment transactions when there is at least one unsettled payment in the channel.

franky's point is that HTLCs are not Bitcoin because they need to be "converted" (routed down to a whole satoshi). Otherwise, HTLC outputs would be invalid and nodes would reject such commitment transaction. When someone asks you to forward for example 500 msat, you sign a new commitment transaction with a higher fee; there is no HTLC output. At worst, you can lose 999 msat, which is worth $0.00047 at the moment, when you close your channel. Oh, and the same applies to HTLCs and final balances below the dust limit.

So, yes, there is some trust involved here. You might not get either up to 999 msat (~$0.00047) or up to 546 sat (~$0.26) back. It doesn't really matter when you are the founder of the channel; you have to pay the transaction fee anyway.

The Lightning Network could work without milisatoshis, but franky would still argue that it's not Bitcoin because you are not guaranteed to get your money since someone might broadcast an outdated commitment transaction while you are offline.

Ledger Nano S lub Trezor One. Jest jeszcze paru innych producentów na rynku, ale nie miałem z nimi styczności. Te dwa portfele są bardzo popularne.

Ledger będzie dla Ciebie w sam raz, jeżeli interesujesz się altcoinami. Model S posiada bardzo mało wbudowanej pamięci, która jest potrzebna do instalacji aplikacji na portfelu. Możesz bez problemu odinstalować jedną aplikację żeby zainstalować drugą bez utraty środków.

Trezor jest w całości open-source (zarówno od strony software'u jak i hardware'u), ale niestety jest podatny na atak, który umożliwia ekstrakcję PINu oraz słów potrzebnych do odtworzenia portfela.

Sam posiadałem oba portfele i byłem z nich zadowolony. Obecnie korzystam z Trezor T oraz Ledger Nano X i szczerze mówiąc częściej korzystam z tego drugiego. Jeżeli byłbyś zainteresowany Ledgerem, ale myślisz, że mała ilość pamięci będzie Ci przeszkadzać, to możesz poczekać na Nano S Plus.

Sure, my node failed to route 389 payments. Some of them were probing attempts, some failed at a further point in the route and others could not be routed because I didn't have enough coins on my side in the outgoing channel. However, those were not my payments. I keep my fees fairly low compared to other nodes so no wonder why I am getting a lot of routing attempts. Anyway, my point is that my node failed to route 70% of the payments, but it doesn't mean that LN failure rate for transaction smaller than 0.09 BTC is 70%. You can't tell if another attempt for the same transaction was successful or not.

I still haven't shared my stats for December, but you will be delighted once you see them. I didn't have much time this month to adjust my fees and rebalance my channels so my node failed over 300 payments mostly due to no liquidity.


No, if you accept a zero-conf transaction and the other party cheats, you have no way of penalizing them. If someone broadcasts an old channel state, you can publish a penalty transaction.