|
By default, Lightning payments are capped at around 0.043 BTC. That is probably what they are calling "channel capacity limit". On a side note, this limitation does not apply to wumbo channels.
|
|
|
|
Obecnie nie ma ekonomicznego powodu używania lightning (fascynacja technologią i rozwijanie technologi na przyszłość to obecnie jedyne powody używania)
Wypłata on-chain z Bitfinex: 0,0004 BTC (~$16,5), wypłata off-chain: 0,000001 BTC (~$0,04) Mam świadomość tego, że giełdy są nieco "odklejone" i znacznie zawyżają opłaty, dlatego dorzucam Nicehash, który ma inny model zarobkowy, do porównania. On-chain Nicehash: 0.000005 BTC (~$0,20), off-chain: 0 BTC  W niektórych przypadkach używanie Lightning ma sens, ale faktycznie jest to spowodowane czyimś widzimisię, a nie stanem sieci. Obecnie sieć jest prawie pusta. Przechodzą transakcje z 2 sat/vbyte czyli 11 centów!
Idealny moment na otwarcie kanałów  |
|
|
|
I'd think it will similar on LN implementation, they still charge additional fees to earn more profit. So if the difference isn't that huge, I will keep using mainnet since it's more convenient.
On the other hand, casinos can run their own Lightning nodes to provide the deposit/withdrawal functionality. This way, they might earn some satoshis by being a routing node. Popular services usually attract people who are willing to open and manage channels, so casinos wouldn't have to do much except opening a bunch of channel at the beginning. |
|
|
|
I jak to działa bez otwierania kanałów i problemu płynności na nich? Wydaje mi się, że jedyna opcja to taka, że portfel jest scentralizowany, nie mamy kluczy i trzymając tam środki nie jesteśmy ich włascicielami.
Dokładnie tak to działa. Właściciel BlueWallet zarządza kanałami i ma pełną kontrolę nad środkami użytkowników. Nie jest to rozsądne rozwiązanie dla większych kwot, ale większość osób używa Lightning raczej do mniejszych wypłat. Ciekawą alternatywą może być Muun Wallet, ale muszę się z nim zapoznać dokładniej zanim będę w stanie powiedzieć coś więcej. Mam pytanie o limity LN? czy są jakieś? jak to wygląda aktualnie?
LN miało być do mikropłatności tylko, jestem ciekaw czy nadal tak jest czy to już się zmieniło i można wysyłać ile sie chce w odpowiednich kanałach?
Kiedyś obowiązywał maksymalny rozmiar kanału (0.16777215 BTC) oraz płatności (0.04294967 BTC) bez wyjątków. Było to uciążliwe, bo np. c-lightning nie wspiera wielu kanałów z tym samym węzłem (można mieć tylko jeden). Teraz każdy może dobrowolnie zasygnalizować wsparcie dla kanałów "wumbo", które nie mają tych limitów. |
|
|
|
No BitPay jest dość popularny. Sam korzystałem kilka razy, ale takiej opcji nie widziałem
Kiedy ostatnio z niego korzystałeś? Wydaje mi się, że wprowadzili płatności poprzez LN jakoś w tym miesiącu. Swoją droga to trzeba mieć otwarty kanał z giełdą i zasilić go kwotą by to działało tak? Albo być w jakimś kanale w którym są również giełdy?
Możesz otworzyć kanał bezpośrednio z jakąś giełdą albo wykorzystać niebezpośrednie połączenie, jeżeli takie w ogóle istnieje. Możesz też skorzystać z np. BlueWallet i nie będziesz musiał przejmować się otwieraniem kanałów i ich płynnością. |
|
|
|
Wśród głiełd/kantorów/pośredników płatności wciąż brak adopcji tej technologi, więc wątpię by taki wzrost był spowodowany czymkolwiek innym.
Całkiem sporo mniejszych kantorów i giełd wprowadziło wsparcie dla Lightning już jakiś czas temu. Ostatnio do tego grona dołączyła giełda Kraken oraz pośrednik płatności BitPay, co w sumie można nazwać dużym krokiem w przód. |
|
|
|
@darkv0rt3x you seem to collect a lot of fees!  What are your fee rates? Fee rates are publicly available information as they are needed for pathfinding. You can check his settings using any Lightning explorer. It's pretty straightforward on both 1ml.com and amboss.space; you just need to scroll down a little. |
|
|
|
Probably has nothing to do with me rebalancing our channel earlier yesterday. Oh, now I see that 4 of those transactions were sent from your side. How many times did you rebalance our channel? |
|
|
|
March doesn't look good in comparison to other months. My Internet connection was unstable for over half a month and my node was down for a couple of days. I managed to fix it around the 26th and it took about 3 days before I started seeing routing attempts again.  On a positive note, my node routed 6 transactions today and I earned 351.58 satoshi. April looks promising! |
|
|
|
Manager: HhampuzNazwa kampanii: DAO Maker ~ Public SHOIle do zarobienia: Sr. Member - $60 w BTC/tydzień, Hero Member/Legendary - $75 w BTC/tydzień Jakie rangi: 8x Sr. Member, 12x Hero Member/Legendary Dodatkowe informacje: Minimum 25 postów tygodniowo. |
|
|
|
Is you node Rath [keysend] down now and then? I opened a channel to it a couple of weeks ago and I keep seeing it go down for a while.
It always comes back, but all the other channels I have stay up. Just trying to figure out if it's you or me or just something between us.
It's my fault. Sorry about that. I have been experiencing some serious Internet problems for the past month. I am going to temporarily migrate my node in a few days to a virtual machine with more stable Internet connection. |
|
|
|
1) Getting a list of IPs through gossip protocol
...and DNS bootstrap. Do you have practical experience with autopilot mode / plugins? Depending on implementation, it might drive centralization by going for the 'safe bet' (mostly going for channels towards large, well connected hubs).
I have only used LND's autopilot for a short moment back in 2019 and it always prioritized large nodes (especially ACINQ which always causes problems for me). I glanced over their GitHub and it looks like they have made quite a few improvements. I prefer to open my channels manually now. Is that a network trend, or just an anomaly with your node that you're only connected to 1-2 peers?
I am connected to all of my channel peers (10 connections) and occasionally some random Lightning nodes connect to me (or vice-versa). My Bitcoin node has far many more connections. If it's a normal thing then it's hard to see how LN anodes can protect themselves from "influence attacks" (or whatever they're called) where a few nodes with a completely different and wrong blockchain connect as the only peers to another node, tainting its knowledge of what is the correct tip. Since Lightning nodes are just thin wrappers around bitcoin nodes, it would be easier to carry out this kind of "mind control" of an unsuspecting LN node
Here's a paper describing such an attack. You should be fine if you run a watchtower at a different location. Most Lightning Network nodes are connected to full nodes which are less susceptible to this attack. |
|
|
|
While a full node discovers peers and subsequently also automatically connects to them, a Lightning node doesn't.
Actually, they do. Connecting to someone is not the same as opening a channel to them. You can use lightning-cli connect with no consequences Usually, 1-2 random nodes are connected to me at a time. Such connections are used only to exchange gossip messages. But automatically connecting (creating channels) doesn't make sense - I hope it is easy to follow why, now.
Autopilot is a thing, but I have never seen one that closes channels immediately once the other peer goes offline |
|
|
|
I mean when one tries to cheat by broadcasting an outdated commitment transaction. As far as I've understood, the cheater needs both signatures to spend from the force-closed multi-sig address.
The sender needs both signatures to spend the output of the funding transaction. That output is spent by every commitment transaction or a transaction that is signed during cooperative close. Commitment transactions lock each output differently. "to_local": OP_IF
# Penalty transaction
<revocationpubkey>
OP_ELSE
`to_self_delay`
OP_CHECKSEQUENCEVERIFY
OP_DROP
<local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG If we assume that "to_local" output belongs to A, they can spend it once the CSV timelock expires using "local_delayedprivkey". B can spend this output at any time using their "revocationprivkey". There is no multisig here; just a bunch of conditions. "to_remote" is usually a simple P2WPKH address. Commitment transactions can also include HTLC outputs which we haven't talked about yet. They are used while the payment is being routed through a channel. They are also used for direct payments (to keep the protocol simple). Offered HTLCs: # To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_NOTIF
# To local node via HTLC-timeout transaction (timelocked).
OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node with preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
OP_ENDIF In your case, A has this output in their first commitment transaction. This output can be spent using either the payment preimage + B's HTLC signature, or A's and B's HTLC signatures (HTLC-timeout transaction) which it timelocked. Received HTLCs: # To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF In your case, B has this output in their first commitment transaction. It requires either payment preimage and A's and B's HTLC signatures (HTLC-success transaction), or A's HTLC signature once the CSV timelock expires. A and B include signatures for HTLC-success/timeout transaction in a "commitment_signed" message ("num_htlcs*signature:htlc_signature" field). If you want to learn why these outputs must be spent using another pre-signed transactions, see this answer. 2. Alice wants to send him 0.02 BTC, so she signs a transaction with two outputs: A) to_local (that can be spent by her after x blocks) and B) to_remote that can be spent by Bob instantly.
It's slightly more complicated than that. We have to assume that they have already signed a commitment transaction with HLTC outputs. Every Lightning transaction involves two commitment updates. Here's an example that I wrote some time ago. I assume that (A)lice wanted to pay (E)ric through B, C, D. Here's my current understanding of how the system works: 0) Lightning nodes constantly use the gossip protocol (bolt07) to forward/receive "node_announcement", "channel_announcement", "channel_update" messages and maintain a local view of the whole network. 1) Alice receives a payment invoice from Eric which includes information like: Eric node's public key, payment hash, amount, expiry (date) and cltv expiry. 2) Alice constructs a path to Eric using her local map of the network. She tries to find the cheapest and the shortest route. The longer the route, the higher the risk that funds will get stuck during routing. 2a) She prepares "onion_routing_packet" which includes encrypted routing information for each hop. 3) Alice sends "update_add_htlc" message to Bob, which includes the "onion_routing_packet" (which is the same for all peers), the amount, the payment hash and cltv expiry. 4) Alice and Bob sign a new commitment transaction with an HTLC output. 5) Bob sends "update_add_htlc" to Carol with the same "onion_routing_packet". 6) Carol and Diana, Diana and Eric do the same. 7) Eric sends "update_fullfil_htlc" message to Diana, which includes the payment secret. 8) Eric and Diana remove the HTLC output and update balances by signing a new commitment transaction. 9) Diana sends "update_fullfil_htlc" to Carol with the same payment secret and they update the commitment transaction. 10) Carol and Bob, Bob and Alice do the same. Comments: 3) The amount Alice sends is actually bigger than the one in the invoice as she must account for the fees. Each hop forwards the HTLC with a smaller amount and keeps the difference. If some hop tries to claim higher fees than Alice expected, the next node in the route will fail the payment as the routing instructions say how much one's node is supposed to forward. If Bob doesn't have enough coins to forward the payment on his side of the channel with Carol, he must send "update_fail_htlc" message and Alice needs to try sending the payment through another route. All channels use the same payment hash. It is safe because HTLC outputs require both the payment secret and HTLC signatures, which can be produced only by channel partners, to be spent. See this post for explanation. In your case, A starts with "update_add_htlc" and then everything goes as you described. Afterwards, Bob sends "update_fullfil_hltc" and the commitment transaction is updated again in the same way. |
|
|
|
Does the lightening network by any means require the use of mempool in transaction verification or it does byepass mempool?
Lightning Network nodes need to watch the mempool and the blockchain because they must: a) check if their channel partner didn't cheat by broadcasting some old channel state (using a revoked commitment transaction), b) check if any of the known channels' funding transactions have been spent, c) check if a funding transaction for a specific channel has been confirmed upon receiving " channel_announcement" message. When you send a transaction over the Lightning Network, you don't need to obtain any data from the mempool. Lightning Network nodes maintain a network graph of all channels so that they can easily and trustlessly calculate a path for the payment. Removal and addition of nodes based on the (un)confirmed transactions is a completely separate process. |
|
|
|
{
"lnServerUrl": "https://127.0.0.1:3003/v1"
Are you sure that port 3003 is correct? You should set it to the same value as "rest-port" in your c-lightning config. Also, try removing "/v1" as it should not be necessary. |
|
|
|
I did, but I have another problem now. Ride The Lightning considers my node as a LND one, but it's C-Lightning and I've written it in RTL-Config.json.
We won't be able to help you unless you share your config with us. You might have made a small mistake somewhere which causes RTL to use the default settings. |
|
|
|
I believe that I also started having problems with the service at some point. I have been running c-lightning-rest as a plugin without any problems since then. You should give it a try. |
|
|
|
Is there a way to choose what inputs you use when opening channel?
Yes. However, I believe that you need to construct the funding transaction manually when using either LND or c-lightning. c-lightning: lightning-utxopsbt, lightning-openchannel_init, lightning-openchannel_update, lightning-signpsbt, lightning-openchannel_signedI have never tested it, so you might want to check the documentation more carefully to see if I am correct before trying it out. -snip
I have been slightly busy lately with some private affairs and my research on Ethereum L2 projects, but I still have in mind to reply to your post. |
|
|
|
So, I wanna ask you if you could recommend me a node implementation to choose.
I tried both, LND & c-lightning, but not in depth so, I'm not quite sure about what are the advantages/disadvantage of each other or which criteria I should use.
Here's a short summary: LND: - more resource intensive, - some people have been complaining that their database grows by a few hundred megabytes/a few gigabytes per day (this applies to large nodes), - big userbase - lots of plugins and third-party software like: Sphinx Chat, Zap Wallet integration, ThunderHub, charge-lnd, - you can't move your database between different system architectures (ex. you can't switch from a Raspberry Pi to a normal server and vice-versa) so you have to close and reopen all of your channels, - you can run LND as two instances - online one with public keys and offline one with private keys ( remote signing). c-lightning: - less resource intensive, - supports dual-funding, which is useful because you don't have to rebalance your channel if the other peer is willing to contribute some funds, - you can easily open multiple channels in a single transaction via one command, - supports BOLT12. I have been running c-lightning without any problems for a couple of months now. I had used LND twice before. At some point, I regretted switching to c-lightning because I missed the integration with Zap Wallet but dual-funding and multifund turned out to be more useful. I can't give you a clear recommendation as I don't know what you will be using your node for. If you have more questions, please reply in The Lightning Network FAQ thread. Other people might help you to make the decision. Also, we had a short LND vs c-lightning discussion there. |
|
|
|
|
Show Posts
