Trending
The most active specs across all ecosystems.
Most reviewed
BIP 110: Reduced Data Temporary Softfork
Mailing list thread at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8 --- Editor note: please post conceptual feedback and meta-commentary on the mailing list [thread](https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8), and focus here on: - expert technical review of the specification - specific, concrete, helpful proposals for the other sections Please refrain from personal or heated commentary, trolling, pedantry, and repeating yourself. As this PR now has many comments, please on
Bip draft: Bitcoin Encrypted Backup
This is a bip for encrypted backup, an encryption scheme for bitcoin wallet related metadata. Mailing list post: https://groups.google.com/g/bitcoindev/c/5NgJbpVDgEc
BIP393: Output Script Descriptor Annotations
This BIP proposal follows from the discussion for BIP392 (#2047) in which it emerged that due to the resource-intensive scanning requirements of the protocol some metadata (for example the birthday block height) may be practically required for efficient recovery of wallet funds. However, this metadata is not technically required to determine the output scripts, and therefore deemed unsuitable for direct inclusion in an output descriptor. This may lead to a situation in future where a wallet back
BIP 1: BIP Purpose and Guidelines
BIP: 1 Title: BIP Purpose and Guidelines Authors: Amir Taaki <genjix@riseup.net>
No reviewsBIP 2: BIP process, revised
BIP: 2 Title: BIP process, revised Authors: Luke Dashjr <luke+bip@dashjr.org>
No reviewsBIP 3: <BIP title (≤ 50 characters)>
This _Bitcoin Improvement Proposal (BIP)_ provides information about the preparation of BIPs and policies relating to the publication of BIPs. It replaces [BIP 2](bip-0002.mediawiki) with a streamlined process, and may be amended to address the evolving needs of the BIP process.
No reviewsBIP 8: Version bits with lock-in by height
BIP: 8 Title: Version bits with lock-in by height Authors: Shaolin Fry <shaolinfry@protonmail.ch>
No reviewsBIP 9: Version bits with timeout and delay
BIP: 9 Title: Version bits with timeout and delay Authors: Pieter Wuille <pieter.wuille@gmail.com>
No reviewsBIP 10: Multi-Sig Transaction Distribution
BIP: 10 Layer: Applications Title: Multi-Sig Transaction Distribution
No reviewsBIP 11: M-of-N Standard Transactions
BIP: 11 Layer: Applications Title: M-of-N Standard Transactions
No reviewsRecently updated
BOLT 12: Negotiation Protocol for Lightning Payments
# 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 reviewsBOLT 11: Invoice Protocol for Lightning Payments
A simple, extendable, QR-code-ready protocol for requesting payments over Lightning.
No reviewsBOLT 10: DNS Bootstrap and Assisted Node Location
## 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 reviewsBOLT 9: Assigned Feature Flags
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 reviewsBOLT 8: Encrypted and Authenticated Transport
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 reviewsBOLT 7: P2P Node and Channel Discovery
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 reviewsBOLT 5: Recommendations for On-chain Transaction Handling
## 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 reviewsBOLT 4: Onion Routing Protocol
## 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 reviewsBOLT 3: Bitcoin Transaction and Script Formats
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 reviewsBOLT 2: Peer Protocol for Channel Management
The peer channel protocol has three phases: establishment, normal operation, and closing.
No reviews