6

If you recommend "Mastering the Lightning Network" in chapter 2 you find a table of possible Lightning Network implementations: Application Device Lightning Node Bitcoin Node Keystore Eclair Mobile Mobile Lightweight Electrum Self-Custody Breez Wallet Mobile Full Node Neutrino Self-Custody Phoenix Wallet Mobile Lightweight Electrum Self-Custody ...


4

Walletbalance is showing your on-chain balance of a lightning wallet. Regarding channel balances (locked on layer 2 and not available onchain): local balance is your local balance that you can spend on lightning network remote balance is balance in your channels but it's being owned by the other party in the channel, this is the amount you are able to ...


4

In each of your channels, you have a local balance. This is the balance that is yours in that channel. The counterparty of the channel has the remote balance. All lightning transactions change these balances with each one resulting in their sum being the same and matching the channel capacity. As all transactions in that channel just end up changing the ...


3

The Bitcoin Core wallet and the LND wallet are completely separate wallets. LND relies on Bitcoin Core as a source for the blockchain data, nothing more. The profitability of your node depends on where it is situated in the network's topology. If you want to run Lightning to earn money, you will need to pick reliable nodes as channel partners, but also try ...


3

The maximum size for HTLC's are currently defined by max_htlc_value_in_flight_msat and is roughly 42mBTC. The max_concurrent_htlc that you mention seems to be the max_accepted_htlcs and states how many HTLCs can be within a commitment transaction at the same time. This has nothing to do with the maximum payment size (not transaction size) of a single path. ...


2

the problem is in your call of charged there you are passing the argument --ln-path ~/.lightning assuming that you run lightning in your home directory thus you have to set ln-path to /tmp/l1-regtest/. Now you say that this also did not work. So before I give you a solution let me explain what is actually going on. charged talkes to lightningd via an rpc-...


2

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


2

Answer by Oliver Gugger (guggero): You can use the dumpchannels command of chantools: https://github.com/guggero/chantools#dumpchannels That will show you the commitment transaction inputs and outputs for both parties. Remember to shut down lnd first, otherwise chantools will block on trying to open the channel DB.


1

Your experience was coincidental, there's no requirement for bitcoind to be listening on a public interface while using lightningd.


1

Tl,;Dr answer: The fees for the htlc are covered by whoever claims the output The fees for the commitment tx are always covered by the party who opened the channel. Sorry to say that but I believe there are many things wrongly stated in your question: The fee for the commitment transaction is not necessarily paid by Alice even if she force closes the ...


1

I strongly advice against a fixed list of nodes. This might eventually become outdated. A better solution might be that you run the autopilot on a server and deliver the results to the user via an api. This of course would be a trusted solution. But the lib_autopilot.py which empowers the clightning autopilot plugin is a standalone library that can easily be ...


1

A macaroon consists of three parts: The header: Identifies the macaroon and contains three fields. The version: 1 byte, always set to 0x02 in lnd The location: variable length string, always set to "lnd" in lnd The identifier: variable length binary data, contains protobuf serialized data in lnd containing the permissions of the macaroon. More on ...


1

I got a sweep TX (from a force closed channel) stuck, also due to low fees. This answer is inspired by OPs answer. I got it working with: lncli openchannel \ --sat_per_byte=${fees per byte for the funding transaction of the new channel} \ --min_confs=0 \ ${remote nodes id} \ ${local amount} The --min_confs=0 part is the important bit, it allows lnd to use ...


1

I solved the problem whit CPFP (children pay for parent). I used the unconfirmed change of the fund TX stuck in mempool to open a new channel. At the time of broadcasting TX the median fee is around 150sat/vb, so i chose to slight increase at 200 sat to ensure good probability to push the first fund tx and the second one in the next block avaible.


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