Lightning Network on Bitcoin Core

Open

The Lightning Network can be used with any node software that supports SegWit. In this example, we'll demonstrate the steps to install Lightning with Bitcoin Core. This guide is intended to merely demonstrate specific commands for installing an LND node for use with CAS.

In this example, an LND node will be installed on top of a Bitcoin Core node.

This article implements LND v0.18.1.

1. Setup a Bitcoin Core node (as illustrated here).

2. Configure Bitcoin Core.

a) Open the Bitcoin Core config file for editing (default shown):

• Note your rpcuser & rpcpass located in the config file for later use (below).

b) Add these additional settings to the config file.

They are required for lnd and bitcoind to communicate.

• Save & exit nano (Ctrl-X).

c) Restart Bitcoin Core to load the new settings.

3. Install LND.

a) Download the LND pre-compiled tarball:

b) Verify the file’s integrity (recommended):

See: https://github.com/lightningnetwork/lnd/releases

c) Extract the program to the system path.

4. Configure LND.

Create the default LND directory:

Create and secure the LND configuration file:

Open the configuration file for modification:

Add these entries to the lnd.conf file:

• Add the correct credentials for bitcoind.rpcuser and bitcoind.rpcpass (determined during your Bitcoin Core installation). LND uses the RPC credentials to communicate with Bitcoin Core.

• Note: the “restlisten” port is an important CAS parameter, and can be changed (as needed) to avoid conflicts with other services that may be running on your node server.

• the alias “gbdemo-lnd” will be broadcast to the world. Choose another alias carefully.

• Save & exit nano (Ctrl-X).

5. Start the node.

a) Start the daemon.

The node will stop & complain that that the wallet is locked. You’ll need to create one (next).

• If you already have a LN wallet, unlock the wallet when requested.

b) Create a new LN wallet.

The node (lnd) must already be running in the background, and it must continue to run in the background while creating a new LN wallet. The Ubuntu screen utility or tmux utility is perfect for this - or you may use 2 separate terminal windows. Either approach will work. Create the wallet in a different window from the already running server daemon (LND) window.

• Enter a new password. You’ll need this password every time you start the node. Make it memorable.

Open

The Lightning node will now begin synchronizing. It won’t take very long (about an hour). It depends upon the underlying Bitcoin node. Both nodes must operate simultaneously.

6. Fund the node.

The node will need to be funded for a channel to be opened. This involves sending an opening transaction to your LN node from a Bitcoin wallet. Obviously, if you already have already funded your node, skip to the next step - you need not fund it again (unless you have insufficient funds).

a) Create a new LIGHTNING deposit address.

A deposit address is required to add BTC to fund your LN wallet. You may create as many deposit addresses as you like; they all fund the same LN node.

• Creates a “pay-to-taproot” wallet, to which you’ll send Bitcoin to fund a channel (put BTC in escrow).

b) Fund the new wallet.

If you have not yet funded your wallet, send a suitable amount of Bitcoin to the address created in the previous step. The minimum amount is 0.0002 BTC (= 20,000 Satoshis).

Wait for the requisite confirmations (normally 3), then check your funding wallet balance:

• in this example, I’ve sent 20000 Satoshis to my funding wallet.

c) Create (open) a Payment Channel.

Some helpful advice: https://github.com/openoms/lightning-node-management

You must open a channel to someone else on the Lightning network. It doesn’t really matter who it is, but it should be a channel that fits your specific needs.

• shows that NO channels are currently open. You can’t send any LN on the network, until you connect a channel to another node, so pick a channel from any suitable explorer.

We’ll use this info (from the Lightning explorer website) to extract 2 required channel details.

• public key = 02254f26976d6487f7664aa941e006642ac3f3974d20c19f4117069e5803418dbe

• node address = ln1.generalbytes.com

The final required piece is the amount. You’ll have to commit a certain amount to the initial transaction, and this will be locked up (you can’t spend the Bitcoin) until the final transaction is broadcast. If you commit 20,000 Satoshis to the channel, then that will be the maximum amount you can send back & forth.

In this example, we’ll commit the trivial amount of 20000 Satoshis. This is the resulting command:

• If successful, the request will return the funding transaction ID:

