5

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 ...


4

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 ...


4

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 ...


3

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 ...


2

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 ...


1

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 ...


1

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 receive multiple payments that exceed "...


1

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 ...


1

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 ...


1

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible