Running LND with systemd, Without Containers (7) - Opening a Channel and Sending a Payment

Part 7 of the series. Part 6 left two LND nodes connected as peers in the same VM: lnc with 1 BTC on chain, lnb with nothing, and no channel between them.

Opening a channel

The counterparty’s public key

A channel is opened to a specific node, and a node is identified by its public key. So the first thing lnc needs is lnb’s key, which I’d kept in a variable:

echo $LND_B_PUBKEY

0361b9…4191 is the same key lnc listpeers showed at the end of Part 6, so the channel will go to the node lnc is already connected to. On a real network, a node’s public key is how you find it and how you check you’ve reached the right one; an address alone could point anywhere.

openchannel and the pending channel

openchannel takes the counterparty’s key, how much to put in the channel, and the fee rate for the funding transaction. If it succeeds, it prints the ID of that funding transaction. Until the transaction confirms, the channel shows up under pendingchannels:

lnc openchannel \
  --node_key="$LND_B_PUBKEY" \
  --local_amt=1000000 \
  --sat_per_vbyte=2
lnc pendingchannels

The pending channel, field by field:

Why local_balance is 996,530 rather than 1,000,000: as the opener, lnc pays the commitment transaction’s costs out of its side. That’s the 2,810 sat commit_fee plus two anchor outputs of 330 sat each:

1,000,000 − 2,810 − 2 × 330 = 996,530

Two fees are in play here and they’re easy to mix up. --sat_per_vbyte=2 pays for the funding transaction that goes on chain now. commit_fee is held back inside the channel for a commitment transaction that only goes on chain if the channel is closed that way.

The same pending channel, from lnb

lnb knows about the channel too, before anything is on chain: opening a channel is a conversation between the two nodes, and they agreed on it over their peer connection before lnc broadcast the funding transaction.

lnb pendingchannels

It’s one channel seen from both ends, the same way the Mac and WSL nodes saw one channel in an earlier routing post: the same channel point and capacity, local and remote swapped, and each side naming the other as the initiator or not. The numbers they both have to agree on, the commitment fee, the reserves, and the confirmations needed, are identical.

The funding transaction in bitcoind’s mempool

The channel is pending because its funding transaction is waiting for a block, and the place transactions wait is Bitcoin Core’s mempool:

btc getrawmempool

All three are the same transaction. LND built and signed it from its own wallet, then handed it to bitcoind over RPC to broadcast, the first job in the table from Part 2 of what LND needs Bitcoin Core for. It’s the only transaction in the mempool, so the next block will pick it up.

Mining the funding transaction into a block

confirmations_until_active was 1, so one block is all the channel needs:

btc generatetoaddress 1 "$MINER_ADDRESS"

Block 3c2277…0780 takes the funding transaction out of the mempool and into the chain. Both nodes hear about it over ZMQ, count the confirmation, and can move the channel from pending to open.

The channel is open

btc getblockcount
btc getrawmempool
lnc listchannels

Before the block, getrawmempool listed exactly one transaction, the funding transaction. Now it returns an empty list: nothing is waiting, because the only pending transaction went into block 105.

The channel now exists on chain as a single output, and lnc can start moving its 996,530 sat to lnb without touching the chain again.

Sending a payment

An invoice from lnb

On Lightning, the receiver starts a payment by creating an invoice. lnb makes one for 10,000 sat, and I copied its payment request into a variable for lnc to use:

lnb addinvoice --amt=10000 --memo="first-regtest-payment"
read -r -p 'B invoice: ' B_INVOICE

The payment request’s prefix already says a lot. ln is Lightning, bcrt is Bitcoin regtest (mainnet would be lnbc), and 100u is the amount: 100 micro-bitcoin, which is 10,000 sat.

Paying it from lnc

An invoice is a request for payment, so it always comes from the receiver; here lnb made it, and lnc pays it:

lnc payinvoice "$B_INVOICE"

Before asking for confirmation, payinvoice decodes the invoice and shows what’s inside it, which is the same information lncli decodepayreq gives:

Then the result:

Two numbers tie this back to earlier steps. CHAN_OUT decodes the same way as the SCIDs in my earlier routing posts: 115448720982016 is block 105, transaction 1, output 0, which is the funding transaction in the block mined above, at the :0 of the channel_point. And the preimage hashes to the payment hash, which anyone can check from the two values in the screenshot:

printf '53f34658c223fd43bbace9628b78b0d02fce96a522378ed52a6ced091711e323' | xxd -r -p | sha256sum
# expected: 5b4d32fbf13499bd2c5ba811f0da6a77cf72d8ba7c3d3744821745fd674e793f  -

That match is the proof of payment: lnc now holds a secret that only lnb could have given it, and only in exchange for the 10,000 sat. Revealing it here costs nothing, since this invoice is paid and these are regtest coins.

Balances after the payment

After the payment, the two sides of the channel line up exactly:

lnc’s local_balance is lnb’s remote_balance, and the other way around. lnc started with 996,530 sat in the channel and paid 10,000, which leaves 986,530; lnb started with nothing and now has the 10,000. unsettled_*: 0 means no payment is still in flight on either side. No transaction went on chain for any of this: the channel’s funding output is unchanged, and only the two nodes’ agreement about how to split it moved.

I’m recording these numbers as a baseline. If anything goes wrong with either node later, this is the state a recovery has to get back to.

Where the series ends

Over seven parts, the lab went from a clean Lima VM to two LND nodes with an open channel and a settled payment, without a container or Kubernetes anywhere:

Each job Kubernetes used to do for me had a plain Linux answer: systemd units for restarts and boot order, users and file modes for isolation, loopback binding for network policy, and a directory the service owns for persistent storage.

What happens when one of these nodes fails is the next question, and it gets its own series.