Basis of Lightning Technology

## Overview This protocol assumes an underlying authenticated and ordered transport mechanism that takes care of framing individual messages. [BOLT #8](08-transport.md) specifies the canonical transport layer used in Lightning, though it can be replaced by any transport that fulfills the above guarantees. The default TCP port depends on the network used. The most common networks are: - Bitcoin

No reviews yet.

The peer channel protocol has three phases: establishment, normal operation, and closing.

No reviews yet.

This details the exact format of on-chain transactions, which both sides need to agree on to ensure signatures are valid. This consists of the funding transaction output script, the commitment transactions, and the HTLC transactions.

No reviews yet.

## Overview This document describes the construction of an onion routed packet that is used to route a payment from an _origin node_ to a _final node_. The packet is routed through a number of intermediate nodes, called _hops_. The routing schema is based on the [Sphinx][sphinx] construction and is extended with a per-hop payload. Intermediate nodes forwarding the message can verify the integri

No reviews yet.

## Abstract Lightning allows for two parties (a local node and a remote node) to conduct transactions off-chain by giving each of the parties a *cross-signed commitment transaction*, which describes the current state of the channel (basically, the current balance). This *commitment transaction* is updated every time a new payment is made and is spendable at all times. There are three ways a chan

No reviews yet.

This specification describes simple node discovery, channel discovery, and channel update mechanisms that do not rely on a third-party to disseminate the information. Node and channel discovery serve two different purposes: - Node discovery allows nodes to broadcast their ID, host, and port, so that other nodes can open connections and establish payment channels with them. - Channel discovery

No reviews yet.

All communications between Lightning nodes is encrypted in order to provide confidentiality for all transcripts between nodes and is authenticated in order to avoid malicious interference. Each node has a known long-term identifier that is a public key on Bitcoin's `secp256k1` curve. This long-term public key is used within the protocol to establish an encrypted and authenticated connection with p

No reviews yet.

This document tracks the assignment of `features` flags in the `init` message ([BOLT #1](01-messaging.md)), as well as `features` fields in the `channel_announcement` and `node_announcement` messages ([BOLT

No reviews yet.

## Overview This specification describes a node discovery mechanism based on the Domain Name System (DNS). Its purpose is twofold: - Bootstrap: providing the initial node discovery for nodes that have no known contacts in the network - Assisted Node Location: supporting nodes in discovery of the current network address of previously known peers A domain name server implementing this specifica

No reviews yet.

A simple, extendable, QR-code-ready protocol for requesting payments over Lightning.

No reviews yet.

# Table of Contents * [Limitations of BOLT 11](#limitations-of-bolt-11) * [Payment Flow Scenarios](#payment-flow-scenarios) * [Encoding](#encoding) * [Signature calculation](#signature-calculation) * [Offers](#offers) * [Invoice Requests](#invoice-requests) * [Invoices](#invoices) * [Invoice Errors](#invoice-errors)

No reviews yet.

Welcome, friend! These Basis of Lightning Technology (BOLT) documents describe a layer-2 protocol for off-chain bitcoin transfer by mutual cooperation, relying on on-chain transactions for enforcement if necessary. Some requirements are subtle; we have tried to highlight motivations and reasoning behind the results you see here. I'm sure we've fallen short; if you find any part confusing or wrong

No reviews yet.