Introduction to Payment Channels
  • Alice has funded the channel
    • Alice signs a funding transaction which spends to a 2-of-2 multisig output.
    • Once the funding transaction is broadcast, the payment channel is open.

  • Both parties sign the commitment TX.
    • Requires signatures of both parties.
    • Commitment captures channel balance.
    • Is updated with each new channel payment.
    • Is not broadcasted until channel closure.
Payment Channel: Naive Implementation
  • Funding TX and Commitment TX 1
    • Funding TX signed by A
    • Commitment TX 1 signed by both parties

  • Valid Channel Close
    • Latest commitment TX is broadcast by either party

  • Problem: Invalid Channel Close
    • Nothing prevents either party from broadcasting old state

Revocable Sequence Maturity Contract
  • Spendable after time-out
    • RSMC A is spendable by A after a delay

  • Spendable by secret R
    • Each party generates secret:
      r1 & r2
    • Parties exchanges pubkeys:
      R1 & R2
    • Public key R is derived indendently:
      R = R1+R2 = r1•G + r2•G = (r1+r2)G
    • Public key R is spendable with:
      r = r1 + r2

  • A party can revoke its RSMC output:
    • By sharing its secret with counterparty.

Payment Channel with RSMC's
  • Old states are revoked
    • RSMC can be spent by counterparty

  • Old broadcast states are swept
    • Penalty TX by counterparty broadcast

  • Chain needs to be watched
    • Both parties must monitor chain for invalid commitment transactions

  • Watchtower
    • Channel participant outsources the monitoring of commitment transactions

Introduction to Payment Channel Routing
  • 1) Alice wants to send a payment to Dave.
    • Dave creates a unique payment_preimage.
    • Dave sends HASH160(payment_preimage)
      to Alice.

  • 2) Alice constructs a route to Dave.
    • Onion routes HASH160(payment_preimage) along route.

  • 3) Channels update commitment with htlc.
    • Hash time locked contract represents
      a "pending" amount.

  • 4) Dave unlocks htlc with payment_preimage.
    • Preimage is propgated backwards
      through payment route.
    • htlc's are settled and commitment tx is updated.

Closing a channel with HTLC outputs
  • Bob closes channel with sent HTLC's
    • A) HTLC spendable by timeout transaction
      after htlc timeout.
      • HTLC & RSMC B revocable with secret r
    • B) HTLC immediately spendable by Charlie with payment_preimage

  • Charlie closes channel with received HTLC's
    • A) HTLC spendable with success transaction
      with payment_preimage.
      • HTLC & RSMC C revocable with secret r
    • B) HTLC spendable by Bob after HTLC timeout.

  • Timeout & Success Transactions:
    • Two-stage design.
    • Enables both HTLC timeout and RSMC delay.
Closer look: HTLC scripts
  • HTLC(SENT) output spendable by:
    • After HTLC timeout: Timeout TX
    • Payment preimage & HTLC receiver’s signature
    • Revocation signature & public key

  • HTLC(RECV) output spendable by:
    • Payment preimage & success TX
    • After HTLC timeout: HTLC sender’s signature
    • Revocation signature & public key