This event will hit our finances, regulations, and global economy.

Finances

• How will established institutions that recently embraced Bitcoin through ETFs react to the sudden supply shock?
• How will the sudden change in Bitcoin’s supply affect peripheral financial assets?

Regulations

• As miners are forced out will regulators impose stricter controls on mining oligopolies?
• Will regulators require more audibility from organizational and individual miners?

Global Economy

• How will this affect the overseas and U.S. mining industry?

We’ll examine the halving events and analyze all the chaos it will cause us:

• What is a Bitcoin Halving?
• How often does it occur?
• Price of Bitcoin and the Halving Events
• Economic Impact of Halving Events
• Halving and Gresham’s Law
• This Story in the Bitcoin Core Code

What is a Bitcoin Halving?

Every 210,000 blocks the block mining reward fee is reduced by half. This was determined years ago when the code was first implemented. The intention behind halving the fees over time is to slow down the network growth and give it time to mature.

The halving events should continue till the year 2140 when the maximum supply of 21 million Bitcoins are met.

How often does it occur?

A new block is mined every 10 minutes, the 10 minute time is maintained by adjusting the difficulty (if blocks are mined too quickly the difficulty increases and if they’re mined to slowly the difficulty decreases).

So if we are halving every 210,000 blocks then we should have a halving event every 4 years.

Minutes Per Year = 60 minutes per hour * 24 hours per day * 365 days per year = 525600 minutes a year

Minutes to Mine 210,000 blocks = 10 minutes to mine block * 210,000 blocks = 2,100,000 minutes to mine 210,000 blocks

2,100,000 minutes to mine 210,000 blocks / 525600 minutes a year ~= 4 years

Below are the date of the halving events and their estimated halving events.

Price of Bitcoin and the Halving Events

There isn’t a direct correlation between the price of Bitcoin and the halving events. Usually the trend is that Bitcoin is fairly stable then there is an uptick after a halving event, but this time (3rd halving event) we’ve seen the uptick before the halving event.

Economic Impact of Halving Events

The intention for the halving is to slow down the rate of Bitcoins coming into the market, and in turn keep the currency

Impact on Crypto Related Stocks

The companies that would be directly impacted by the halving are mining pool companies and companies that supply mining infrastructure. Marathon, Riot, and Clean Spark are some of the biggest miners today, halving the Bitcoin reward might remove many miners from the market and allow some of these larger mining companies to expand. Companies like NVIDIA and AMD will see negative affects from their mining equipment sales because there will be less miners.

Note: NVIDIA and AMD are growing their AI business and might not be deeply impacted from a stock perspective.

The companies that are crypto adjacent have been Coinbase, Block (Square), Microstrategy, Galaxy Digital Holding, Paypal, and Reddit because they have a large holding of Bitcoin and some provide crypto utilities. Their growth is indirectly impacted by how the halving impacts the fiat value of Bitcoin and the movement of Bitcoin.

Impact on other PoW Coins

Since the halving event reduces the reward for mining Bitcoin PoW (proof of work) miners would have more of an incentive to mine on other PoW networks. As of today some of those networks are Dodgecoin, Bitcoin Cash, Litecoin, Ethereum Classic, Kaspa, and Monero. It doesn’t mean that the coins associated to these networks will increase in value, but there might be more activity around mining, which will eventually lead to trading in these networks.

Halving and Gresham’s Law

bad money drives out good

A little bit about the Gresham Law…

The idea behind the Gresham Law is if two forms of money are in circulation at the same time then people will use the bad money and save or hoard the good money, eventually driving the good money to appear less in circulation. An example is gold and fiat currency, gold it’s considered (even today) good money, but how many times did you buy something with gold or receive it?

Gresham Law and Bitcoin

The supply of Bitcoin won’t decrease with the halving but it will slow down the supply, making it somewhat scarcer. This scarcity might drive people to hold on to their Bitcoin rather than spend it.

The combination of hoarding and new Bitcoins entering into circulation might decrease the velocity of Bitcoin (how quickly units are exchanged), causing an increased value. This would make Bitcoin, “the good money,” to disappear from circulation and for Fiat currency, “bad money,” to appear more in circulation.

The same theory can be applied to other cryptocurrencies and Bitcoin. As Bitcoin, the “good money,” is hoarded more blockchain projects will use cryptocurrencies that are considered the “bad money”. It wouldn’t make sense to create DApps that use a crypto that’s high in value, so instead, companies would create their DApps using crypto that has low transaction fees in fiat. This could give way to modern cryptocurrencies like Solana, Algorand, and Avalanche.

Halving Story in the Bitcoin Core Code

Here we have the logic that tells us that the mining reward (subsidy) is halved every 210,000 blocks.

 CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

The 210,000 is defined as a parameter value (nSubsidyHalvingInterval) in the chain params.

