History of Payment Channels

History of Payment Channels

Gabriel Comte

Gabriel <acento español>

Gabrielito

Gabri-chelito

Señor Maestro Chero Gabo

Don Gabrón

Non-chronological order

Ordered by topics rather than time

The problem

Bitcoin is a broadcast network

Entire ledger is replicated to all network participants

Consequences

  • Computing is expensive
  • Scaling the system is hard
  • Getting privacy is hard

Solution

Omitting (some) data from the broadcast protocol

Payment Channels

A Micropayment Channel or Payment Channel is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin blockchain.

Source: https://en.bitcoin.it/wiki/Payment_channels

Payment Channels

  • Take (some) transactions off-the-chain
  • Leave the option for on-chain enforcement

Metaphor

Satoshi's payment channels

  • Satoshi already considered payment channels
  • Deployed required primitives in first version
  • Design consequences subsist until today

Satoshi's payment channels

TX aa047b11f0...

Scenario

  1. You are at a bar
  2. You want to order multiple beers sequentially
  3. You don't have any trust relationship with the bartender
  4. The bartender wants to be paid directly for every beer
  5. You don't want to pay so many transaction fees

First beer

  • TX could be broadcasted
  • It's enough to just pass the TX to the bartender

Second beer

  • TX could be broadcasted
  • It's enough to just pass the TX to the bartender

Third beer

  • TX could be broadcasted
  • It's enough to just pass the TX to the bartender

Nth beer

Can be replaced until nLockTime

Channel close

Unilateral

  • Bartender waits until nLockTime and publishes last TX
  • If multiple TXs are published, miners will pick the TX with the highest nSequence

Channel close

Cooperatively

You create a final TX and remove nLockTime

Shortcomings

  • Unidirectional payment flow
  • Finite channel lifetime
  • Not secure!

Security issue

  • Miner cannot be held accountable
  • May disregard nSequence field

Conclusion

  • TX can be replaced by newer versions until nLockTime
  • Sender and receiver exchange entirely valid Bitcoin TXs (offline)
  • Only one of these TXs can be settled (mined into the Blockchain)
  • Update mechanism is not secure (miner collusion)

Questions?

Any questions so far?

Intermediate ideas and implementations

After Satoshi's flawed idea, a lot of innovation happened on payment channels

Using Multisig

In 2011 Bitcointalk user hashcoin proposed a scheme to fix miner collusion

Spilman reintroduced similar scheme in 2013 and provided a PoC implementation

Schemes use 2-of-2 multisig to resolve trust issues

Spilman | Channel lifecycles

With Spilman channels we can already see the emergence of the payment channel lifecycles which subsist until today:

  • Channel setup phase | on-chain
  • Payments through channel | off-chain
  • Channel closing | on-chain

Spilman | Setup phase

  1. You craft a setup TX that sends funds to a 2-of-2 MultiSig controlled by bartender and yourself
  2. You DON'T publish that TX yet
  3. You craft a TX that sends all the funds within the setup transaction back to you at nLockTime T
  4. You ask the bartender sign that closing TX for you
  5. Now that you have a security to reclaim your funds, you publish the setup TX
  6. Wait for the TX to confirm on the blockchain
  7. The channel is now setup and can be used until nLockTime T

Spilman | Payments phase

  1. You start spending crafting TXs that spend the funding TX
  2. You spend it such, that some funds go to the bartender and some go to yourself
  3. You craft one such TX for each off-chain payment
  4. You sign these TXs and pass them to the bartender
  5. He could publish these TXs at all times, but he does NOT

Spilman | Payments phase

Channel closing

  • Bartender signs and publishes the last channel state (which is most lucrative to him)
  • He must do that before the channel expires!
  • If the channel hasn't been used at all, you sign and publish the Reclaim TX

Conclusion

  1. Miner collusion is fixed
  2. Payments can still only flow into one direction
  3. Payment channel still has a limited lifetime
  4. A channel lifetime still needs to be committed to in advance
  5. Bartender needs to act before channel expires

Incentives rather than nSequence

Why is it that the newest channel state is being published?

  • Order is NOT enforced by miners through nSequence
  • Bartender publishes newest state because it is the most lucrative for him
  • You cannot sign any state because you don't have the bartenders signature
  • Premature publishing of Reclaim TX is prevented by nLockTime

Questions?

Any questions so far?

SegWit required

Spilman channels and other proposals required SegWit to fix transaction malleability

SegWit was activated in 2017

Bi-directional payment flows

  • A naive solution to allow for bi-directional payment flows is to simply create 2 channels in the opposite direction respecitively
  • Problem: You cannot send the funds you received, instead you need to close and reopen channels.
  • Money within a channel can only be transferred once

Problem

The already existing problem of the limited lifetime of a channel gets even worse!

