New answers tagged


Just use lightning-cli close id the implementation will first try to do a mutual close. Both lightning nodes will use the fee estimator from Bitcoind to suggest fees. If they don't agree there is a communication protocol defined in the BOLTs that they will eventually find a local agreement between themselves. This protocol is described under the section ...


There seems to be a mix in notation. Payment channels on lightning are bidirectional by design. However that does not mean that funds can always flow on both directions. Currently channels are funded by one party an as such can not receive funds after opening. As was mentioned in the comment what you mean is called a dual funded channel. As soon as you use ...


Channel funding (and the distribution of funds) is determined at the time of channel opening. Once opened, a party cannot ‘add funds’ to the channel, this would require opening a new channel. If you opened the channel and did not specify that some number of sats should be pushed to the remote node at the time of opening, then the channel will open with the ...


listpeers listpeers returns data on nodes that you have connected with OR the nodes with which you have an open channel. If you have an open channel with a node, but the connection with that node has been lost, then the node will still appear in the output, with "connected": false. If you are connected with a node but do not have open channels, then it will ...


listpeers show current peers, which means your node has been peered to other nodes that are shown in the command. It also means you are ready to fund channels with these nodes. listnodes show nodes in your local network information.


updated the docker image and put bind-addr to somehow fixed the problem for some unknown reason.

Top 50 recent answers are included