class CMainParams : public CChainParams {
public:
    CMainParams() {
        m_chain_type = ChainType::MAIN;
        consensus.signet_blocks = false;
        consensus.signet_challenge.clear();
        consensus.nSubsidyHalvingInterval = 210000;
...

This is where the maximum supply of Bitcoin can exist, if a bug ever causes the supply to exceed 21 million Bitcoin will go into a fork. The “MoneyRange” line of code is crucial and is referenced throughout the codebase.

// Copyright (c) 2009-2010 Satoshi Nakamoto
// Copyright (c) 2009-2021 The Bitcoin Core developers
// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#ifndef BITCOIN_CONSENSUS_AMOUNT_H
#define BITCOIN_CONSENSUS_AMOUNT_H

#include <cstdint>

/** Amount in satoshis (Can be negative) */
typedef int64_t CAmount;

/** The amount of satoshis in one BTC. */
static constexpr CAmount COIN = 100000000;

/** No amount larger than this (in satoshi) is valid.
 *
 * Note that this constant is *not* the total money supply, which in Bitcoin
 * currently happens to be less than 21,000,000 BTC for various reasons, but
 * rather a sanity check. As this sanity check is used by consensus-critical
 * validation code, the exact value of the MAX_MONEY constant is consensus
 * critical; in unusual circumstances like a(nother) overflow bug that allowed
 * for the creation of coins out of thin air modification could lead to a fork.
 * */
static constexpr CAmount MAX_MONEY = 21000000 * COIN;
inline bool MoneyRange(const CAmount& nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }

#endif // BITCOIN_CONSENSUS_AMOUNT_H

This is where we add the block subsidy (mining reward) with the transaction fee.

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

Here we stop issuing fees if the accumulated fees exceed 21 million, as defined.

            nFees += txfee;
            if (!MoneyRange(nFees)) {
                LogPrintf("ERROR: %s: accumulated fee in the block out of range.\n", __func__);
                return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-txns-accumulated-fee-outofrange");
            }

Resources

Swan Bitcoin — Next Bitcoin Halving: April 19th History and What to Know!

Next Bitcoin Halving: April 19th, 2024 History and What to Know!

Swan Bitcoin — Gresham’s Law

https://www.swanbitcoin.com/greshams-law/

Bitcoin Core Github

GitHub - bitcoin/bitcoin at 28f2ca675f89a764e1ec8eb5671b35357b8677f3

Blockworks — Bitcoin Halving BTC Price Implications

https://blockworks.co/news/bitcoin-halving-btc-price-implications

Bitcoin Talk

Bitcoin Forum - Index

Bitcoin Halving Events was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Publishing your image is crucial if you want share your masterpiece apps with the world. Let’s look at Google Cloud Artifact and how we can use that to share our application images.

Images, Containers, and Container Registries

How do images, containers, and container registries all fit together? Images can be thought of as an image file, the containers are those images in different frames, and container registries are like the gallery that houses all these containers.

Image: Standalone, executable package that encapsulates all the necessary components to run an application, including the application code, runtime, libraries, and environment variables. It adheres to the Open Container Initiative (OCI) specifications for image formats and runtime, ensuring compatibility and interoperability across different containerization platforms.

Container: Runtime instance of an image, functioning as an isolated environment in which the application executes. Think of it as a lightweight, portable, and self-sufficient environment for the image.

Container Registry: Centralized service for storing and managing container images. It provides teams with the ability to securely store private images, conduct vulnerability analysis, and manage image lifecycles. The registry typically includes features for fine-grained access control, allowing administrators to define who can push or pull images, thereby ensuring that only authorized users can access and manipulate the images.

Tagging: Used to mark a specific commit of an image and are often used in a CI/CD pipeline.

Push: Act of uploading an image to the container registry from your local machine.

Push: Act of downloading an image from the container registry to your local machine.

Setting up Google Artifact Registry

Note: These steps are the same regardless of what language you wrote you app in, because containers are language agnostic.

Do the whole song and dance of setting up a Google Cloud account, it involves enabling APIs, accepting terms, etc. After your done go to your Google console (https://console.cloud.google.com/) and search “Artifact Registry”.

Now you’re in the Artifact Registry tool, create a repository.

When creating a repository name it whatever your heart desires, select the format “Docker”, mode “Standard”, your desired location, and the encryption “Google managed encryption key”.

After creating a repository you should see your artifact folder you just created, click into the folder.

Auth Docker into Google Cloud

Next we’re going to use our docker to push into this repository to make that happen we’ll need our docker to be able to authenticate with our cloud instance.

Select “Setup Instructions” in your Google Cloud Console and you will find a command line that looks like the following, it might differ depending on your location. Run this command in your terminal in the same folder of your Dockerfile.

gcloud auth configure-docker us-central1-docker.pkg.dev

Build and Pushing Images to Google Artifact Registry

Click into the folder and select the breadcrumb copy button, this will give you the full path of the repository you just created.

Using the location of the repository run the command below to build you app to your repository.

docker build -t [LOCATION OF REPOSITORY - REPLACE THIS]/[APP_NAME]:v1 .

After a successful build push your image to the repository, using the command below:

docker push [LOCATION OF REPOSITORY - REPLACE THIS]/[APP_NAME]:v1

Note: The v1 at the end of the build and push commands should match up and should represent the version or tag you want to associate with the image.

Potential Issue:

If you aren’t properly authenticated or authenticated in one tab and trying to push your image in an older tab you will come across the error below. Make sure to authenticate in the same tab your pushing the image to the repository.

denied: Unauthenticated request. Unauthenticated requests do not have permission "artifactregistry.repositories.uploadArtifacts" on resource "projects/something-12345/locations/us-central1/repositories/backendapis" (or it may not exist)

BAM! Verify Your Image is Available in the Registry

Go back to the cloud console > Artifact Registry, and you should find your container within the the folder you created.

And if you click on the container you will find all the images and their associated tags, since you just did one push you will just have one.

Resources

Google Official Artifact Registry Docs

Artifact Registry | Google Cloud

Google Codelabs Artifact Registry

Artifact Registry Deep Dive | Google Codelabs

Getting Started with Artifact Registry and GKE

Getting Started with Artifact Registry: Deploying to Google Kubernetes Engine

Introducing Artifact Registry

Publishing Your Image to Google Cloud Artifact was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Popular Implementations

Below are a few popular lightning network implementations that follow the BOLT standards, LND, C-Lightning, Eclair, Rust LDK, and Electrum. They mostly vary by language, C-Lightning is written in C, Eclair is written in Scala, LND is written in Go, Rust LDK is written in Rust, and Electrum is written in Python.

Criteria

Besides language preferences, here are a few additional considerations to take into account when choosing the right Bitcoin Lightning implementation.

💻 Platform Support

Bitcoin client support (regular and light)

💰💰 Dual Funded Channel

💰💰💰Multi-Funded Channel

🖊 Partially Signed Bitcoin Transactions (PSBT) Support

🗼Watchtower Support

🗄 Database Required

🔑 Keysend Support

📺 Channel Backups

💻 Platform Support

Platform support is about where we can run these implementations, like can you run on a mobile Android, iOS, Linux Desktop, etc. This criterion is dependent on what hardware you have available and mostly what use case you’re trying to solve for.

Bitcoin client support (regular and light)

An implementation that supports both full and light (SPV) Bitcoin clients offers more flexibility. Full clients provide higher security but require more resources, whereas light clients are easier to run but might offer less security.

💰💰Dual Funded Channels

Dual-funded channels allow both parties to contribute to the funding transaction when initiating a channel. This brings lower transaction fees because they can jointly construct and sign the funding transactions and allows for a large payment capacity because both parties fund it. In a regular channel, only one party can fund the channel.

What Is A Dual Funded Lightning Channel? - The Bitcoin Manual

💰💰💰Multi-Funded Channel

A multi-funded channel is similar to a dual-funded channel, except now more than one party can contribute to the funding transaction when initiating a channel.

🖊 Partially Signed Bitcoin Transactions (PSBT) Support

PSBTs are a binary transaction format that allows multiple parties to sign on the same transaction at different times and share information on the transaction. This is useful if another signer is offline (ex. they are using an air-gapped wallet or hardware wallet) or a watch-only wallet that just creates transactions but can’t sign.

🗼Watchtower Support

Watchtowers act as third-party services that monitor the blockchain for malicious activities related to your Lightning channels. This adds a layer of security when you’re unable to actively monitor your channels.

Check out the description of Watchtower in the article below:

Different Ways to Close a Lightning Payment Channel

🗄 Database Required

Many of these implementations use embedded databases but can use more robust database solutions like PostgreSQL. Databases in Lightning are used to manage transaction and channel state management, routing details, and auditing.

🔑 Keysend Support

Keysend allows funds to be sent to a node without an invoice, which means you can spontaneously send someone funds without them ever asking for it. In non-keysend payments, the receiver needs to send an invoice presented by email or a QR code, with keysend payments this isn’t necessary, the receiver just has to share their node ID (a public key) once to receive payments.

What is the difference between a regular transaction and a keysend transaction?

In both cases, using onion routing helps preserve privacy by making it difficult for observers to see the identities of the sender and receiver and the payment amount. However, the use of keysend in the second transaction simplifies the process by allowing Bob to send the preimage directly to Alice’s node without the need for intermediate nodes to forward the packet.

Why you shouldn’t use the same pre-image?

Using the same preimage can allow an observer to link multiple payments together. All those payments will be tied to the same hash value, and an observer can link the payments by identifying transactions that have the same hash value.

Disadvantages of Keysend

This all sounds wonderful, but there are disadvantages to using this approach. Accepting payments without an invoice can open you up to:

• Dusting attacks (a small amount of satoshis are sent to track an address),
• Spammed wallet (someone from an unsanctioned country can send funds to your wallet and raise flags)
• Lack of payment confirmation, since an invoice isn’t required, there is no way a sender can confirm that the payment received by the intended recipient

📺 Channel Backup

Data Loss Prevention is crucial when planning for your lightning node. To handle DLP scenarios, lightning has different channel backup strategies.

Static Channel Backups (SCB): Backup files (in LND files called channel.backup) that are encrypted using a key derived from your wallet seed. This file will allow users to recover both their on-chain funds and funds settled (base commitment outputs but not HTLC’s) within their channels. It’s called static because the file is only obtained once and is valid till the channel is closed.

Note: This file sits on the node, so there needs to be a script that copies this file whenever there are changes to another instance outside of the node.

Release lnd v0.6-beta · lightningnetwork/lnd

Dynamic channel backup: This is a more advanced method of backing up a channel that involves creating a backup channel that runs in parallel to the primary channel. The backup channel is updated with the latest state of the primary channel and can be used to recover funds in the event of a channel failure.

Database backup: Some Lightning Network nodes offer a feature to automatically backup channel data to a database or other storage location. This can provide an easy way to recover channels in the event of a node failure or other issues.

Offline storage: Another option is to back up the channel information to an offline storage device such as a USB drive or external hard drive. This can provide a secure backup that is not vulnerable to online attacks.

Backup/Recovery

Below are instructions on how to recover funds when using the LND implementation:

lnd/recovery.md at master · lightningnetwork/lnd

Summary

No single implementation reigns supreme; different implementations cater to various priorities and use cases. If features are your priority, then considerations like keysend, dual-channel, and multi-channel funding are crucial. For those prioritizing security, watchtower support, database management, Bitcoin client support, and channel backup are crucial. And if flexibility and use-case adaptability are paramount, then platform support is crucial.

Resources

LDK Lightening Dev Kit

Lightning-Implementation-Features/README.md at main · FulgurVentures/Lightning-Implementation-Features

Lightning Implementation Features by Fulgur Ventures (Inspiration for this blog)

Lightning-Implementation-Features/README.md at main · FulgurVentures/Lightning-Implementation-Features

Keysend Payment

What Is A Keysend Payment? - The Bitcoin Manual

Voltage Keysend Payment Explained

Lightning Keysend Payments Explained | Voltage

PSBT Formats — BIP 174

bips/bip-0174.mediawiki at master · bitcoin/bips

PSBT Version 2 — BIP 370

bips/bip-0370.mediawiki at master · bitcoin/bips

BOLT Standards

B.O.L.T. Standards

Choosing the Right Lightning Network Implementation was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Any implementation (i.e. Rust LDK, LND, Eclair) that claims to be a lightning network implementation must follow B.O.L.T. standards. If they don’t, be wary. If you want the spark notes version of the BOLT standards, you can check out Rusty Russell’s blog post series on the BOLT standards (FYI: Rusty Russell is also a contributor to the BOLT standards and a key contributor with the BOLT 12 standard).

The #Bitcoin #Lightning Spec Part 1/8

The B.O.L.T. (Basis of Lightning Technology) standards define the protocols and specifications for any implementation of the Lightning Network. B.O.L.T. covers multiple topics around payments, routing, p2p interactions, messaging, and networking.

Here’s a list of the 10 BOLT standards.

1. BOLT #1: Base Protocol
2. BOLT #2: Peer Protocol for Channel Management
3. BOLT #3: Bitcoin Transaction and Script Formats
4. BOLT #4: Onion Routing Protocol
5. BOLT #5: Recommendations for On-chain Transaction Handling
6. BOLT #7: P2P Node and Channel Discovery
7. BOLT #8: Encrypted and Authenticated Transport
8. BOLT #9: Assigned Feature Flags
9. BOLT #10: DNS Bootstrap and Assisted Node Location
10. BOLT #11: Invoice Protocol for Lightning Payments

BOLT 6 (IRC Announcements) is missing because it was superseded by BOLT 7 (https://github.com/lightning/bolts/issues/551).

In summary, the 10 B.O.L.T. standards can be summarized in 10 commandments.

1. Thou Shall Follow Messaging Formats

2. Thou Shall Manage the Channel Lifecycle

3. Thou Shall Transact with Bitcoin Properly

4. Thou Shall Securely Route Transactions

5. Thou Shall Close the Channel

7. Thou Shall Make Nodes & Channels Discoverable

8. Thou Shall Encrypt and Authenticate

9. Thou Shall Support New Features

10. Thou Shall Discover a Node Using DNS

11. Thou Shall Send Proper Invoices

12. (Bonus) Thou Shall Provide Fresh Invoices

Thou Shall Follow Messaging Formats

BOLT 1: Base Protocol

It defines the messaging formats, data types, and connection handling between peers. Below are the topics this standard covers:

• Connection Handling and Multiplexing
• Lightning Message Format
• Type-Length-Value Format
• Fundamental Types
• Setup Messages
• Control Messages

Thou Shall Manage Channel Lifecycle

BOLT 2: Peer Protocol for Channel Management

This discusses channel operations like opening, closing, and managing it. Below are the topics this standard covers:

• Definition of the Channel ID
• Channel Establishment (opening, accepting, funding, etc.)
• Channel Close
• Channel Operations (HTLCs, updating fees, revoking & acknowledging, CTLV expires, etc.)
• Message Retransmission

Thou Shall Transact with Bitcoin Properly

BOLT 3: Bitcoin Transaction and Script Formats

This tells us what the required formats of on-chain transactions with Bitcoin should look like. It includes funding, commitment, HTLC (Hash Time-Locked Contract) transactions, and key derivation.

Below are the topics this standard covers:

• Transaction Output Ordering
• Use of Segwit
• Funding Transaction Output
• Commitment Transaction
• HTLC-timeout and HTLC-success Transactions
• Closing Transaction
• Fees
• Dust Limits
• Commitment Transaction Construction
• Keys

Thou Shall Securely Route Transactions

BOLT 4: Onion Routing Protocol

This standard describes the onion routing mechanism used for secure and private payment routing within the Lightning Network.

What are Onion Routes?

Onion routes come from our days of illegally pirating music and movies from Torrent sites; it’s popularly used with Tor.

Deep Dive Into TOR (The Onion Router)

The Lightning Network uses an onion routing technique, similar to the Sphinx construction, to route transactions through multiple intermediate nodes, known as hops. An onion route packet is created by the origin node, which establishes a shared secret with each hop using the Diffie-Hellman key exchange (specifically, ECDH — Elliptic Curve Diffie-Hellman) and the public keys of the intermediate nodes.

Diffie Hellman and Why it’s Needed

The shared secret from Diffie Hellman is then used to create a stream of bytes that obfuscates the packets and a number of keys used to encrypt the payload and compute the HMACs.

Below are the topics this standard covers:

• Conventions
• Key Generation
• Pseudo-Random Byte Stream
• Packet Structure (Payload Formatting, Basic Multi-Part Payments, and Route Blinding)
• Accepting and Forwarding a Payment
• Shared Secret
• Blinding Ephemeral Keys
• Packet Construction
• Packet Forwarding
• Filler Generation
• Returning Errors
• Test Vector

Thou Shall Close the Channel

BOLT 5: Recommendations for On-chain Transaction Handling

This standard goes over closing channels in the good (mutual close), bad (unilateral close), and ugly (revoked transaction) way. Check out the blog below for more details on channel closures.

Different Ways to Close a Lightning Payment Channel

Below are the topics this standard covers:

• Commitment Transaction
• Failing a Channel
• Mutual Close Handling
• Unilateral Close Handling: Local Commitment Transaction
• Unilateral Close Handling: Remote Commitment Transaction
• Revoked Transaction Close Handling
• Generation of HTLC Transactions

Thou Shall Make Nodes & Channels Discoverable

BOLT 7: P2P Node and Channel Discovery

This standard defines the mechanisms for discovering Lightning nodes and channels on the network, including node announcements and channel updates.

Below are the topics this standard covers:

• Definition of short_channel_id
• The announcement_signatures Message
• The channel_announcement Message
• The node_announcement Message
• The channel_update Message
• Query Messages
• Initial Sync
• Rebroadcasting
• HTLC Fees
• Pruning the Network View
• Recommendations for Routing

Thou Shall Encrypt and Authenticate

BOLT 8: Encrypted and Authenticated Transport

It specifies the requirements for secure transport and message encryption between Lightning nodes.

Below are the topics this standard covers:

• Cryptographic Messaging Overview
• Authenticated Key Exchange Handshake Specification
• Lightning Message Specification
• Lightning Message Key Rotation
• Security Considerations

Thou Shall Support New Features

BOLT 9: Assigned Feature Flags

This standard establishes a framework for assigning feature flags to enable optional protocol extensions within the Lightning Network.

Feature flags allow the network participants to signal their support for new or experimental features and provide a way to coordinate the activation of those features across the network. The flags are represented as bits, where the odd bits are optional features and the even bits compulsory features.

Feature flags usually are implemented through a consensus process, where participants in the network signal their readiness to support a particular feature by setting a specific flag in the protocol messages they exchange. Once a sufficient majority of participants have signaled their readiness, the feature can be activated on the network.

The use of feature flags allows for a more gradual and coordinated deployment of new features, ensuring compatibility and minimizing disruptions to the network. It also provides a mechanism for backward compatibility, as older implementations can still function without supporting the newly introduced features.

Thou Shall Discover a Node Using DNS

BOLT #10: DNS Bootstrap and Assisted Node Location

It defines a mechanism for Lightning nodes to discover initial peer connections using DNS records and assisted node location services. We use DNS to:

• Bootstrap: providing the initial node discovery for nodes that have no known contacts in the network
• Assisted Node Location: supporting nodes in the discovery of the current network address of previously known peers

Below are the topic this standard covers:

• DNS Seed Queries
• Reply Construction
• Policies

Thou Shall Send Proper Invoices

BOLT #11: Invoice Protocol for Lightning Payments

This standard specifies the format and semantics of Lightning Network invoices, which are used for requesting and receiving payments.

Below are the topics this standard covers:

• Encoding Overview
• Human-Readable Part
• Data Part
• Payer / Payee Interactions

Check out the article below to dive into invoices.

Lightning Invoices

(Bonus) Thou Shall Provide Fresh Invoices

BOLT #12: Flexible Protocol for Lightning Payments (Offers)

BOLT 12 aims to address the shortcoming of BOLT 11. Due to security concerns, BOLT 11 invoices can only be used once. So BOLT 12 saves the day by creating brand new invoices natively without the need for web servers (unlike LnURLs) in real-time. In BOLT 12, there is this concept of “Offers,” which can be shared publicly for donations or for merchants. Below is an example of an “Offer”:

bolt12.org: Lightning's Native Experience, Everywhere

Checkout Rusty Russell’s Git repo on BOLT

GitHub - rustyrussell/bolt12: Javascript Routines for the Lighting Network Protocol

There are two basic payment flows supported by BOLT 12:

General User-Pays-Merchant Flow

1. A merchant publishes an offer, such as on a web page or a QR code.
2. Every user requests a unique invoice over the lightning network using the invoice_request message, which contains the offer fields.
3. The merchant replies with the invoice.
4. The user makes a payment to the merchant as indicated by the invoice.

Merchant-Pays-User Flow (e.g. ATM or refund)

1. The merchant publishes an invoice_request which contains offer fields that refer to its attempt to send money, including an amount.
2. The user sends an invoice over the lightning network for the amount in the invoice_request using a (possibly temporary) invoice_node_id.
3. The merchant confirms the invoice_node_id to ensure it’s about to pay the correct person and makes a payment to the invoice.

Why is it insecure reusing B.O.L.T. 11 Invoices?

With invoices in BOLT 11, the payee can claim the payment by revealing the preimage (input). If you reused the invoice, you would be reusing the same hash, resulting in the same preimage.

This means anyone who previously saw the preimage (from the first time the invoice was paid) could intercept and claim future payments made to the same invoice.

They can potentially claim the funds if they set up their own HTLC (Hash Time Locked Contract) using the same hash and then unlock it using the preimage they already know. They can also track your payments across different channels and times, linking them together and reveal information about your finances.

Disclaimer: Just knowing the preimage isn’t enough to intercept a transaction, the attacker would also need control over one of the nodes in the payment path that’s re-using the the same invoice. If the next node in the path (the one you received the HTLC from) sees on the blockchain that you broadcasted the old state you will be penalized.

A little bit about Pre-Images…

The receiver when creating the invoice generates a random number and uses this number as input to a cryptographic hash function. The value yielded by the cryptographic hash function is the payment hash, and the random number in the input is the payment pre-image.

Is B.O.L.T. 12 Used Today?

B.O.L.T. 12 isn’t in the B.O.L.T. standards yet and is still in the experimentation and discussion phase. It was first implemented on C-Lightning and is currently on the roadmap for many of the popular implementations.

Here is the discussion on B.O.L.T. 12 on the LND Github repo:

BOLT12 · Issue #5594 · lightningnetwork/lnd

Here is B.O.L.T. 12 on the Rust LDK roadmap for Q2'23:

LDK Roadmap: LDK Node, BOLT 12, Anchor Outputs, Async Payments & More

BOLT 12 is an exciting development and will be a critical piece in the evolution of the BOLT standards. BOLT 12 may not be perfect right now, but will eventually lead to an explosion of use Bitcoin Lightning use cases.

Bitcoin Lightning is similar to a bar tab…

The lightning network acts as the tab running at a bar. The tab is a payment channel between you and the bar. When ordering the first drink, you provide a credit card, similar to initiating a payment channel. Then as the night proceeds, and you're having too much fun, you will order multiple drinks 🍻; these multiple drink orders are recorded transactions 📜. While going through these drinks, you haven't technically spent any money on these drinks. It's only until the end of the night when you pay for the drinks by closing out your tab.

With the lightning network, 2 transactions happen on the Bitcoin network, opening a payment channel (starting the tab) and closing a payment channel (closing out the tab).

Topics Covered:

⛈ What is Bitcoin Lightning?

🤺Different Lightning Implementations

🌐Payment Channel Lifecycle

🤔Analyzing a Lightning Payment Channel

👬Connecting to a Lightning Node via Docker

📚Resources

⛈ What is Bitcoin Lightning Network?

The lightning network is built to facilitate cheaper transaction fees and faster transactions on the Bitcoin network.

A Layer 2 Solution…

It's a layer 2 solution, which means it's a child network to a major blockchain network. There are different variations to layer 2 networks, but the overall theme is that they are smaller versions of the network that write into the layer 1 network. Examples of other layer-2 solutions are Polygon for Ethereum, Loopring for Ethereum, and Lightning for Bitcoin.

Ingredients in the Lightning Network

The Lightning Network consists of three key components: lightning nodes, payment channels, and routing nodes. Lightning nodes are the machines and software that allow organizations or people to participate. Payment channels are established between two nodes to allow for off-chain transactions with fast and low-cost settlements. Routing nodes are crucial in finding and forwarding payments across the network, ensuring that transactions can reach their intended destinations efficiently. These components create a scalable and efficient network for conducting fast and secure off-chain transactions.

Lightning Nodes — The Building Blocks

Lightning nodes are machines or instances that have lightning software installed. These nodes have a full Bitcoin node, a lightning client (see the Lightning Implementation section below), and a node wallet.

A Lightning node is a piece of software that connects to the Lightning Network and allows users to transact with other nodes on the network. Anyone can run lightning nodes to send and receive payments and route payments for other users.

Lightning nodes can be set up using a machine like raspberry pi (for experimental and learning purposes), on the cloud, or bought ready-made. Below is a guide on setting up a node:

How To Set Up A Lightning Network Node

Below is a link on whether you should buy or DIY a Bitcoin lightning node:

Buy or DIY? An Overview of 7 Bitcoin Full Node Products

Payment Channels — Connecting Nodes

The lightning network is made up of a collection of payment channels. A payment channel is a connection between two nodes that allows them to transact with each other off-chain without broadcasting their transactions to the main blockchain.

A payment channel is a connection between two nodes that allows them to transact with each other off-chain without broadcasting their transactions to the main blockchain. This is the fundamental building block of the Lightning Network.

Think of it like a Thanksgiving dining table. Bob is next to Carol, and Carol is next to Alice. Alice, Carol, and Bob will all be nodes in the lightning network. Alice and Carol have a payment channel, and Carol and Bob have a payment channel.

Alice and Carol can have all the side conversations they want without sharing them with the group. There's no reason why Alice has to tell the group everything she wants to tell Carol and vice versa (unless she's roasting her). But if someone asks what they are talking about or Alice and Carol decide to bring in the group, they can summarize their conversation with the group. In this scenario, Alice and Carol have a payment channel.

With payment channels, nodes can transact with each other back and forth without ever sharing it with the larger Bitcoin network (all the nodes). The pieces they share are that they started a payment channel with each other and closed their channel with their final balances.

Routing Nodes — Connecting Payment Channels

The lightning network comprises multiple payment channels, mostly connected like a web. One party can connect with another party because the payment channels are all connected to each other.

Routing nodes act as intermediaries and use their own payment channels to route transactions and relay payments to the final destination. Routing nodes are responsible for discovering and maintaining routes through the network and ensuring that transactions are processed quickly and efficiently.

Going back to our Thanksgiving dinner… Even though Bob isn't sitting next to Alice, he can transact (give a slice of turkey 🦃) with Alice efficiently because he can go through Carol. Carol can agree to pass the turkey to Alice in exchange for payment. In this scenario, Carol would be called a routing node.

Over time as the network expands, all channels will be connected based on the theory of six degrees of separation.

Onion Routing

The technique used to route is onion routing, developed in 1998 by DARPA (Defense Advanced Research Projects Agency) and has been commonly used in Tor Networks.

Onion routing applies anonymity to a network messages by wrapping each message in distinct layers of protection to hide the routing of the messages between a client device and a destination device.

The messages are encapsulated in layers of encryption, just like layers of an onion.

In onion routing, each layer is encrypted with the public key of the next node in the route, including the final destination. The routing node receiving the onion packet only knows the address of the next node in the route, which is encrypted in the outer layer of the onion.

The routing node uses its routing table to determine the address of the next node to route the transaction and then decrypts the outer layer of the onion to reveal the address of the next node. It then encrypts the packet with the public key of the next node and sends it along to the next routing node. This process repeats until the packet reaches its final destination.

• GitHub - lightningnetwork/lightning-onion: Onion Routed Micropayments for the Lightning Network
• How does Tor actually work? | HackerNoon

🤺Different Lightning Implementations

People and organizations use lightning implementations to interact with a lightning node and do all the necessary functions. All lightning network implementations must follow the specifications defined by B.O.L.T. (Basis of Lightning Technology).

GitHub - lightning/bolts: BOLT: Basis of Lightning Technology (Lightning Network Specifications)

A few popular lightning networks that vary by language are C-Lightning, Eclair, LND, Rust LDK, and Electrum. C-Lightning is written in C, Eclair is written in Scala, LND is written in Go, Rust LDK is written in Rust, and Electrum is written in Python.

🤔Analyzing a Lightning Payment Channel

To truly understand a lightning network, it's crucial to analyze it in an explorer (i.e., mempool.space, 1ml.com, or amboss.space).

Below is a snapshot taken from "mempool.space" on channel 805523109340971008, which is used by "zero fee routing | CLN" and "BitcoinLightning.Network".

Key highlights about this network:

• The lightning nodes involved in this channel are "zero fee routing | CLN" with the address 038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5 (Location is Germany with ISP Hetzner Online GmbH [ASN 24940]) and "BitcoinLightning.Network" with the address 023c55e8e1912096ed9ef4e18859de7fa652d713e5d1f2b83a3a8b845305a4287c (Location is unknown and Tor blocks the ISP)
• "BitcoinLightning.Network" party put in all the sats to open this channel, 2,000,000 sats.
• The Bitcoin network has the opening and closing transactions of the channels, respectively, 1b6869fbb7168da402396e1a477f7a35aa238cdbdccdda7ac6af81adf5f29bbb and a3b23982331300ef8d23bd90b64e939758835515642a65ba64234bf2cae2ac7a.
• The fees to open and close this channel were $0.14 cents ($0.08 open txn fee + $0.06 close txn fee).
• This channel ran for roughly 4 days.
• During the 4 days, "BitcoinLightning.Network" sent "zero fee routing | CLN" 104,104 sats.
• After the "BitcoinLightning.Network" transferred 104,104 sats, they were left with 1,895,896 sats (2,000,000 starting balance –104104 transferred balance). After paying the closing fee of 249 sats, they have a closing balance of 1,895,647 sats (1,895,896 balance after transfers in the channel — 249 closing fee).

🌐Payment Channel Lifecycle

1. Create a Payment Channel

We need to be part of a payment channel to do anything on the lightning network. To create a payment channel, we'll have Alice and Bob go through the following steps:

Terms are Negotiated

1. Alice and Bob agree on the terms of the payment channel, including the amount of Bitcoin to be committed to the channel and the fees they will pay each other for routing payments.

Multi-Signature Wallet is Created

1. Alice creates a multi-signature wallet that requires both her and Bob's signatures to spend funds

Funding Transactions are Created & Signed

1. Alice generates a funding transaction that allocates the agreed-upon amount of BTC from her wallet to the multi-sig wallet address. This transaction is not broadcast to the Bitcoin network yet.
2. Alice shares the funding transaction details with Bob, who verifies the details and adds his own input to the transaction.
3. Bob generates a signature for the funding transaction and shares it with Alice.
4. Alice adds her own signature to the funding transaction and broadcasts it to the Bitcoin network, making the funds available in the multi-sig wallet.
5. Bob creates his own funding transaction using the same multi-sig wallet address, allocates the agreed-upon amount of BTC from his wallet, and shares the funding transaction details with Alice.
6. Alice verifies the details and adds her own input to the transaction.
7. Alice generates a signature for the funding transaction and shares it with Bob.
8. Bob adds his own signature to the funding transaction and broadcasts it to the Bitcoin network, making the funds available in the multi-sig wallet.

Announcement Transactions

1. Alice creates a new transaction that spends from the funding transaction and sends the channel's capacity to a new public key (the channel ID).
2. Bob does the same and creates a new transaction with the same inputs and outputs but with his own public key as the channel ID.
3. Alice and Bob exchange their unsigned announcement transactions.
4. Alice signs Bob's announcement transaction with her private key and sends the signed transaction to Bob.
5. Bob signs Alice's announcement transaction with his private key and sends the signed transaction back to Alice.
6. Once both parties have fully signed announcement transactions, they can broadcast them to the Bitcoin network to publicly announce the existence of the new payment channel.

2. Exchange Funds in the Payment Channel

1. The recipient (Bob) generates an invoice that includes the payment amount and a payment hash.
2. The sender (Alice) uses her Lightning wallet to scan the invoice's QR code or copy the invoice details.
3. Alice's wallet decodes the invoice and verifies that it's valid.
4. Alice's wallet constructs a Sphinx packet that includes the payment hash and encrypts it with Bob's public key.
5. Alice's wallet adds the Sphinx packet to a payment message that includes the payment amount and routes it through the Lightning network toward Bob's node.
6. The payment message is forwarded through intermediary nodes until it reaches Bob's node.
7. Bob's node decrypts the Sphinx packet with his private key to reveal the payment hash.
8. Bob's node looks up the preimage corresponding to the payment hash and includes it in a Sphinx packet that is encrypted with the previous hop's public key.
9. Bob's node sends the Sphinx packet back through the network toward Alice's node.
10. The Sphinx packet is forwarded through intermediary nodes until it reaches Alice's node.
11. Alice's node decrypts the Sphinx packet with her private key to reveal the preimage.
12. Alice's node sends the preimage to Bob's node to prove the payment has been completed.
13. Bob's node verifies the preimage, and the payment is complete.

The Invoice

All payments start with an invoice (unless it's keysend). The payee must put together an invoice. This tells the payer what network they want the payment in and the amount.

A Lightning invoice is a payment request that includes a payment hash and a preimage, which the payer must provide to settle the invoice.

Lightning invoices are generated by the payee and are used to receive payments through the Lightning Network.

Dive deeper into specifics around an invoice at the blog below:

Lightning Invoices

3. Close the Payment Channel

There are 3 ways to close a channel, a collaborative close, a force close, and a dispute close.

Below are the steps at a high level:

1. Either party initiates the closing process by sending a close transaction to the Bitcoin network.
2. The closing transaction spends the latest channel state, which includes the balance of each party.
3. The closing transaction is broadcast to the Bitcoin network and included in a block.
4. Once the closing transaction is confirmed, both parties can claim their respective channel balances on the Bitcoin network.

If one party does not agree with the channel state used in the closing transaction, they can broadcast a penalty transaction to the Bitcoin network. This penalty transaction claims all the funds in the channel for the non-compliant party.

If the penalty transaction is broadcast, it will invalidate the previous closing transaction and force the compliant party to wait until the penalty transaction confirms before claiming their funds.

Check out the write-up below for a deeper dive into closing channels:

Different Ways to Close a Lightening Payment Channel

👬Connecting to a Lightning Node via Docker

Getting Started with the Lightning Network with Docker

1. Find your machine's IP address by running the command (macOS):

ipconfig getifaddr en0

1. Find your machine's IP address by running the command (windows):

ipconfig /all

2. Set your IP address as an IP_ADDR variable. If your IP address is 192.xxx.x.xx, then run the command:

IP_ADDR=192.xxx.x.xx

3. Set a volume to store the data for the lightning node and name lnd-data:

docker volume create lnd-data

4. Run the following docker command:

docker run -v lnd-data:/lnd --name=lnd-node -d \
  -p 9735:9735 \
  -p 10009:10009 \
  lnzap/lnd:latest \
  --bitcoin.active \
  --bitcoin.testnet \
  --debuglevel=info \
  --bitcoin.node=neutrino \
  --neutrino.connect=testnet1-btcd.zaphq.io \
  --neutrino.connect=testnet2-btcd.zaphq.io \
  --autopilot.active \
  --tlsextraip=$IP_ADDR \
  --externalip=$IP_ADDR:10009 \
  --rpclisten=0.0.0.0:10009

Breakdown of this Docker Command

Below are a few highlights to notice in the docker command above.

Using the Volume lnd-data

-v lnd-data:/lnd --name=lnd-node -d

We are telling docker the node will use the volume created earlier (lnd-data)

Pulling the Zap Lightning Network Image

lnzap/lnd:latest

The image is lnzap/lnd, created by the open-source project, Zap (https://zaphq.io).

Docker

Using the Testnet Network

--bitcoin.testnet

For learning purposes, we will only use Bitcoin testnet, so we're not using any real money.

Connect to the Neutrino Public Client

We will connect to a Neutrino public client using Zap's Neutrino testnet client https://zaphq.io/.

A little bit about Neutrino…

Neutrino came out of BIPs 157/158 (Client-Side Block Filtering), which is an improvement from Bloom Filters proposed in BIP 37.

Neutrino clients are lightweight Bitcoin clients that use simplified payment verification (SPV) and client-side filtering. Client-side filtering is used to to sync with the Bitcoin network and retrieve only the transactions relevant to the user’s wallet, without having to download and verify the entire blockchain.

--bitcoin.node=neutrino \
  --neutrino.connect=testnet1-btcd.zaphq.io \
  --neutrino.connect=testnet2-btcd.zaphq.io \

Checkout Suredbits explainer for a deeper dive into Neutrino:

https://suredbits.com/neutrino-what-is-it-and-why-we-need-it/

Automatically Open Channels with Other Channels

This flag is used to activate the autopilot feature of the Lightning Network Daemon (LND). Autopilot is a feature that automatically opens channels with other nodes on the network based on certain criteria, such as channel size, uptime, and fees.

--autopilot.active \

Set an Additional IP address to include in the TLS certificate

The --tlsextraip flag adds an extra IP address to the TLS certificate that the LND node uses to establish secure connections. The $IP_ADDR variable should be replaced with the IP address of the node.

--tlsextraip=$IP_ADDR \

Advertise IP Address and Port to the Network

This tells the LND node to advertise itself to the network using the given IP address and port number ($IP_ADDR is the IP address of the node). This is useful if the node is behind a NAT or firewall and needs to be reachable from outside the network.

--externalip=$IP_ADDR:10009 \

IP Address and Port for Incoming RPC Connections

This sets the IP address and port number the LND node will listen to for incoming RPC connections. The 0.0.0.0 IP address means that the node will listen on all available network interfaces and $IP_ADDR:10009 specifies the port number to listen on.

--rpclisten=0.0.0.0:10009

📚Obsessed? More Resources

Lightning Network Original Whitepaper

https://lightning.network/lightning-network-paper.pdf

Lightning Node Setup Guide (with Docker)

Lightning Node Setup Guide (With Docker)

History of the Lightning Network Infographic

https://i.redd.it/d4ulzl8s5oq21.png

Doug von Kohorn's Run You Own Lightning Node

Run your own mainnet Lightning Node

Bitcoin Magazine: Understanding the Lightning Network — Building a Bi-Directional Payment Channel

Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel

LNBook — Mastering Lightning Network

GitHub - lnbook/lnbook: Mastering the Lightning Network (LN)

Coindesk Lightning Network Research — 2021.09

https://downloads.coindesk.com/research/Lightning+Network+-+CoinDesk+Research+-+2021.09.pdf

Getting Started with Bitcoin Lightning Network was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Lightning invoice is a payment request that includes a payment hash and a preimage, which the payer must provide to settle the invoice.

Lightning invoices are generated by the payee and are used to receive payments through the Lightning Network.

We’re going to dive into:

Anatomy of an Invoice

• Human Readable Part
• Data Part

Why Do Lightning Payments Need Invoices?

Alternatives to Payments Without Invoices — Keysend

Anatomy of an Invoice

The invoice is formatted in bech32 encoding, already used for Bitcoin Segregated Witness. It’s broken up into 2 main parts: human-readable and data portions.

Below is an example of an invoice:

lnbc15u1p3xnhl2pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs

Human Readable Part

The human-readable part has the network name and amount. In the example above lnbc15u is the human-readable part.

Network

All Lightning invoices start with the letters ln for Lightning Network. Then they are followed by a 2-letter code defined by BIP173 for the network. Below is a table with network prefixes. For example, an invoice that starts withlnbc would be in the lightning mainnet because bc is after ln.

Amount

The amounts reference bitcoin, not satoshi. To save space for round invoices, an amount can be followed by a multiplier. For example, a single satoshi Lightning invoice would appear as 10n, a hundred satoshi as 1u, and a milli-satoshi as 10p. In the example above, the amount is 15u (15* 100 satoshis). Below is a table of the amount units.

Data Part

The data part is broken up into a timestamp, payment hash, description, min block height expiry (min final CLTV Expiry), expiry, payment secret (preimage),

An easy to know the different parts is by looking for the tags. P is the tag for payment hash, D is the tag

In the example above, the data part is:

pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs

Timestamp

In the example above, the timestamp is p3xnhl2, this is equivalent to the timestamp 1651105770, which is equivalent to Monday, May 2, 2022, at 8:29:30 AM UTC.

Payment Hash

In the example above, the payment hash (tagged with p) is pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3s. The payment hash is a 32-byte hash that uniquely identifies a Lightning Network payment. This hash is used to reference the payment throughout the payment’s lifecycle, from invoice creation to the payment's fulfillment.

Description

In the example above, the description (tagged with d) is dqsvfhkcap3xyhx7un8. The description can be any text note on the invoice. The description in the example is decoded to bolt11.org.

Min Final CLTV Expiry

In the example above, the minimum final CLTV (CheckLockTimeVerify) expiry (tagged with c) is cqzpg. The minimum final CLTV is the minimum block height at which the payment can be considered final. In this example, there is a requirement of a block height of 40 to be considered final.

Expiry

In the example above, the expiry (tagged with x) is xqzjc. The expiry is the number of seconds after which the invoice will expire if the payment has not been made. In this example, the invoice will expire in 600 seconds (10 minutes) if a payment hasn’t been made.

Payment Secret

In the example above, the payment secret (tagged with s) is sp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq. The payment secret is a random 32-byte string that the payer generates, encrypted in the invoice using the shared secret. It is also known as the preimage or the payment hash preimage.

The recipient must decode the invoice to obtain the payment secret, which the payer later uses to prove the payment was successful and claim the funds in the payment channel.

The payment secret is crucial for the network’s security and privacy features because it prevents unwanted parties from intercepting or tampering with the payment.

Feature Bits

In the example above, the feature bits (tagged with 9) is 9qyyssq. Feature bits are optional or required features that can be included in the invoice to indicate to the payer which capabilities the payee’s Lightning node supports. In this example, the featured bits are:

{
"var_onion_optin": "supported", 
"payment_secret": "required", 
"basic_mpp": "supported"
} 

• “var_onion_optin”: indicates that the payee’s node supports using variable-length onion packets for routing the payment.
• “payment_secret”: indicates that the payee requires the payer to include a payment secret in the payment hash.
• “basic_mpp”: indicates that the payee’s node supports the use of basic multi-path payments, which allows a payment to be split across multiple routes.

Signature

In the example above, the signature is y4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq. A signature is a cryptographic signature created by the invoice issuer’s private key. It’s used to ensure the authenticity and integrity of the invoice. When the invoice recipient receives it, they can use the issuer’s public key to verify the signature and ensure that the invoice has not been tampered with.

Checksum

In the example above, the checksum is 4gj5hs. A checksum is a value calculated from a specific algorithm that is added to a Lightning invoice to ensure the integrity of the data and help detect errors.

Why Do Lightning Payments Need Invoices?

We need invoices in the Lightning Network to enable payments to be routed from the payer to the payee. Invoices contain important information such as the payment amount, payment hash, and other optional fields like the routing hints that enable intermediaries to discover the path to the payee. Routing nodes use invoices to determine the next hop in the payment path and forward the payment to the next node until it reaches the payee.

In addition, invoices also provide a way for the payee to request a specific payment amount and add additional metadata, such as an order number or customer ID, that can be useful for accounting or tracking purposes.

Without invoices, payers would have to manually construct payments and specify the routing path, which can be error-prone and time-consuming. Overall, invoices are critical in enabling efficient and reliable payment routing in the Lightning Network.

Alternatives to Payments Without Invoices — Keysend

Keysend is a feature introduced in the Lightning Network that allows for small and spontaneous payments without needing a Lightning invoice. With keysend, a payer can simply send a payment directly to the payee’s Lightning node by including the payment information, such as the payment amount and memo, in the onion routing packet.

To make a payment using keysend, the payer’s Lightning node generates a payment hash and constructs an onion routing packet with the payment information in the payload. The onion packet is then sent to the payee’s Lightning node, which decrypts the packet and retrieves the payment information. The payee’s Lightning node then constructs a Lightning invoice using the payment hash, which the payer’s node can use to claim the payment once they have the preimage corresponding to the payment hash.

Keysend allows for more spontaneous and efficient payments. It eliminates the need for the payee to generate a Lightning invoice and for the payer to scan the QR code or manually enter the payment information. However, it does raise some privacy concerns, as the payment information is included in the routing packet in plaintext and can be visible to all the nodes involved in routing the payment.

Resources

Interactive Invoice BOLT 11

The Lightning Invoice

Suredbits on Lightning Invoices

Lightning 101: What is a Lightning Invoice?

BOLT11 Standards on Invoices in Github

bolts/11-payment-encoding.md at master · lightning/bolts

Lightning Engineering — Understanding Lightining Invoices

Understanding Lightning Invoices

Lightning Keysend — ReadTheDocs

lightning-keysend - Send funds to a node without an invoice - Core Lightning b8519a6-modded

Voltage Keysend Payments

Lightning Keysend Payments Explained | Voltage

Lightning Invoices was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Time-Lock Delay

A time-lock delay is implemented using a CheckSequenceVerify (CSV) feature, which allows a party to set a delay on the transaction so that the other party cannot spend it until a certain amount of time has elapsed. This gives both parties time to resolve any issues that may arise, such as a channel closure or dispute over the transaction, before the funds are released.

Revocation Delay

A revocation delay is a security mechanism in the Lightning Network designed to prevent cheating in payment channel transactions. When a payment channel is opened, both parties commit to a set of transactions that can be used to close the channel and distribute the funds. The revocation delay is when one party can prove that the other party cheated by revealing a transaction that invalidates the previous transaction. If a party cheats, the other party can use this revealed transaction to claim all the funds in the channel, and the cheater is punished by losing their share of the funds.

Difference between Time-lock/CSV and Revocation Delays

Time locks/CSV determine how long a commitment transaction must be delayed, while revocation delays determine how long a revoked commitment transaction must be delayed before it can be broadcasted. The differences are subtle, so I captured them in the table below.

Time-Lock/CSV and Revocation Delays in Code

Time-lock/CSV

Time-locks/CSVs enforce the order and timing of transactions, preventing double-spending by either party in the channel. The time-lock/CSV value (number of blocks that acts as time) is set in every commitment transaction.

Below is an example of a regular off-chain commitment transaction using the LND implementation in Go. Here we are setting the csvTimeout to 144 blocks (roughly 1 day).

// Set the CSV timeout to 144 blocks (roughly 1 day)
csvTimeout := uint32(144)

After the csvTimeout is set, you can see it’s passed in as one of the values in CreateCommitTx (create a commitment transaction).

// Create the commitment transaction
commitTx, err := lnwallet.CreateCommitTx(channelState.OurBalance,
                                         channelState.TheirBalance,
                                         ourPaymentBasePoint, theirPaymentBasePoint,
                                         ourHtlcBasePoint, theirHtlcBasePoint,
                                         csvTimeout, 0, channelState.FeePerKw,
                                         channelState.LocalChanCfg.DustLimit)
if err != nil {
    // handle error
}
// Sign the transaction
localFundingKey, err := channelState.LocalChanCfg.MultiSigKey.PubKey()
if err != nil {
    // handle error
}
sig, err := wallet.Cfg.Signer.SignOutputRaw(commitTx, 0, fundingScript, localFundingKey)
if err != nil {
    // handle error
}
commitTx.TxIn[0].Witness = lnwallet.CommitSpendTimeoutWitness(sig)

Revocation Delays

Revocation delays prevent a counterparty from publishing an outdated channel state, preventing fraudulent activity. The revocation delay value (number of blocks that acts as time) is set when the channel is opened, and the initial commitment transaction is broadcasted to the network. The revocation delay is a fixed value and cannot be modified after the initial commitment transaction. Every commitment transaction has a new revocation key. The non-fraudulent party can use this key to reclaim their funds within a specific time period (revocation delay).

Below is an example of an initial commitment after a funding transaction using the LND implementation in Go. In this example, the revocation delay called RemoteCsvDelay, is set to 20 blocks.

// Create the open channel request
openChanReq := &lnrpc.OpenChannelRequest{
    NodePubkey:         remotePubKey.SerializeCompressed(),
    LocalFundingAmount: int64(fundingAmount),
    PushSat:            int64(lnd.Cfg.PushSat),
    TargetConf:         lnd.Cfg.RequiredConfirmations,
    SatPerByte:         int64(lnd.Cfg.FeePerKW),
    MinHtlcMsat:        int64(lnd.Cfg.MinHTLC),
    RemoteCsvDelay:     20,
}

Once the open channel request is prepared, it’s sent using the LND client to be opened.

// Send the open channel request
ctxb = context.Background()
response, err := lnd.Client.OpenChannel(ctxb, openChanReq)
if err != nil {
    log.Fatal(err)
}

In Conclusion…

Regarding enforcement mechanism, Time-lock/CSV utilizes time-lock for CSV, while Revocation Delays use a revocation key. Time-lock/CSV applies to every transaction in the channel, while Revocation Delays apply only to the latest transaction in the channel.

Lightning Network & Delays was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the lightning network, payment channels can close in 3 different ways, and they're good, bad, and ugly. The good is a "collaborative close" when both parties work together to close the channel. The bad is a "force close" when one party can't close the channel. The ugly is a "dispute close" when there's a force close, but the other party comes back and disputes the close initiated by the other party.

😃 Collaborative Close — Good

1. Negotiate the final channel balance
2. Initiate & Exchange Close Requests
3. Sign, Exchange & Broadcast Close Requests to the Network
4. Wait for Confirmations on the Network
5. Remove the Channel

💻 Code to do a Collaborative Close

📜 Example of a Collaborative Close Transaction

😞 Force Close — Bad

1. Initiate, Sign, and Broadcast the Force Close Request
2. Wait for the Force Close to Confirm
3. Remove the Channel

💻 Code to do a Force Close

📜 Example Forced Close Transaction

😡 Disputed Close — Ugly

💻 Code of a Dispute Close Transaction

🗼Watch Tower

📚Hooked? Dive into the Rabbit Hole

😃 Collaborative Close

A collaborative close in the Lightning Network is a channel closure where both parties agree to close the channel. With a collaborative close, both parties sign off on closing the payment channel and get their funds back immediately. Below are the steps to a collaborative close.

1. Negotiate the Final Channel Balance

Before initiating the channel closing, the parties should agree on the final balance. This can be done by exchanging commitment transactions until they reach a final balance that they both agree on.

2. Initiate Close Channel Requests & Exchange Requests

Each party must initialize a close channel request in a collaborative close. Before the request is ever signed and broadcasted to the network, it must be exchanged to ensure everyone is on the right page.

An initialize request in LND implementation involves the following details:

• Channel Point: a unique identifier for a payment channel established between two parties. It consists of the channel funding transaction hash and the index of the transaction output that funds the channel.
• Target Confirmations: How many blocks need to be mined after the close txn to consider the txn done?
• Sats Per Byte: This is the Bitcoin fee rate the party is willing to pay on the close transaction.
• Force: Since this is not a force close, force is set to false.
• Delivery Address: Specifies an address to receive the funds from the closed channel. If left empty, the funds will still be split between the two parties according to their channel balance, but any unspendable funds will go to the node that initiated (Alice) the channel closure request.

Below is the code (using the LND go implementation) to initiate the close:

// Initiate the cooperative channel close.
closeReq := &lnrpc.CloseChannelRequest{
    ChannelPoint: channelPoint,
    TargetConf:   0, // Wait for the next block.
    SatPerByte:   1, // Set the fee rate.
    Force:        false, // Initiate a cooperative closure.
    DeliveryAddress: "your_bitcoin_address", // Optional.
}
closeResp, err := client.CloseChannel(ctx, closeReq)
if err != nil {
    log.Fatal(err)
}
log.Printf("Close channel response: %v", closeResp)
closeChannelStream, err := client.CloseChannel(context.Background(), closeChannelReq)
if err != nil {
     log.Fatalf("could not initiate close: %v", err)
}

Below is the code (using the LND go implementation) to receive the close request from the remote (other) party:

// Receive close request from remote party.
closeRequest, err := closeChannelStream.Recv()
if err != nil {
     log.Fatalf("could not receive close request: %v", err)
}

3. Sign, Exchange & Broadcast Requests to the Network

Now that both parties agree on the close request, they can sign and broadcast their requests.

Below is the code (using the LND go implementation) to sign the request, send it to the remote (other) party, and receive the signed request from the remote (other) party.

// Sign the close request.
    signedCloseReq, err := client.SignMessage(context.Background(), &lnrpc.SignMessageRequest{
        Msg: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not sign close request: %v", err)
    }
// Send the signed close request to the remote party.
    _, err = closeChannelStream.Send(&lnrpc.CloseStatusUpdate{
        Update: &lnrpc.CloseStatusUpdate_SignedClosingTx{
            SignedClosingTx: signedCloseReq.Signature,
        },
    })
    if err != nil {
        log.Fatalf("could not send signed close request: %v", err)
    }
    // Receive the fully signed close request from the remote party.
    closeRequest, err = closeChannelStream.Recv()
    if err != nil {
        log.Fatalf("could not receive fully signed close request: %v", err)
    }

Below is the code (using the LND go implementation) to broadcast the close channel transaction to the Bitcoin network.

// Broadcast the close transaction to the Bitcoin network.
    _, err = client.SendRawTransaction(context.Background(), &lnrpc.SendRawTransactionRequest{
        TxHex: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not broadcast close transaction: %v", err)
    }

4. Wait ⏰ for Confirmations on the Network

Wait for the TargetConf stated during the initiation, these are the number of blocks that need to be added after the close transaction is committed to the Bitcoin network (in this example, Alice is waiting for 6 blocks).

Below is the code (using the LND go implementation) to wait for the confirmations.

// Wait for the channel to be closed and remove it from local storage.
    waitCloseReq := &lnrpc.WaitForFinishedRequest{
        ChannelPoint: channelPoint,
    }
    _, err = client.WaitForChannelClosed(context.Background(), waitCloseReq)
    if err != nil {
        log.Fatalf("could not wait for channel to close: %v", err)
    }

5. Remove the Channel

Most implementations handle the channel removal on the network automatically. But even though the channel is removed from the network, the channel's information will still exist in the network.

You may want to remove a channel from your Lightening node's storage to free up disk space, improve your node's performance, or reduce your configuration's complexity.

Below is the code (using the LND go implementation) to remove the channel from local storage.

_, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }

Warning — Loss of Information:

Removing the channel state from your Lightning Network node will permanently delete all information associated with the closed channel, including the transaction history and any funds remaining in the channel.

This is why it’s important to make sure that the channel has been fully closed and settled on the Bitcoin network before removing the channel state from your node.

Warning — Wait for Pending HTLC’s

Wait for any pending HTLCs to expire: If there were any pending HTLCs (hash time-locked contracts) on the channel at closing, you should wait for them to expire before removing the channel state from your node.

This is because HTLCs have a time-out period during which the counterparty can redeem them. Once this time-out period has expired, the HTLCs will be resolved on-chain, and the remaining funds will be returned to the appropriate parties. Once all pending HTLCs have expired and been resolved, you can safely remove the channel state from your node.

Example Code to do a Collaborative Close

package main

import (
    "context"
    "fmt"
    "github.com/lightningnetwork/lnd/lnrpc"
    "google.golang.org/grpc"
    "log"
)
func main() {
    // Set up a connection to the lnd instance running locally.
    conn, err := grpc.Dial("localhost:10009", grpc.WithInsecure())
    if err != nil {
        log.Fatalf("could not connect to lnd: %v", err)
    }
    defer conn.Close()
    client := lnrpc.NewLightningClient(conn)
    // Set the channel point you want to close.
    channelPoint := &lnrpc.ChannelPoint{
        FundingTxidStr: "funding_transaction_id",
        OutputIndex:    0,
    }
    // Start a cooperative close for the channel.
    closeChannelReq := &lnrpc.CloseChannelRequest{
        ChannelPoint:  channelPoint,
        TargetConf:    6,
        SatPerByte:    1,
        DeliveryAddr:  "", // Optional, if not provided the closing funds go to the channel initiator.
        Force:         false,
    }
    closeReq := &lnrpc.CloseChannelRequest{
      ChannelPoint: channelPoint,
      TargetConf:   0, // Wait for the next block.
      SatPerByte:   1, // Set the fee rate.
      Force:        false, // Initiate a cooperative closure.
      DeliveryAddress: "your_bitcoin_address", // Optional.
    }
    closeChannelStream, err := client.CloseChannel(context.Background(), closeChannelReq)
    if err != nil {
        log.Fatalf("could not initiate close: %v", err)
    }
    // Receive close request from remote party.
    closeRequest, err := closeChannelStream.Recv()
    if err != nil {
        log.Fatalf("could not receive close request: %v", err)
    }
    // Sign the close request.
    signedCloseReq, err := client.SignMessage(context.Background(), &lnrpc.SignMessageRequest{
        Msg: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not sign close request: %v", err)
    }
    // Send the signed close request to the remote party.
    _, err = closeChannelStream.Send(&lnrpc.CloseStatusUpdate{
        Update: &lnrpc.CloseStatusUpdate_SignedClosingTx{
            SignedClosingTx: signedCloseReq.Signature,
        },
    })
    if err != nil {
        log.Fatalf("could not send signed close request: %v", err)
    }
    // Receive the fully signed close request from the remote party.
    closeRequest, err = closeChannelStream.Recv()
    if err != nil {
        log.Fatalf("could not receive fully signed close request: %v", err)
    }
    // Broadcast the close transaction to the Bitcoin network.
    _, err = client.SendRawTransaction(context.Background(), &lnrpc.SendRawTransactionRequest{
        TxHex: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not broadcast close transaction: %v", err)
    }
    // Wait for the channel to be closed and remove it from local storage.
    waitCloseReq := &lnrpc.WaitForFinishedRequest{
        ChannelPoint: channelPoint,
    }
    _, err = client.WaitForChannelClosed(context.Background(), waitCloseReq)
    if err != nil {
        log.Fatalf("could not wait for channel to close: %v", err)
    }
    _, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }
    fmt.Println("Channel closed.")
}

Example of a Collaborative Close Transaction

Transaction a3b23982331300ef8d23bd90b64e939758835515642a65ba64234bf2cae2ac7a is an example of a collaborative closure.

Force Close

A force close happens when one of the parties is offline, so the other party unilaterally forces the channel to close. There are fewer steps in a force close because there aren't exchanges between parties since it's a one-person show.

1. Initiate, Sign, and Broadcast the Force Close

Below is the code (using the LND go implementation) to create the force close request. Notice that now the Force the field is marked true.

// Create the force close channel request
    request := &lnrpc.CloseChannelRequest{
        ChannelPoint:       channelPoint,        
        Force:              true,
        TargetConf:         6,
        SatPerByte:         10,
        DeliveryAddress:    "",
        ForceTargetChanId:  0,
        Anchors:            false,
    }

Below is the code (using the LND go implementation) to initiate the force close request. We are using the client to broadcast the close request here.

// Initiate the force close request
    response, err := client.CloseChannel(context.Background(), request)
    if err != nil {
        log.Fatalf("could not initiate force close: %v", err)
    }
    log.Printf("force close initiated: %v", response)

2. Wait ⏰ for the Force Close to Confirm

With force close, the party initiating the close has a waiting period (time lock), giving the counterparty enough time to respond.

Local and Remote Force Close

There are two types of forced closures, remote and local. It depends on who is initiating the forced closure. If you are initiating the forced closure, you are dealing with a local force close, and if you aren’t initiating the forced closure, then you are dealing with a remote force close.

This time lock prevents the funds from being spent for a certain period. This time lock is known as the CSV (Check Sequence Verify) value, and it ensures that both parties can dispute the force close and prevent fraud.

Below is the code (using the LND go implementation) to enforce the time-lock/CSV.

// Wait for the force close to be confirmed
    time.Sleep(10 * time.Minute)

In the Lightning Network, security is enforced, and honesty is incentivized using delays. The Lightening Network has two types of delays time-lock and revocation delays. If you want to dive deeper into those concepts, check out the article below:

Lightning Network & Delays

3. Remove the Channel

After the time-lock expires, the channel closure is complete, and now we can remove the channel from local storage.

Below is the code (using the LND go implementation) to remove the channel from local storage.

// Remove the closed channel from the node's local storage
    _, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }

Example Code to do a Force Close

package main

import (
    "context"
    "log"
    "time"
    "github.com/lightningnetwork/lnd/lnrpc"
    "google.golang.org/grpc"
)
func main() {
    // Create a connection to the LND instance
    conn, err := grpc.Dial("localhost:10009", grpc.WithInsecure())
    if err != nil {
        log.Fatalf("could not connect to LND: %v", err)
    }
    defer conn.Close()
    // Create a new LND client
    client := lnrpc.NewLightningClient(conn)
    // Define the channel point to be closed
    channelPoint := &lnrpc.ChannelPoint{
        FundingTxid: &lnrpc.ChannelPoint_FundingTxidStr{
            FundingTxidStr: "FUNDING_TXID",
        },
        OutputIndex: OUTPUT_INDEX,
    }
    // Create the force close channel request
    request := &lnrpc.CloseChannelRequest{
        ChannelPoint:       channelPoint,
        Force:              true,
        TargetConf:         6,
        SatPerByte:         10,
        DeliveryAddress:    "",
        ForceTargetChanId:  0,
        Anchors:            false,
    }
    // Initiate the force close request
    response, err := client.CloseChannel(context.Background(), request)
    if err != nil {
        log.Fatalf("could not initiate force close: %v", err)
    }
    log.Printf("force close initiated: %v", response)
    // Wait for the force close to be confirmed
    time.Sleep(10 * time.Minute)
    // Remove the closed channel from the node's local storage
    _, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }
    log.Println("force close complete")
}

Example Forced Close Transaction

Transaction f9b48496a3b16693460a447a224b102d4fb3d38bb9473dc865fb5ce6e71761bd is an example of forced closure. There are key features

If you dig a little deeper and look at the lightning channel details, you can see that Bitcoin Revolution was the one that opened and closed the channel (704410x953x0) unilaterally. Also, notice that the fees are considerably higher than a collaborative close. This transaction has a $0.67 fee, while the collaborative close (mentioned earlier) has a $0.06 fee. Force closes have higher fees because they use a time-critical pre-signed transaction.

Disputed Close

Previously in the force close, Alice had to wait (time-lock/CSV) to give the other party a chance to come back on and dispute. In this scenario, the other party returned online within the wait time (time-lock/CSV) and disputed the force close.

In this example, Bob noticed that Alice made a force close request to the network. Luckily, Bob has the wait time (time-lock/CSV) ⏰ to dispute her close.

How would Bob dispute Alice's force close?

Bob needs to publish the most recent state of the channel before the time lock expires. If Bob publishes the most recent state within the time-lock wait time, he can publish a justice transaction 🏛 👩‍ ⚖. The justice transaction 🏛 👩‍ ⚖ will allow Bob to take everything.

What are justice transactions?

Justice transactions 🏛 👩‍ ⚖ use game theory to secure the lightning network, and if you're dishonest, you can lose it all, so the incentive of being dishonest must outweigh the risk of losing all your funds. BitMEX published research on the effectiveness of justice transactions.

BitMEX Research Confirms Lightning 'Justice' Works

When does 🏛 👩‍ ⚖ justice transactions happen?

After the breach close transaction is confirmed on the Bitcoin network, the channel will enter into the “Pending Force Close” state.

At this point, the justice transaction will be broadcasted by the LND node to claim the channel’s funds and penalize the counterparty.

Example Code of a Dispute Close Transaction

The code below walks through the steps Bob needs to take using the LND implementation in Go.

import (
 "context"
 "log"
 "github.com/lightningnetwork/lnd/lnrpc"
 "google.golang.org/grpc"
)
func main() {
 // Create a connection to the LND instance
 conn, err := grpc.Dial("localhost:10009", grpc.WithInsecure())
 if err != nil {
  log.Fatalf("could not connect to LND: %v", err)
 }
 defer conn.Close()
 // Create a new LND client
 client := lnrpc.NewLightningClient(conn)
 // Define the channel point to be disputed
 channelPoint := &lnrpc.ChannelPoint{
  FundingTxid: &lnrpc.ChannelPoint_FundingTxidStr{
   FundingTxidStr: "FUNDING_TXID",
  },
  OutputIndex: OUTPUT_INDEX,
 }
 // Create the breach close transaction request
 request := &lnrpc.BreachCloseChannelRequest{
  ChannelPoint: channelPoint,
  SweepAddress: "YOUR_SWEEP_ADDRESS",
 }
 // Generate the breach close transaction
 response, err := client.BreachCloseChannel(context.Background(), request)
 if err != nil {
  log.Fatalf("could not generate breach close transaction: %v", err)
 }
 log.Printf("breach close transaction generated: %v", response)
 // Broadcast the breach close transaction to the network
 _, err = client.PublishTransaction(context.Background(), &lnrpc.PublishTransactionRequest{
  Transaction: response.SignedTransaction,
 })
 if err != nil {
  log.Fatalf("could not publish transaction: %v", err)
 }
 log.Println("breach close transaction published to network")
 // Wait for the breach close transaction to be confirmed
 // TODO: implement waiting code
 log.Println("dispute complete")
}

🗼Watch Tower

In the scenario described above, Bob had to check the status of his payment channel continuously, or it might have been luck that he caught Alice the one time he checked his payment channel.

In most scenarios, it's advisable to use a watch tower to automate the monitoring of your payment channel and, in the case of fraudulence, publish the most recent state and a justice transaction. The watchtower does everything Bob was doing in the previous scenario.

🗼What is a Watchtower?

Watchtower is a lightning node that watches the chain on behalf of a 3rd party that can send justice transactions when it detects a breach.

🗼How the Watchtower knows it should dispute the close?

Every time the channel’s state is updated (Bob and Alice transact on the channel), Alice and Bob contact the watchtower with a status update.

The status update has a fixed-size encrypted blobs and is only able to decrypt and publish the justice transaction after the offending party has broadcast a revoked commitment state.

🗼Could the Watchtower eavesdrop?

Client communications with a watchtower are encrypted and authenticated using ephemeral (temporary) keypairs, mitigating the amount of tracking the watchtower can perform on its clients using long-term identifiers.

Below is code using LND implementation in Go to implement a watchtower.

import (
 "github.com/lightningnetwork/lnd/watchtower/client"
)
// create a client config with the necessary parameters
config := client.Config{
    DialAddr:        "localhost:9911",
    PubKey:          pubkey,
    PrivKey:         privkey,
    ChainHash:       chainhash,
    DB:              db,
    SessionBackup:   sessionBackup,
    SweepFeeRate:    sweepFeeRate,
    RewardAddress:   addr,
    Resolver:        resolver,
    Net:             net,
    EpochRegistrar:  epochRegistrar,
    DebugLogger:     logger,
    ErrorLogger:     logger,
}
// create a new watchtower client
watchtowerClient, err := client.New(config)
if err != nil {
    log.Fatalf("unable to create watchtower client: %v", err)
}
// create a new breach observer to watch for channel breaches
observer := watchtower.NewBreachObserver(watchtower.BreachObserverConfig{
    Backend:   backend,
    ChainHash: chainhash,
})
// start the observer and begin watching for breaches
if err := observer.Start(); err != nil {
    log.Fatalf("unable to start observer: %v", err)
}

In a Trusting World, Would We Only Use Collaborative Closes?

Most likely, you will deal with forced closes. Collaborative closes require both nodes to always be up and running, and synchronization between the two nodes after transactions are complete.

Constant Node Uptime is Unrealistic

With node issues, network, and power outages, node uptime is a major issue. This isn't just a Bitcoin or Blockchain node issue but a major issue in tech; even giants like Amazon and Google cloud providers face these issues.

Channel Nodes are Not Always in Communication

There's a chance that one of the nodes in a payment channel goes MIA (missing in action). They may want their funds but forgot to close the channel or abandoned their node altogether. Think about all those unclaimed funds in your Venmo account. I know I am not the only one letting them sit there. Even though the other party may be happy to let their funds sit in the channel, the other party may have a greater urgency to close.

📚Hooked? Dive into the Rabbit Hole

BOLT Rules on Closing Transactions

bolts/02-peer-protocol.md at d975de1ba5d3e8aca586154ae0cae8f1b3181495 · lightning/bolts

Bitcoin Lightning Transactions & Protocol Deep Dive

Ligthning Engineering

Lifecycle of a Payment Channel

L.N. Guide

LN.Guide

Raphael Osaze Eyerin Lightening Payment Channel

Lightning Payment Channels

The Bitcoin Manual

How To Close A Lightning Channel? - The Bitcoin Manual

BOLT to identify Justice Transactions

bolt03/is_remedy_witness.js at master · alexbosworth/bolt03

How to Set up a Watchtower for an Umbrel Bitcoin Lightening Node

How To Set Up A Watchtower For An Umbrel Bitcoin Lightning Node

LND Watchtower

lnd/watchtower.md at master · lightningnetwork/lnd

Lightening Network Watchtower

Lightning Network Watchtower * LightningNetwork+

Decred Documentation on Watchtowers

Watchtowers - Decred Documentation

New to trading? Try crypto trading bots or copy trading on best crypto exchanges

Join Coinmonks Telegram Channel and Youtube Channel get daily Crypto News

Also, Read

• Free Crypto Signals | Crypto Trading Bots
• An ultimate guide to Leveraged Token
• 16 Best Folding Electric Bikes
• 28 Best Electric Bikes Review
• Top 3 Binance Futures Trading Bots

Topics

🏊What are Liquidity Pools?

💰Where are Liquidity Pools Used?

🦄 Creating a Liquidity Pool

🙅🏽‍♂️ Risks with Liquidity Pools — Impermanent Loss

📈 Pricing with Liquidity Pools — Price Feed Oracles

📚Hooked More Resources on Liquidity Pools

🏊 What are Liquidity Pools?

Liquidity pools are a collection of assets locked into a smart contract. This collection of assets provides decentralized financial (DeFi) products capital to execute transactions like derivatives, lending, and trading efficiently. In other words, they are the goods needed on the other side to make the transaction happen.

DeFi products want to continuously provide these products, so they need to preserve their liquidity pool over time. Liquidity pools maintain long-term liquidity using an algorithm that utilizes supply and demand principles. It will adjust the asset price depending on the supply of the token.

Liquidity pool instances are powered by a smart contract, AMM (automated market makers). An AMM is a smart contract with algorithms (constant product) that adjust the price to maintain the supply of a token.

What’s the difference between liquidity pools, AMM, and the constant product algorithm?

It can be confusing how liquidity pools and AMM are often used interchangeably, and AMM and constant product algorithms are used interchangeably.

Liquidity pools are a concept of locking tokens into a smart contract to provide liquidity for a pair or set of assets.

AMM is the smart contract that’s created for liquidity pools. Inside the AMM smart contract, there is an algorithm or set of algorithms used to set the price of the tokens.

Constant Product Algorithms are the most popular algorithm used in AMM smart contracts.

In one of the most popular liquidity providers, Uniswap, the algorithm is called Constant Product. The algorithm(s) vary depending on the protocol, and the constant product mostly pertains to Uniswap.

Who can create a Liquidity Pool?

Anyone can become a liquidity provider (LP) for a pool by depositing an equivalent value of each underlying token in return for pool tokens. These tokens track pro-rata LP (liquidity pool) shares of the total reserves and can be redeemed for the underlying assets at any time.

💰Where are Liquidity Pools Used?

Liquidity pools are used across many products in the DeFi space, like derivatives, lending, and decentralized exchanges.

Derivatives

To cater to common derivative instruments like options, futures, and perpetual futures, crypto derivative platforms require liquidity locked in for a future date.

If the platform doesn’t have the promised funds on the set future date, it will default on its contract. Platforms that offer perpetual contracts must be consistently liquid because the future date is unknown.

With derivatives, there is a concept called liquidation event. With derivatives, any losses from the trade need to be funded from the margin. If the price moves against the trader’s open position, unrealized losses erode the margin provided by the trader. The trader's position must be liquidated when these losses become equal to the margin.

Long story short, derivative platforms need to be prepared to liquidate their customers at a moment’s notice.

New to trading? Try crypto trading bots or copy trading on best crypto exchanges

More on Crypto Derivatives can be found here:

A Beginners Guide to Crypto Derivatives

Lending

In lending protocols like Compound, that’s not peer-to-peer lending; funds are borrowed against liquidity pools. Lenders who lend their funds to the lending protocol create a single-asset liquidity pool.

In this single-asset liquidity pool, the funds deposited for lending becomes a fungible resource, and ERC20 tokens (“cTokens with Compound”) that represent the deposited funds are issued to the depositor. Depositors can redeem these cTokens at any time for their underlying tokens. As interest accrues over time, the depositor can redeem cTokens at an exchange rate relative to the supplied assets.

Decentralized Exchanges

In decentralized exchange protocols like Uniswap, that’s not peer-to-peer trading; funds are traded against liquidity pools. When a liquidity provider creates a liquidity pool with a pair of tokens, they create a dual asset liquidity pool.

A dual asset liquidity pool maintains a 50/50 ratio of the pair of tokens. Traders constantly need a way to liquidate their assets, and liquidity pools in DEXs ensure the asset will remain liquid by setting the price using AMM (automated market-making algorithms), which influences the supply.

This post will focus more on liquidity pools created for DEXs like Uniswap, and we will dive into details on AMM.

Note: There are liquidity pools for decentralized exchanges that can support liquidity pools of a maximum of 8 tokens like Balancer

🦄 Creating a Liquidity Pool

To understand how Liquidity Pools are created, we will use the 50:50 dual liquidity pool often used by Uniswap. In 50:50 dual liquidity pools, each asset’s total value is equivalent to the other.

Liquidity pools are like mini stores. Let’s say we have a store that doesn’t accept fiat cash; instead, you must buy apples for grapes and vice versa.

This store has 2 Apples and 8 Grapes, so we’re contributing 10 fruits. Each apple is equivalent to 4 grapes, and each grape equals 1/4th an apple.

Notice that each asset’s total value should be equivalent to each other, the 2 apples are equal to 8 grapes, and 8 grapes are equivalent to 2 apples. This is a key feature in 50:50 dual pools.

Below is an illustration of our liquidity pool.

To create this liquidity pool, we need to create a smart contract and deploy that smart contract to a blockchain network. To create and deploy the liquidity pool contract, we use platforms like Uniswap or Balancer, which also act as DEXs (decentralized exchanges). These platforms require us to connect our wallets and fill out a form about our liquidity pool. Once that’s completed, the platform generates the smart contract and deploys it.

The article and video below break down how to create a liquidity pool on a platform like Uniswap:

Deep End of Liquidity Pool in the DEX Space?

Managing Supply & Demand in the Liquidity Pool

The goal is to keep this “store” liquidity pool useful for as long as possible, so we need to constantly adjust the price to maintain a sufficient supply of assets. We accomplish this with the constant product formula.

Constant Product Formula

The constant product formula uses the supply of both assets (apples and grapes) to preserve the constant supply.

Uniswap, one of the most popular liquidity pools and decentralized exchanges, uses the formula constant products.

x * y = k

x = token x quantity, y = token y quantity, k = constant quantity

The formula states that trades must not change the product (k) of a pair's reserve balances (x and y). Because k must remain unchanged, it is often referred to as invariant or constant.

Defining our k, Constant/Invariant

Our liquidity pool has 2 apples and 8 grapes, so using the formula above, the constant product would be 16.

2 Apples * 8 Grapes = 16 = k

16 is our golden number, our constant, and we must maintain this constant throughout.

Change in Supply & Price

Chef Alice wants to start creating her wine and needs four grapes.

How many apples would 4 grapes cost?

With liquidity pools, the price is determined by the amount that will be purchased. If Alice wanted to buy 1 grape or 5 grapes, the price per grape would be different because the price adjusts with the supply & demand of the asset. It’s like surge pricing or how stocks are priced, they adjust in price throughout the day depending on different factors.

Right now, we have 8 grapes in total, and Alice wants 4 grapes for her wine, which would leave us with 4 grapes after her purchase.

What are the remaining Grapes After Purchasing 4 Grapes? 4 Grapes

8 Total Grapes - 4 Grapes Taken = 4 Grapes Remaining

After this order, we would have just 4 grapes left, if Chef Alice takes any more grapes, we’re out of business! So we need to increase 📈 the price of grapes.

To increase the price of grapes, we go back to our constant defined earlier, which is 16. Remember the 1st rule of liquidity pools, we must always maintain our constant, that’s defined by x * y = k. To maintain our constant, we must figure out how many apples to fulfill Chef Alice's order of 4 grapes.

How Many Apples Does the Pool Need for 4 Grapes? 4 Apples

16 / 4 Grapes Remaining After Order = 4 Apples Required in Pool

If we have 4 grapes and 4 apples, we would be able to maintain our constant of 16.

Would the New Supply Maintain the Constant, K? Yes

4 Grapes * 4 Apples = 16, our constant is preserved

How many Apples would 4 Grapes Cost? 2 Apples

4 Apples required - 2 Apples in Pool = 2 Apples Required for 4 Grapes

The calculation above can be simplified to the formula below

x = apple supply, y = grape supply, px = amount of x purchased, py = amount of y purchased

If x is being purchased
((x * y)/(x - px)) - y

If y is being purchased
((x * y)/(y - py)) - x

So for our pool with 2 apples and 8 grapes, where Chef Alice is purchasing 4 grapes, the cost of 4 grapes would be 2 apples.

((2 apples * 8 grapes)/(8 grapes - 4 grapes purchased)) - 2 apples= 2 grapes

The price of the grapes is significantly much higher because this formula is ratio oriented. If there are more apples and grapes in the pool, the price of each asset won’t fluctuate as much. Let’s say we had 200 apples and 200 grapes. If chef Alice took 2 apples, the price of the 2 apples would only be 2 grapes.

200 Apples * 200 Grapes = 40000 is the constant

200 Apples - 2 Apples for Alice's recipe = 198 remaining Apples

40000 / 198 Apples remaining = 202 Grapes are needed in the pool

202 Grapes needed in the pool - 200 Grapes in the pool = 2 Grapes is the price for 2 Apples

We can also use our formula to determine how many apples it would cost the 2 grapes.

((200 * 200)/(200 - 2) - 200 = ~2 Grapes is the cost for the 2 Apples

Slippage

The increased quantity also provides a lower slippage, a difference between the executed and expected prices. If someone leaked Alice’s wine recipe and everyone in town wanted to start buying grapes to try out her recipe, the price of grapes would fluctuate depending on how large the quantity is. High liquidity prevents slippage, so if the quantity is significantly larger than the orders coming in, the price wouldn’t fluctuate as much and will be more predictable.

Note: This is a very simplified run through of the Constant Product formula, to get into the details checkout Uniswap’s whitepaper:

https://uniswap.org/whitepaper-v3.pdf

🙅🏽‍♂️Risks of Liquidity Pools — Impermanent Loss

Impermanent loss is the biggest risk of being a liquidity provider (LP). Impermanent loss can be monitored, but it’s only a loss until you withdraw funds from your liquidity pool.

Impermanent Loss is the loss LP faces for putting their tokens into a liquidity pool instead of holding them.

When does Impermanent Loss Occur?

Impermanent loss occurs when the two tokens you added to the liquidity pool stray further away from their counterpart’s original price.

Think of the two tokens in the pool as friends; they always need to succeed and fail together. One can’t succeed while the other stays stagnant, and one can’t succeed, and the other fails.

If the price of the tokens is drifting off from each other, you’ll have a greater chance of experiencing impermanent loss.

If the price of the tokens moves in the same direction, you have less chance of experiencing impermanent loss.

Note: Depending on the fees collected for each trade, the liquidity mining options, and the degree to which the assets price moves, the impermanent loss may or not be significant or even be considered a loss.

Impermanent Loss in our Grape & Apple Liquidity Pool

Refresher on Current Liquidity Pool State

Before getting into impermanent loss, let’s refresh ourselves on the current state of our liquidity pool. After Chef Alice purchased 4 grapes, we now have 4 apples and 4 grapes in our liquidity pool, and we are still maintaining our k (constant) 16.

The “Others” Contributing to Our Liquidity Pool

Other people want to contribute to our liquidity pool and add their grape and apple tokens. They add 4 more apple tokens and 4 more grape tokens.

With the additional 4 apples and 4 grape contributions, the grape and apple liquidity pool have 8 apples and 8 grapes. Since your contributions account for 50% of the pool, you will get LP Tokens representing a 50% share.

Current Price of Apples

Using the calculation we used in the above section, “Managing Supply & Demand in the Liquidity Pool,” we can use the same calculations to determine the price of one Apple in our pool.

If x is being purchased
((x * y)/(x - px)) - y

If y is being purchased
((x * y)/(y - py)) - x

(8 apples * 8 grapes) / (8 apples - 1 apple purchase) - 8 grapes = 1.14 grapes is the cost

Or we can break down the calculations accordingly:

With the additional 4 grapes and 4 apples, what is our constant? 64
8 apples * 8 grapes = 64 = k

After one apple is purchased, how many apples remain in the pool? 7
8 Apples in Pool - 1 Apple = 7 Apples Remaining

How many grapes would we need in the pool after selling 1 apple? 9.14
64 / 7 remaining Apples= ~9.14 grapes needed in pool

Does 9.14 grapes and 7 apples help us maintain our constant? Yes
9.14 grapes needed * 7 remaining apples = ~64

How many grapes would an apple cost? 1.14 grapes
9.14 grapes needed in pool - 8 grapes in pool = 1.14 grapes

The Price Hike

Chef Alice decides to share her famous apple pie recipe, so now everyone and their mother wants to make her famous apple pie. This brings up the demand for apples, causing the price of each apple to increase from 1.14 grapes to 3 grapes, bringing a price increase of 60%.

While the price of apples increased by 60%, the price of grapes stayed the same, making this situation a likely case of impermanent loss.

The Arbitrage Moment

While most exchanges increased the price of apples from 1.14 to 3 grapes, your liquidity pool still has apples at 1.14 grapes. Now your apples are a discount compared to the price at most exchanges. Chef Bob sees this arbitrage opportunity and buys 2 apples from your pool for 1.14 grapes each and sells it to another in exchange for 3 grapes each, making a profit of 1.86 grapes for each apple and a total profit of 3.72 grapes.

Bob spent 2.28 grapes for 2 apples
2 apples * 1.14 grapes ea. in your pool = 2.28 grapes for 2 apples from your pool

Bob made 6 grapes for selling 2 apples
2 apples * 3 grapes ea. in other exchange = 6 grapes for 2 apples in other exchange

Bob made a profit of 3.72 grapes in arbitrage
6 grapes from exchange - 2.28 grapes from your pool = 3.72 grapes in profits

People like chef Bob will continue to buy apples from your pool until the global price matches your liquidity pool price. If the price is the same or slightly less, it wouldn’t make sense with the trading fees to go through this effort of buying from one exchange and selling to another.

Calculating Impermanent Loss

The formula below will help you calculate the impermanent loss.

We determine the number of assets we will withdraw from the pool using the formula below. We will measure the value of x against y, if we were to measure ETH against the dollar, then ETH would be x, and y would be the dollar.

Assets you will you withdraw, y is the asset you measure value with
√(k/r) * lp share = x
√(k*r) * lp share = y

Since we’re using a 50:50 pool, the value of both assets should be equivalent. So can calculate the value of asset y and multiply it by 2.

In a 50:50 pool the value of x and y should equal each other
x * r = y

LP Value -> Total value of assets withdrawn
(√(k*r) * lp share) * 2 = lp value

Impermanent loss is the difference between the liquidity pool value of assets and the value of assets if they were just held (hodl), often this value is calculated as a percentage of difference.

Hodl Value -> Total value of assets initally put in with today's new price
(x * r) + y = hodl value

Impermanent Loss
(lp value - hodl value / hodl value) * 100

Knowing all of this, we can summarize the formula for impermanent loss as the formula below:

Let’s apply this to our scenario; if you were F12 on your browser and run the javascript formula below in your console, you would get the impermanent loss calculation.

Math.abs(((Math.sqrt(64 * 3) * .50 * 2) - (4 * 3 + 4))/(4 * 3 + 4) * 100)

Below we’ll go through how we got each value and break down the calculation.

How many grapes and apples are left after the arbitrage process?

Ratio of Apples to Grapes (1 APL = 3 GRP), Ratio is y price in x
r is 3 = 3/1

How many apples are remaining after arbitrage? 4.62 apples
x = √(64/3) = 4.618802153517006

How many grapes are remaining after arbitrage? 13.86 grapes
y = √(64 * 3) = 13.856406460551018

How much do you get when you withdraw 50% from the pool?

You get 2.31 apples and 6.93 grapes when you withdraw
4.62 apples in pool * 0.5 = 2.31 apples is your share

13.86 grapes in pool * 0.5 = 6.93 grapes in your share

In your initial deposit, you put in 4 apples and 4 grapes and leave with 1.69 fewer apples and 2.93 more grapes. So if you were to measure everything in grapes, are you walking away with more grapes?

Are we following the 50:50 balance? Yes
2.31 apples * 3 grapes = 6.93 grapes 
6.93 grapes from the value of apples = 6.93 grapes

How many total grapes did you withdraw? 13.86 grapes
6.93 grapes from Apples + 6.93 grapes in your share = 13.86 grapes

What if you just held your assets, how many grapes would you have today? 16 grapes
(4 apples * 3 grapes) + 4 grapes = 16 grapes

What is the difference if you held vs liquidity pool? 2.14 grapes
16 grapes if you held - 13.86 grapes from liquidity pool = 2.14 grapes

What is the impermanent loss? 13.38%
(2.14 grapes difference / 16 grapes if held) * 100 = 13.38%

Using the formula, you can start to see a pattern that can be illustrated in the graph below. The graph shows that the loss increases steeply as the price change increases. If the price change is 2x, then there is a ~6% loss, 3x, then there is a ~12.5%; and if the price change is 5x, then there is a ~25% loss.

Check out Eric Eric Falkenstein substack on calculating impermanent loss for a deeper dive into the formula.

A Simpler Formula for Impermanent Loss

There are a lot of calculations here, but luckily there is a tool to help you manage your impermanent loss, APY.vision (https://app.apy.vision/).

Note: This is an overly simplified example that excludes several market conditions below are different factors that affect impermanent loss. All these calculations exclude trading fees earned from each trade.

More on impermanent loss:

• Impermanent Loss Explained With Examples & Math - The Chain Bulletin
• Uniswap: A Good Deal for Liquidity Providers?

📈 Pricing with Liquidity Pools — Price Feed Oracles

The by-product of liquidity pools is pricing oracles. Liquidity pools serving as pricing oracles offer access to historical price and liquidity data that enable other DeFi products.

A little bit about Oracles…

Oracles are data feeds that bring data from off the blockchain (off-chain) data sources and puts it on the blockchain (on-chain) for smart contracts to use.

Types of Pricing Oracles

Even though they all do the same job, they all come in different flavors and vary on the frequency data is extracted, the direction data flows, and the way the data is added to the smart contract. There are different price feed oracle design patterns, immediate read, publish-subscribe, and request response.

Below are a few of the popular implementations of price-feed oracles.

Risks

Price feeds come with several risks if they aren’t implemented correctly, the biggest being price manipulation. The biggest instance was the Harvest Finance exploit, resulting in a $33 million collective loss.

Check out Open Zeppelin’s write-up on price feeds:

Smart Contract Security Guidelines #3: The Dangers of Price Oracles - OpenZeppelin blog

📚Hooked More Resources on Liquidity Pools

Comparison of Uniswap v1, v2, and v3

Uniswap V1 to V3, a table

TWAP Oracles vs. Chainlink Price Feeds: A Comparative Analysis

TWAP Oracles vs. Chainlink Price Feeds: A Comparative Analysis

How to Retrieve Price Data in Smart Contracts

How to Retrieve Price Data in Smart Contracts

Uniswap Github

Uniswap Labs

Balancer Github

Balancer Labs

Curve Github

Curve

Deribit Education Liquidation

Liquidation

Uniswap: A Good Deal for Liquidity Providers

Uniswap: A Good Deal for Liquidity Providers?

Why are you miscalculating your impermanent loss and how to stop doing it

Why Are You Miscalculating Your Impermanent Loss And How To Stop Doing It

Impermanent Loss Calculator

Impermanent Loss Calculator With APR, APY And Profit & Loss - Crypto Crab

What is Imperment Loss

What Is Impermanent Loss? Examples & How To Avoid It | Finder.com

Dipping into a Liquidity Pool was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here we’ll take a deep dive into how decentralized exchanges works with liquidity pools and create a liquidity pool on Uniswap. If you’re not familiar with the fundamentals of liquidity pools then check out part 1, “Dipping into Liquidity Pools”

Dipping into a Liquidity Pool

Topics

How Centralized Exchanges Get Liquidity?

How Decentralized Exchanges Get Liquidity?

Where can you create a Liquidity Pool?

How to create a Liquidity Pool in Uniswap with your ERC20 Tokens?

1. Connect to Uniswap and go to the ‘Pool’ section
2. Import the chosen ERC20 Tokens into the Pool
3. Setting the Fees
4. Setting the Price
5. Setting the Price Range
6. Depositing the Amounts
7. Verifying Smart Contract Execution
8. Managing the Liquidity Pool

Creating Liquidity Pools and Managing them Programmatically

How Centralized Exchanges Get Liquidity?

Many of us have dealt with the complexities of exchanges since a young age, starting in the lunch room. A peer-to-peer exchange is like finding a friend willing to trade your lunch with theirs, this usually happens if you bring a commonly desired lunch item (for most North American school kids) like pudding or an apple. In this scenario, you are liquid.

New to trading? Try crypto trading bots or copy trading on best crypto exchanges

But what if your mom or dad packed you something a little more ethnic, like a spicy samosa? As delicious as samosas are, finding a friend in a North American school willing to trade with you will be much more difficult. In this scenario, you face a risk of being illiquid.

Exchanges usually require both parties to agree on a buy/sell price, and we usually need these parties to agree fairly quickly. But what if both parties don’t agree on a buy/sell price, or if someone wants to trade their asset for another asset that isn’t available? Now our exchange is illiquid or exposes itself to liquidity risks, and people may be unable to offload their assets.

Exchanges limit their exposure to liquidity risks by turning to their rich friends (market makers) that have enough goods (liquidity) to make the deal happen.

PFOF (Payment for Order Flow) is a rebate market makers send to brokerage firms to incentivize brokers to direct orders towards them. The reason they want to fulfill the orders is because the market makers make their revenue off the spread of the bid and ask price.

Fun Fact: PFOF was pioneered by the one and only… Bernie Madoff. He was known for his work around PFOF before he was known for his Ponzi scheme.

How Decentralized Exchanges Get Liquidity?

In a decentralized exchange, the order is fulfilled by a liquid provider, a group of people who pool their funds to provide liquidity for a pair of assets. These liquidity providers enter a smart contract when they create their liquidity pool. They agree to supply their assets to the DEX for a trading fee.

As the demand for the tokens increases, the DEX utilizes an algorithm that adjusts the price. This concept is called an Automated Market Market (AMM) because an algorithm does the market-making and figures out the price. For the most part, the AMM algorithm utilized is called constant product, but this isn’t the case for all liquidity pool protocols.

Where can you create a Liquidity Pool?

Some of the most popular liquidity pool platforms in the DEX space are Uniswap, Sushiswap, Curve, and Balancer, these platforms are consistently in the top 10 because of their TVL (Total Value Locked), volume traded, and support for a wide range of crypto assets. Today we will dive into Uniswap.

Below are the rankings of the top 10 platforms taken from Messari.

Top 10 TVL (Total Value Locked)

Top 10 Volume Traded

How to create a Liquidity Pool in Uniswap with your ERC20 Tokens?

Below is a video to see the whole process of creating a liquidity pool on Uniswap. We’ll walk through each step in detail in this blog.

Prerequisites

Before we get started, you should have a solid understanding of the following:

• Setting up your wallet with testnet tokens

Setting Up Wallet for Testnet

• ERC20 Tokens and adding them to your wallet

How to Create and Deploy an ERC20 Token - In 20 minutes

You will need a plugin wallet with 2 Ethereum compatible tokens in a testnet network (preferably Goerli). One of them can be Ethereum, or both of them can be ERC20 tokens.

1. Connect to Uniswap and go to the Pool section

Go to the site https://uniswap.org/ and connect your web3 wallet (i.e., Exodus, Metamask, etc.) to the app. Then navigate to the Pool section of the app to create your liquidity pool.

2. Import your ERC20 Tokens into the Pool

Get the Token Contract Address

In your wallet, select a token. In this case, I selected the token APL. When you click on the 3 dots on the top, select the option “Token Details.”

In the Token Details section, you will get a ‘Token contract address”. This is the address of the token APL’s contract address, which acts as an identifier of the token. Copy this address, we will use it to import your token into Uniswap.

Import Token into Uniswap

Back in Uniswap, please select one of the tokens; it should take you to a search bar.

When you enter the token contract address, you will see the ERC20 token and its metadata. You can either import a pair of ERC20 tokens or just one ERC20 token and pair it against Ethereum. In this case, we’ll pair apples (APL) against grapes (GRP).

3. Setting the Fees

After the tokens are added and paired with each other, the next step is to set a fee for the liquidity pool.

This is the fee the liquidity provider (you, in this case) will receive every time a trade is made against your pool.

• 0.05% is often used for token pairs that correlate closely in prices like USDC and DAI, which are closely tied to $1.
• 0.3% is typically used for most pairs and has been the default in the previous versions.
• 1% is used for low-liquidity assets like meme coins.

We choose the 0.3% fee to earn 0.3% of fees for every trade of apples or grapes from our liquidity pool.

4. Setting the Price

Here the price of an apple is four grapes, so in the section that says “Set Starting Price,” we set the current price of an APL (apple) to 4 GRPs (grapes).

5. Setting the Price Range

We need to set the price range; figuring out the range is based on how the market’s demand will change your asset price over time. The price range can’t be too narrow, and it can’t be too wide.

What if the price range is too narrow?

You won’t be paid the trade fee if your asset is priced outside the range. So if the price range is too narrow, the chances of earning fees decrease.

If you have a stablecoin and can guarantee that the price will always be within a dollar with a 5% margin going above and below a dollar, then you can have a narrow range.

What if the price range is too wide?

If your price range is too wide, you introduce market inefficiencies and high slippage (the difference between the expected and actual prices) to the traders. A wide range can increase your chance of earning fees, but the fees you earn will be less than if you had a narrow range. This is because the trading fees collected at a given price range are split pro-rata by LPs (Liquidity Providers) proportional to the amount of liquidity they contributed to that range.

Uniswap v3 addressed the risk of going out of range with narrow price ranges and market inefficiencies with wide price ranges by implementing concentrated liquidity. You can create multiple ranges that are narrow enough; check out the concept of Concentrated Liquidity,

Introducing Uniswap V3

We didn’t put too much analysis into figuring out the price range here and randomly selected a price range between ~2 and ~20.

6. Depositing the Amounts

Now for the last step, we’re going to approve both the Apple and Grape tokens and deposit the tokens into the liquidity smart contract.

When we confirm the transaction using our wallet, we add tokens to the liquidity smart contract.

7. Verifying Contract Execution

After the contract is deployed, you can verify the transaction details on Etherscan (a popular Ethereum blockchain explorer) using the transaction id provided by Uniswap (or link).

The “View on Etherscan” link will take you directly to your transaction.

If you can find your transaction details on Etherscan and the status says “Success,” you know the transaction happened and is committed to the Ethereum network. Below you can see that 2 APL (apple tokens), and 4.22 GRP (grape tokens) were transferred to a smart contract.

How do I know the address my tokens were transferred to is not just someone’s wallet but an actual contract?

In the field called “Interacted With (To):” you can see the term “Contract” and an address of the contract, in this case the address in this picture is 0xc36442b4a4522e871399cd717abdd847ab11fe88. When you search this contract on Etherscan Goerli (or any blockchain explorer for the Goerli chain) you can go to the contract tab and view the contract code that was deployed on the chain. This is an assurance that your funds are locked into the smart contract and will only behave the way the contract intended to.

8. Managing Liquidity Pool

Once your liquidity pool is created, you can manage it on Uniswap. You can either remove or increase liquidity and collect fees earned from trades. You can also monitor where your price currently sits within the set price range.

Creating Liquidity Pools and Managing them Programmatically

If you’re a financial service firm that needs to create liquidity pools for multiple clients at a time with different criteria, using the interface may not be most efficient. So you would approach it programmatically, by either:

1. Creating a project by copying Uniswap’s set of smart contracts and deploy it using your own app

This approach will be difficult to maintain and is only advisable if the plan is to differ from the Uniswap protocol.

GitHub - Uniswap/v3-core: 🦄 🦄 🦄 Core smart contracts of Uniswap v3

2. Use Uniswap’s SDK

The easiest approach to get started with. The limitation is that the SDK is only available in Typescript and if you want to switch protocols then you would have to re-write your entire codebase.

Overview | Uniswap

3. Inheriting Uniswap’s smart contract (Recommended)

This is the most recommended approach because you’re calling the continuously audited Uniswap protocol but also doing it within your smart contract and not your full stack.

Set Up Your Contract | Uniswap

Deep End of Liquidity Pool in the DEX Space? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.