Bi-directional channels

Alex Akselrod had the idea to let funds flow bi-directionally in channels by using decreasing nLockTimes.

Bi-directional channels

Duplex Micropayment Channels (DMC)

  • Decker and Wattenhofer published a proposal that also heavily relies on time locks
  • Paper was released in October 2017

Duplex Micropayment Channels (DMC)

Adding trust

Various proposals integrated limited forms of trust to solve various problems

Questions?

Any questions so far?

Present: Lightning Network payment channels

"The Bitcoin Lightning Network" paper released in February 2015 (updated version by Poon and Dryja)

Most important finding was routing, not new channel techniques

Poon-Dryja channels (Penalty)

Characteristics

  • Bi-directional payment flows
  • Unlimited lifetime

Channel setup

  1. The funder crafts a setup TX that sends funds to a 2-of-2 MultiSig controlled by funder and remote
  2. He only publishes the funding TX once he has a signed reclaim TX
  3. The opened channel can be used indefinitely

Channel setup

More details on Elle Mouton

LN payments

More details on Elle Mouton

The revocation key

  • Uses ECC magic (details)
  • Revocation key pair is crafted collaboratively between Alice and Bob
  • Bob only accepts a new payment state, when Alice provides him with the data he needs to be able to construct the revocation key pair
  • Bob knows the revocation key pairs, but only for old states
  • Nobody knows the revocation key pair for the current state

Penalty transaction

When Alice publishes an old channel state, Bob has 144 blocks to claim all the funds in the channel

Let's revisit the scheme

Alice needs protection too!

Bob stores channel states with the same scheme, but mirrored

Commitment TXs per peer

Recap

  1. For the curent channel state X, both Alice and Bob have a transaction for which some part could be claimed with the revocation private key
  2. But nobody knows the entire revocation private key yet
  3. Alice and Bob only sign a new channel state, if they get the information they need to derive the revocation private key from their channel partner
  4. This kind of invalidates the old state
  5. If you publish an old state, you risk losing all your funds in that channel

Channel reserves

  • For the penalty transaction incentive to work, skin in the game is required
  • If all the balance within a channel belongs to Bob, he can't effectively punish Alice
  • Bob could punish her and take all the money, but it's not a punishment because it already belongs to him
  • That's why usually you cannot spend your full Lightning balance of a channel

Output scripts

to_remote output (Bolt 3)


						<remotepubkey> OP_CHECKSIGVERIFY 1 OP_CHECKSEQUENCEVERIFY

Output scripts

to_local output (Bolt 3)


						OP_IF
							# Penalty transaction
							<revocationpubkey>
						OP_ELSE
							`to_self_delay`
							OP_CHECKSEQUENCEVERIFY
							OP_DROP
							<local_delayedpubkey>
						OP_ENDIF
						OP_CHECKSIG

Requirement to be online

  • Node has time of X blocks to release a penalty TX
  • Must watch the blockchain to see wether an old state has been published

Questions?

Any questions so far?

Optional topics in case we have time!

Repurpose of nSequence field

  • BIP 68 repurposes the nSequence field to be used for relative time locks
  • BIP 125 repurposes the nSequence field to signal that a transaction can be replaced-by-fee
  • ...

CLTV

  • OP_CHECKLOCKTIMEVERIFY enforces the spending TX of an output to set a minimum nLockTime
  • It essentially adds an absolute timelock to an output
  • Output cannot be spent before block 800.000

CSV

  • OP_CHECKSEQUENCEVERIFY enforces the spending TX of an output to set a minimum nSequence
  • It essentially adds a relative timelock to an output
  • Output cannot be spent for 100 blocks after *this* TX has confirmed

SegWit

  • Before SegWit, a TX id could be manipulated by anybody even without holding a private key
  • This is because a signature can be manipulated without changing its meaning
  • SegWit TX ids are a hash of the TX without the signature

Importance for payment channels

When we craft TXs that spend unconfirmed outputs (think Reclaim TXs), the spended output can suddenly seize to exist, because it's TX id (which is referenced as an input) changed.

Anchor channels

Problem: You need to estimate Transaction fees in advance, potentially for months!

This is particularly bad because timelocks can expire while TX is waiting for confirmations

Solution: Anchor channels

Anchor channels: Details

  • Don't try to estimate the TX fee in advance
  • Instead use a low fee, and CPFP it upon a unilateral channel close
  • Comes with its own challenges (CPFP carve-out, needs outputs to be able to CPFP)

Taproot

Channels based on taproot can use MuSig2 for the Multi-signature part and hide the script within the tweaked PubKey. (details)

Conclusion

  • Developing LN is an iterative process
  • It's still evolving
  • We're learning new things as we're building it

Resources

History

Current implementation