• The transaction (as with any Bitcoin Tx) may then take anywhere from minutes to hours to confirm.

d) Monitor your payment channel(s).

At any time, check your channel state using the lncli listchannels command demonstrated (above). It will take a certain amount of time to open the channel, but once it confirms (and the channel activates), you’ll see an active channel as shown here, using:

• no channels listed probably means the channel is still pending. It may take hours+ to confirm.

  • use lncli pendingchannels to examine the situation (and other channels that might also be in limbo - such as closed channels).

• The channel will also automatically deduct the closing transaction’s mining fees from your deposit.

  • e.g. while 20,000 satoshis were deposited, only the local_balance (19,273 satoshis) were available for spending. The current estimated mining fees (727 satoshis) for the closing transaction - are withheld.

7. Setup a secure tunnel for encrypted communication.

Your CAS server and this node must have a secure method of communicating. Your passphrase and other sensitive information will be passed back & forth, so encrypt (and protect) this communication by using a secure SSH tunnel. You have 2 different tunnel options; never use both (one or the other).

The GB Wallet Tunnel is recommended.

Option 1: General Bytes has incorporated an open-source SSH client into CAS.

• Click here for instructions to install the GB Wallet Tunnel Server on this node.

8. Prepare the parameters for the CAS Crypto Setting

This final step is also discussed here:https://generalbytes.atlassian.net/wiki/x/AQCOyQ

In a text file, on a single line, assemble these parameters. Each parameter is separated by only a single colon (no spaces). This example uses spaces only for clarity of view (don’t use spaces)!

Here’s a simple script to assemble the parameters:

• This script assumes you use the GB Wallet Tunnel.

Details matter.

In the event you have trouble above (or implement a custom solution), manually verify this data:

1. url

The first parameter is the URL, and it varies upon your implementation.

Common between all implementations is the “restlisten=” port you set in the ~/.lnd/lnd.conf file (step 8 way at the beginning). The example supplied port 8088, so if you haven’t deviated from the examples, then we know it’s 8088. To be certain, you may execute this:

• If the result is empty, STOP. You better restart from the beginning.

• Whatever number is returned: is the port you’ll need to append to the URL.

The base URL will be one (or the other) of these two:

1. You used the GB Wallet Tunnel: use the URL or IP of that node server,

   1. e.g. if your public IP is “123.123.123.123”, then the URL will be: https://123.123.123.123

2. You created your own tunnel, use: https://127.0.0.1

Finally, append the port to the URL. This is your “url”.

2. macaroon:cert

These files are used for secure interprocess communication (between CAS and LND). The contents must be converted & entered as hex in the CAS parameters:

• ~/.lnd/tls.cert

• ~/.lnd/data/chain/bitcoin/mainnet/admin.macaroon

These 2 lines accomplish this:

Separate the 2 results with a colon, and append to the parameter string (which already has the url).

Example parameter string:

Finally, configure CAS.

Once you have the required information assembled, proceed to configure CAS:

• https://generalbytes.atlassian.net/wiki/x/AQCOyQ

Notes

Closing a channel:

If you’ve decided that the channel you’ve opened is insufficient (too small) or problematic (bad routing), you can close the channel one of 2 ways.

First, get the channel details:

• Locate channel_point.

• NOTE: the 2 required parameters are separated by a colon in listchannels.

  • Replace the colon with a space when passing the parameters to closechannel.

• When active = true, you may close cooperatively. When false, use option 2 (forced).

Option 1 (best; cooperative):

Close an active channel with a closing transaction.

• Request closure using: lncli closechannel funding_txid channel_point e.g.

  • • 926fb8fc1aa69432bcaa7e4aa7b0cf9cde6f24378870b8a22b92eb036175ac1eis the funding transaction ID.

    • 1 is the output_index from channel_point

• The closing transaction should settle and your funds should become available within a few mining confirmations.

Option 2 (forced; unilateral );

Closes any channel, but may take a few weeks to recover your funding. In some situations you have no choice, such as when the channel goes inactive.

• The funds may take a few weeks to return to your wallet. Use only as a last resort!

Additional resources:

https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md

https://github.com/alexbosworth/run-lnd

https://docs.lnpay.co/api/lnurl-withdraw/how-does-lnurl-withdraw-work