On-Chain Payments
Bitcoin on-chain transactions use an unspent transaction output (UTXO) model. A payment creates a new UTXO locked to the recipient's address using a scriptPubKey. The sender proves ownership by providing a scriptSig (or witness for SegWit) that satisfies the locking conditions.
1. Invoice created
Merchant generates a BIP-21 payment URI or address. Optional: amount and label included.
2. Payer broadcasts
Wallet signs and broadcasts a transaction to the mempool. Fee (sat/vB) is chosen by the sender.
3. Mempool → miner
Miners select transactions by fee rate. Higher sat/vB = faster inclusion.
4. First confirmation
Transaction included in a block (~10 min avg). Merchants typically wait 1–6 confirmations for finality.
5. Settlement
6 confirmations (~60 min) is considered irreversible for large amounts. Small amounts often accept 1.
BIP-21 Payment URI
Encodes a payment request as a URI that wallets can scan or click.
Format
bitcoin:<address>[?amount=<BTC>][&label=<name>][&message=<msg>]Example
bitcoin:bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
?amount=0.00250000
&label=Acme+Coffee
&message=Order+%23A42Transaction types
| Type | Script | Avg size | Fee efficiency |
|---|
| P2PKH (legacy) | OP_DUP OP_HASH160 … | ~250 vB | Lowest |
| P2SH | OP_HASH160 … OP_EQUAL | ~297 vB | Low |
| P2WPKH (SegWit) | OP_0 <20-byte hash> | ~141 vB | Good |
| P2TR (Taproot) | OP_1 <32-byte key> | ~111 vB | Best |
Lightning Network
Lightning is a Layer-2 protocol built on Bitcoin that enables instant, near-zero-fee payments by routing them through a network of pre-funded payment channels. Funds only settle on-chain when channels open or close.
1. Channel open
Two parties lock Bitcoin into a 2-of-2 multisig on-chain funding transaction.
2. Invoice generated
Payee creates a BOLT11 invoice with payment hash. Sent to payer via QR or link.
3. Route found
Payer's node finds a path through the channel graph using source-routing (onion encryption).
4. HTLC propagated
Hash Time-Locked Contracts lock funds at each hop. No hop can steal funds without revealing the preimage.
5. Preimage revealed
Payee reveals preimage to claim funds. Each hop unwinds atomically. Payment settles in <1 second.
6. Channel close (optional)
Parties cooperatively or unilaterally close the channel, settling net balance on-chain.
BOLT11 Invoice format
Lightning invoices are bech32-encoded strings containing payment hash, amount, expiry, and routing hints.
Example (10 000 sats)
lnbc100u1p3xnhl2pp5......| Prefix | Meaning |
|---|
lnbc | Lightning Network, Bitcoin mainnet |
lntb | Bitcoin testnet |
lnbcrt | Regtest (local dev) |
100u | Amount: 100 micro-BTC = 10 000 sats |
BOLT specs
BOLT 1Base Layer
Inter-node communication, feature flags, message types (init, error, ping/pong)
BOLT 2Peer Protocol (Channels)
Channel lifecycle: open, update, close. Commitment transactions and revocation keys.
BOLT 3Bitcoin Transaction & Script
Funding transaction format, HTLCs, penalty transactions, SegWit requirements.
BOLT 4Onion Routing
Sphinx onion packet format. Each hop decrypts one layer; payment path is private.
BOLT 7P2P Node & Channel Discovery
Gossip protocol for advertising channels and routing policies (fees, CLTV delta).
BOLT 9Assigned Feature Flags
Registry of feature bits (OPTION_STATIC_REMOTEKEY, AMP, MPP, etc.).
BOLT 11Invoice Protocol
BOLT11 invoice format — bech32-encoded payment requests with amount, hash, and routing hints.
BOLT 12Offers (BOLT12)
Reusable offer codes; payee provides a static offer; payer fetches an invoice on demand. Replaces static BOLT11 invoices.
Key Lightning concepts: HTLCs (Hash Time-Locked Contracts) allow trustless routing — each hop reveals a preimage to claim the payment only if the next hop succeeds. LSPs (Lightning Service Providers) like Voltage, Breez, or LSPS spec provide liquidity and channel management as a service.