Bitcoin Lightning Network

The Bitcoin Lightning Network is a peer-to-peer payment network that leverages payment channels anchored on the Bitcoin blockchain to enable near instant settlement of Bitcoin between participants at a low cost. Multiple such payment channels are chained together to deliver payments to anyone in the network without requiring trust in participants.

Invoices

The Lightning Network uses invoices instead of addresses. Invoices are generated by the recipient. Each invoice includes a specified amount, time of expiration, the destination public key, as well as any other data required. Invoices can be canceled by the recipient at any time before the invoice is filled.

Lighting invoices us the BOLT(Basis of Lightning Technology) 11 QR-code-ready protocol. BOLT specifications are required to enable separate implementations to function and interact with each other within the same network. These specifications allow any client or tool to be able to understand any Lightning invoice created, regardless of the creator.

Each Lightning invoice includes an amount, expiration time, destination public key, supported features and other data as needed.

More information on Lightning Invoice specifications.

Payments(HTLC)

All payments utilize Hash Time-lock Contracts(HTLC), an output of an unconfirmed transaction to a “smart contract”. HTLCs can be settled by revealing a preimage as defined by it's hash.

All payments along the HTLC route are made to this hash, and can be claimed only when the preimage is revealed. If the preimage is not revealed, the payment is sent back to the sender. Although HTLCs can be settled on blockchain, they are generally resolved off-chain between peers.

When an Lightning transaction is initiated the receiver must first send a random number that has been hashed to the sender. For example, If Alice wants to create a contract with Dave to send funds, Dave must generate a random number R, and hash it thus creating number H. Then Dave sends H. Alice then creates a conditional payment to Bob(a node she is connected to) that is completed if he can produce the preImage of H if he does within a 3 days(in this example). If that time period passes only Alice would be able to redeem the payment. This ensures Alice can redeem the funds if Bob never finds out what R is. However, this transaction is not broadcasted on chain because they expect it to clear out.

In order to create a payment to Dave, Bob routes a transaction through Carol, who is associated with Dave. In this transaction Dave agrees to pay Carol if she can produce the preimage of H.

Once this happens Carol can send R to Bob who in turn sends it to Alice, settling all transactions. If any member of the chain is uncooperative, the transaction between the uncooperative person would be broadcasted on chain and R could then be recovered by looking at the on-chain transaction. This allows the rest of the payment channel to settle off-chain.

Last updated