Tag Info

First of all welcome to the lightning network and keep asking excellent questions! the important information is within the result of the listfunds command. For example here: "channel_sat": 500000, "channel_total_sat": 500000, The channel_total_sat says that the capacity of your channel is 500k satoshi. Whereas the channel_sat says that you own 500k ...

No, there is no work around for this. If a channel's balance is completely allocated to one side, the channel can only be used to move funds in one direction. Additionally, a channel whose balance is shifted completely to one side is vulnerable to the broadcast of a previous channel state as there are no funds to be lost for the attacker. This does not apply ...

The currently lightning specification means that one party must fund the channel. So if A opens a channel with B and A is funding with, e.g. 1 BTC, then the channel initial state will be A:1 BTC, B:0 BTC. So A can't receive anything because B is the only person that can send money to A, but B has no money. However B can receive money from A because A has the ...

Natively c-lightning does not support paying invoices to yourself. But I have provided a trick described in this video: https://www.youtube.com/watch?v=Dwl-0cY6KkU&t=1s: The trick is to create an invoice and then use getroute to find a route to some node and then go back (possible over another route with another getroute call). once you have such a ...

Create an invoice for yourself: lncli addinvoice <amt> Pay the invoice specifying the outgoing channel and the last hop to take before paying you: lncli payinvoice --allow_self_payment --outgoing_chan_id <outgoing_chan> --last_hop <last_hop> <payreq_from_1> To get the outgoing channel id use lncli listchannels --active_only. I ...

Any additional funding transactions would not be covered by older commitment transactions which can result in the loss of funds. Older commitment transactions will not contain inputs that spend from the new funding transaction. The funds sent in the second funding transaction require B to sign a spending transaction, and if B refuses, then A has no way to ...

I did not have any incoming connections with enough liquidity. I got some and it is working now.

First of all, there are already scripts that automate this process. Check C-Otto's rebalance script, for example. Secondly, I wouldn't assume that finding a route via queryroute guarantees that the balances in the used channels could actually support your payment. I think it just means that the theoretical capacity in your nodes' view of the LN is ...

It can be done, but it's not trivial. Technically, in order to be able to route payments, you need liquidity in both directions, incoming as well as outgoing. If you just funded two channels, you only have outgoing liquidy now (all the money is on your side). There are many ways to gain incoming liquity. You could spend or swap the funds in your channels (or ...

As explained here How to fund a bidirectional payment channel? there is a difference between capacity and balance of a channel. Your channel has a capacity of 20000 Satoshi and this number is (as of the current protocol specification) fixed for the lifetime of the channel. Your local balance seems to be also 20000 as you have opened it. Making payments ...

if your channel's are initially as you described (just depicted here again with better readability using total cpacity of the channel in brackets in the middle of the channel and the respective local balance on the side of the peer) You -(200) --------[400] -------- (200) - Alice You -(200) --------[200] ---------- (0) - Bob And you create a circular ...

Can my LN channel for some amount "X" receive a LN payement larger than "X" No, you can only receive payments until the entire channel capacity ("X") has been pushed to you side of the channel. At that point, you will no longer have incoming capacity. ..or receive multiple small payments that exceed "X"? You could ...

Not all implementations support multiple channels between two nodes. That is why I would advise against that practice. Also I do not really see an advantage of having two channels. We don't have Atomic multipath routing yet so in general it makes more sense to have larger channels. Only counter argument I see is that one channel can only have 483 htlcs ...

I would like to be able to receive LN payment on online shop. In order to do this and in my understanding, I have to either wait until my customers fund channels to me, or find a node that already has many channels and get it connect to me with an ample amount of cap. This is correct, but there are other options as well. For example, you could open a ...

Payment routing could handle this. Any business has operational costs and will have to make outgoing payments. If your concern is that channels will mostly consist of payments in a single direction (i.e. from customers to larger businesses), and that this will lead to a high frequency of channel closings or on-chain settlements, then we can consider the ...

The total capacity of a channel cannot be increased since the funds are held in a single UTXO (unspent transaction output). What can be done, however, is to rebalance the channel from within the Lightning Network itself, so A can use it again. Let's assume the balance of the channel is now 0 BTC for A and 2 BTC for B, so A cannot send payments through the ...