Introduction

to the Lightning Network

Mainz

Feb 05th 2019

Introduction

to the Lightning Network

Gjøvik

Jan 09th 2019

I've been told I should start any talk with something everybody in the audience should know

​

​

​

​

​

​

​

​

A standard Bitcoin Transaction has 6 data fields

( The following is a brief summary of https://en.bitcoin.it/wiki/Transaction#Input )

​

• Version number (4 Bytes)
• In-Counter (1-9 Bytes)
• List of inputs (depending on the Value of <In-Counter>)
• Out-Counter (1-9 Bytes)
• List of Outputs (depending on the Value of <Out-Counter>)
• Lock_time (4 Bytes)

(

Bitcoin Transaction with 3 inputs and 2 outputs

Data consists mainly of executable scripts!

A chain of Bitcoin Transactions with 2 UTXO

• Outputs are references by the inputs
• The Script in the output defines how the transaction can be spent
• Owning Bitcoins means being able to spend the output of an unspent transaction
• Provide an input script
• Concatenate it with with some outputscript of an unspent transaction
• The combined Script needs to evaluate to True

Spending a Pay-to-PubkeyHash (standard TX)

• ScriptPubKey (aka the Output Script)
• OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
• ScriptSig: (aka the Input Script)
• <sig> <pubKey>
• Explainations
• OP_CODES are the instructions of the script language within Bitcoin
• <data> is depicted like html tags with lesser than and greater than signs
• The complete script is concatenated as Input || Output and then being executed on a Stack machine

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

Data is pushed on the stack

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

<pubKey>

Data is pushed on the stack again

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

<pubKey>

<pubKey>

The OP_CODE OP_DUP is being executed by pushing the top element to the stack again

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

<pubKey>

The OP_CODE OP_HASH160 is being executed:

​

It takes the top element of the Stack

<pubKey>

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

<pubKey>

<pubKeyHash>

The OP_CODE OP_HASH160 is being executed:

​

It takes the top element of the Stack

The RIPEMD-160 Hash is calculated

​

By design of the input and output script this will be the Hash of the Public Key (aka the Bitcoin Address)

<pubKey>

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

<pubKey>

<pubKeyHash>

The OP_CODE OP_HASH160 is being executed:

​

It takes the top element of the Stack

The RIPEMD-160 Hash is calculated

And the result is pushed back on the stack

​

By design of the input and output script this will be the Hash of the Public Key (aka the Bitcoin Address)

<pubKey>

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

<pubKey>

<pubKeyHash>

<pubKeyHash>

Data is pushed on the stack again

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<sig>

<pubKey>

OP_EQUALVERIFY checks if the two top elements of the stack are equal.

​

While checking the elements will be removed

​

Like the instruction set in the ALU of the CPU OP_CODES know how much data they need to consume (and will do so or fail otherwise)

<pubKeyHash>

<pubKeyHash>

Execution of Pay-to-PubkeyHash Script

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

​

​

​

<True>

OP_CHECKSIG evaluates that the PubKey which was the top element fits to the signature which was the 2. Element on the stack

​

If this fits together ownership is proven and the Transaction will be added to the block with a new Output script.

​

After being mined the transaction is now considered to be spent. Double spending cannot take place since the assumption was that the output was not spent yet.

<sig>

<pubKey>

Broadcast / Publish that Transaction for the network to verify it

The Bitcoin miners will build the next block

• Collect published and valid transactions
• In particular the hashes of the transactions
• Most likely those that offer highest mining fees
• Mining fees are leftovers of inputs which have not assigned to outputs
• As many as there is space within the block
• Start with one special transaction which has no input generating the block reward as an output
• Take some additional meta data
• The hash of the previous block
• The nonce (and extra nonce as part of the coinbase)
• Compute the merkle tree of all the hashes
• Look out for a hash collision with respect to the mining difficulty
• If your Tx was in: Congratulations you now sent bitcoins

Bitcoin Transaction with 3 inputs and 2 outputs

Be Brave!

​

​

Now is the moment to ask questions

Let's talk lightning!

I love taking photographs of lightning bolts...

Two main components lead to the Lightning Network

• Bidirectional payment channel
• 3 known methods to construct those
• Poon Dryja Channels (Penalty Revocation based system)
• Eltoo (SIGHASH_NOINPUT requires Bitcoin softfork)
• Decker Wattenhofer (invalidation trees)
• Revocable Sequence Maturity Contracts (RSMC)
• OP_CHECKSEQUENCEVERIFY aka OP_RELATIVECHECKLOCKTIMEVERIFY
• Thanks (!) to BIP 112 https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

​

• Routing payments through a network of payment channels
• Hashed time locked contracts (HTLC)
• Preimages of Hash as Secrets to trigger payments

Purpose of a trustless bidirectional payment channel

• Sending payments between two partners
• Instantly
• Like updating a balance sheet
• Only bound by network traffic over the internet
• No direct involvement of the blockchain (as long as everyone plays by the rules)
• No need for any partner to trust the other side
• Again The Blockchain CAN be involved if problems arise
• No fees or overhead when sending payments within the channel
• Payments can go in either direction back and forth

→ How can this technically be possible?

A comparison with HTTP

• HTTP is a Request Response Protocol by design
• You (the client / Browser) can make a request
• The server gives you a response
• According to the protocol a server cannot initiate communication with a client

​

• How can a website (e.g. Twitter) give us a notification that some new data is there?
• By abusing the protocol
• aka: Server push, long polling,
• Took us about 10 years to figure that out

How does a HTTP server push work?

• You load a web page
• Javascript (AJAX) initiates an HTTP request
• Server looks if he has some information for the client
• If yes → response
• If no → defer answering to that request to some time in the future
• If new information for the client is available
• If client opens a new page and can't receive that response anymore
• Just as a heartbeat mechanism to ask the client to make a new request
• From an end user perspective the server has initiated a conversation
• The end user is usually not aware of the fact that an AJAX Request is outstanding

More details at: https://en.wikipedia.org/wiki/Push_technology

Payment channels are constructed by deferring the publication or broadcast of some TXs to the future

• Bitcoin is not a request response protocol
• Rather a broadcast / gossip protocol
• What exactly is being deferred to the future?
• Transactions spending outputs are held back from being broadcasted
• Later Transactions are purposely tried to be double spent
• Obviously only one of the transactions can be actually spent
• Lightning is about making sure it is the correct one
• We look at this in the next couple slides
• Payment channels are to Bitcoin what HTTP Server Push is to HTTP
• Just a non obvious use of the Bitcoin protocol
• It took us a little while to figure this feature of Bitcoin out (as for HTTP)

A payment channel is a 2-2 multisig Address together with some (smart?) contract

• A 2-2 multisig Address means that the output script of a transaction requires 2 keys in order to be able to spend the transaction
• It is a form of Pay to Script Hash
• scriptPubKey (OUTPUT): OP_HASH160 <scriptHash> OP_EQUAL
• scriptSig (INPUT): ...<signatures>... <serialized script>
• Case of a m-of-n multi-signature
• The OUTPUT script (scriptPubKey) as above
• OP_HASH160 <scriptHash> OP_EQUAL
• The INPUT Script to spend the scriptPubKey looks like this:
• scriptSig: 0 <sig1>...<serialized script>
• Script: OP_m <pubKey1> … OP_n OP_CHECKMULTISIG

Funding Transaction

​

​

Funding Transaction

​

​

Input (100 mBTC)

Output 0

(100 mBTC)

Alice's & Bob's Key

Output x

(100 mBTC)

Alice's Key

Reference

ScriptPubKey:

OP_HASH160 <scriptHash> OP_EQUALVERIVY

Inside

U

N

P

U

B

L

I

S

H

E

D

Legend for colors:

​

Broadcasted and mined

​

Not boradcasted

​

Cannot by minded / should not be broadcasted

​

Should be broadcasted

Funding Transaction

​

​

Funding Transaction

​

​

Input (100 mBTC)

Output 0

(100 mBTC)

Alice's & Bob's Key

Commitment Transaction 1

​

​

Input (100 mBTC)

Reference

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

Bob's Key

Output x

(100 mBTC)

Alice's Key

Reference

ScriptPubKey:

OP_HASH160 <scriptHash> OP_EQUALVERIVY

sigScript:

<sig1>... <serializedScript>

Script:

OP_2 <Alice><Bob> OP_2 OP_CHECKMULTISIG

Inside

Inside

U

N

P

U

B

L

I

S

H

E

D

U

N

P

U

B

L

I

S

H

E

D

Funding Transaction

​

​

Funding Transaction

​

​

Input (100 mBTC)

Output 0

(100 mBTC)

Alice's & Bob's Key

Commitment Transaction 1

​

​

Input (100 mBTC)

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

Bob's Key

Output x

(100 mBTC)

Alice's Key

Reference

ScriptPubKey:

OP_HASH160 <scriptHash> OP_EQUALVERIVY

sigScript:

<sig1>... <serializedScript>

Script:

OP_2 <Alice><Bob> OP_2 OP_CHECKMULTISIG

Inside

Inside

This Commitment Transaction (CTX1) encodes the balance sheet of the channel.

It is called commitment because both sides have already been committed to it.

​

They can be broadcasted to the blockchain at any time

​

Reference

P

U

B

L

I

S

H

E

D

With CTX2 Bob upates the channel Balance

Funding Transaction

​

​

Input (100 mBTC)

Output 0

(100 mBTC)

Alice's & Bob's Key

Commitment Transaction 1

​

​

Input (100 mBTC)

Reference

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

Bob's Key

Commitment Transaction 2

​

​

Input (100 mBTC)

Reference

Output 0

(80 mBTC)

Alice's Key

Output 1

(20 mBTC)

Bob's Key

potential

double �spending?

Bob effectively sends 10 mBTC

to Alice

Anybody seeing a problem with this?

Funding Transaction

​

​

Input (100 mBTC)

Output 0

(100 mBTC)

Alice's & Bob's Key

Commitment Transaction 1

​

​

Input (100 mBTC)

Reference

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

Bob's Key

Commitment Transaction 2

​

​

Input (100 mBTC)

Reference

Output 0

(80 mBTC)

Alice's Key

Output 1

(20 mBTC)

Bob's Key

potential

double �spending?

Bob broadcasts CTX1 which is successfully mined

Bob just effectively stole 10 mBTC from Alice

Funding Transaction

​

​

Input (100 mBTC)

Output 0

(100 mBTC)

Alice's & Bob's Key

Commitment Transaction 1

​

​

Input (100 mBTC)

Reference

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

Bob's Key

Commitment Transaction 2

​

​

Input (100 mBTC)

Reference

Output 0

(80 mBTC)

Alice's Key

Output 1

(20 mBTC)

Bob's Key

Goal: Make old CTXs somehow unpublishable

• Modify the output of the CTX
• Fraudulent publishing will punish the publisher
• For example by giving the silent party the opportunity to claim all outputs of the CTX

Funding Transaction

​

​

Input (100 mBTC)

Output 0

(100 mBTC)

Alice's & Bob's Key

Commitment Transaction 1

​

​

Input (100 mBTC)

Reference

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

Bob's Key

Commitment Transaction 2

​

​

Input (100 mBTC)

Reference

Output 0

(80 mBTC)

Alice's Key

Output 1

(20 mBTC)

Bob's Key

We modify the output scripts of CTXs that it can be spent by either one of the two Transactions

Commitment Transaction 1b (Bob)

​

​

Input (100 mBTC)

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

RSMC

Reference

ScriptPubKey: (Output0)

OP_HASH160 <Alice's key> OP_EQUALVERIFY OP_CHECKSIG

​

Script: (Input Script to be able to spend Output1)

OP_IF

144 OP_CECKSEQUENCEVERIFY

OP_ DUP OP_HASH160 <Bob's key> OP_EQUALVERIFY OP_CHECKSIG

OP_ELSE

2 <Alice R_1><Bob R_1> 2 OP_CHECKMULTISIGVERIFY

OP_ENDIF

Revocable Delivery 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's Key

Relative Time Lock (144)

Breach Remedy Tx 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's & Alice's

Revocation Key #1

potential

double �spending?

Within 144 Blocks after CTX1b is mined only Alice can spend Output1 (if she has Bob's Revocation Key)

Commitment Transaction 1b (Bob)

​

​

Input (100 mBTC)

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

RSMC

Reference

ScriptPubKey: (Output0)

OP_HASH160 <Alice's key> OP_EQUALVERIFY OP_CHECKSIG

​

Script: (Input Script to be able to spend Output1)

OP_IF

144 OP_CECKSEQUENCEVERIFY

OP_HASH160 <Bob's key> OP_EQUALVERIFY OP_CHECKSIG

OP_ELSE

2 <Alice R_1><Bob R_1> 2 OP_CHECKMULTISIGVERIFY

OP_ENDIF

Revocable Delivery 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's Key

Relative Time Lock (144)

Breach Remedy Tx 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's & Alice's

Revocation Key #1

After 144 Blocks Bob can redeem his 10 mBTC & Alice can't spent BRTX1b without Bob's Key

Commitment Transaction 1b (Bob)

​

​

Input (100 mBTC)

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

RSMC

Reference

ScriptPubKey: (Output0)

OP_HASH160 <Alice's key> OP_EQUALVERIFY OP_CHECKSIG

​

Script: (Input Script to be able to spend Output1)

OP_IF

144 OP_CECKSEQUENCEVERIFY

OP_HASH160 <Bob's key> OP_EQUALVERIFY OP_CHECKSIG

OP_ELSE

2 <Alice R_1><Bob R_1> 2 OP_CHECKMULTISIGVERIFY

OP_ENDIF

Revocable Delivery 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's Key

Relative Time Lock (144)

Breach Remedy Tx 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's & Alice's

Revocation Key #1

A new Commitment Transaction is only signed if the other party reveals their previous revocation Key

Commitment Transaction 1b (Bob)

​

​

Input (100 mBTC)

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

RSMC

Reference

Revocable Delivery 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's Key

Relative Time Lock (144)

Breach Remedy Tx 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's & Alice's

Revocation Key #1

Commitment Transaction 2b (Bob)

​

​

Input (100 mBTC)

Output 0

(80 mBTC)

Alice's Key

Output 1

(20 mBTC)

RSMC

Revocable Delivery 2b (Bob)

​

​

Input (20 mBTC)

Output 0 (20 mBTC)

Bob's Key

Relative Time Lock (144)

Breach Remedy Tx 2b (Bob)

​

​

Input (20 mBTC)

Output 0 (20 mBTC)

Bob's & Alice's

Revocation Key #2

Assume CTX1b is published an mined. Alice should immediately publish BRTX1b to punish Bob's breach

Commitment Transaction 1b (Bob)

​

​

Input (100 mBTC)

Output 0

(70 mBTC)

Alice's Key

Output 1

(30 mBTC)

RSMC

Reference

Revocable Delivery 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's Key

Relative Time Lock (144)

Breach Remedy Tx 1b (Bob)

​

​

Input (30 mBTC)

Output 0 (30 mBTC)

Bob's & Alice's

Revocation Key #1

Commitment Transaction 2b (Bob)

​

​

Input (100 mBTC)

Output 0

(80 mBTC)

Alice's Key

Output 1

(20 mBTC)

RSMC

Revocable Delivery 2b (Bob)

​

​

Input (20 mBTC)

Output 0 (20 mBTC)

Bob's Key

Relative Time Lock (144)

Breach Remedy Tx 2b (Bob)

​

​

Input (20 mBTC)

Output 0 (20 mBTC)

Bob's & Alice's

Revocation Key #2

I

M

P

O

S

S

I

B

L

E

D

O

U

B

L

E

S

P

E

N

D

I

N

G

Some remarks on presented simplifications

• In order to be able to ascribe blame both sides get their own CTXs
• Commitment Tx 1b, 2b, 3b,... (for Bob)
• Commitment Tx 1a, 2a, 3a,... (for Alice)
• Transactions for every channel update
• The Revocation Deliver TXs and the Breach Remedy TXs are adapted accordingly
• For every Update of the CTXs new Revocation Keys have to be created
• Otherwise revealing the key once would not help for future updates
• Future Breach Remedy Transactions could be spent directly
• They are created from a Hierarchical Deterministic Wallet
• The Commitment Transactions will have even more outputs to support HTLCs
• HTLC outputs will be needed for routing third party payments through one's channel
• Reading suggestion for a payment channel construction with less Overhead
• eltoo: A Simple Layer2 Protocol for Bitcoin
• Christian Decker, Rusty Russell (Blockstream)
• Olaoluwa Osuntokun (Lightning Labs)
• Summary at https://www.rene-pickhardt.de/thoughts-about-eltoo-another-protocol-for-payment-channel-management-in-the-lightning-network/

Summary of what we have achieved now

• Bidirectional payment channel is opened with one on chain transaction
• Channel can stay open for arbitrary time
• The newest Commitment Transaction encodes the balance of a channel
• Old Commitment Transactions are invalidated to prevent broadcasting them
• Achieved by sharing private keys to effectively allow the other side to spend the output
• The balance sheet can instantly be updated
• Effectively allowing each party to send funds to the other party
• Both parties need to collaborate for this to happen
• Blockchain doesn't need to get involved
• No fees for updating the balance within the payment channel

​

Where is the (Lightning) Network of payment channels?

​

A trusting (Lightning) Network of payment channels

Alice

0.35 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.65 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.35 BTC

0.5 BTC

0.15 BTC

0.3 BTC

A trusting (Lightning) Network of payment channels

​

Alice

0.35 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.65 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.35 BTC

0.5 BTC

0.15 BTC

0.3 BTC

send

0.1 BTC to Charlie

A trusting (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.75 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.25 BTC

0.5 BTC

0.25 BTC

0.3 BTC

send

0.1 BTC to Charlie

A trusting (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.75 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.25 BTC

0.5 BTC

0.25 BTC

0.3 BTC

send

0.1 BTC to Charlie

I am honest and forward the payment

A trusting (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.65 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.4 BTC

channel B-C

0.25 BTC

0.4 BTC

0.25 BTC

0.4 BTC

send

0.1 BTC to Charlie

I am honest and forward the payment

Alice needed to trust Bob to forward the payment

• Both payment channels needed to negotiate new commitment transactions for both sides
• Could we change the output of the CTXs so that routing works trustless?
• Idea (aka Hashed Time Locked Contract - HTLC):
• Add another conditional output to the Commitment Transactions
• It can only be spent by the recipient
• within a certain time frame
• if the recipient can provide the preimage of some hash
• After the timeframe the sender can reclaime the funds
• For brevity I refer to the lightning network paper to look up
• the Script for the sigScript
• the Breach Remedy Transactions that are attached to this output
• You can trust me (: It is similar to what we have seen before

A trustless (Lightning) Network of payment channels

​

Alice

0.35 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.65 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.35 BTC

0.5 BTC

0.15 BTC

0.3 BTC

send

0.1 BTC to Charlie

Some Hash H of R

A trustless (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.65 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.25 BTC

0.5 BTC

0.15 BTC

0.3 BTC

Some Hash H of R

H

0.1 BTC

I can't claim 0.1 BTC without knowing R (within some time)

If Bob doesn't provide R

I can soon claim back 0.1 BTC

A trustless (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.55 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.25 BTC

0.4 BTC

0.15 BTC

0.3 BTC

Some Hash H of R

H

0.1 BTC

I can't claim 0.1 BTC without providing R (within some time)

I pay charly if she can provide R (within some shorter time)

H

0.1 BTC

A trustless (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.65 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.3 BTC

channel B-C

0.25 BTC

0.5 BTC

0.15 BTC

0.3 BTC

Some Hash H of R

H

0.1 BTC

H

0.1 BTC

Tell Charlie R

R

A trustless (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.55 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.4 BTC

channel B-C

0.25 BTC

0.4 BTC

0.15 BTC

0.4 BTC

Some Hash H of R

H

0.1 BTC

R

I can only claim 0.1 BTC by providing R to Bob

R

A trustless (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.55 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.4 BTC

channel B-C

0.25 BTC

0.4 BTC

0.15 BTC

0.4 BTC

Some Hash H of R

H

0.1 BTC

R

Great! Now I can also claim 0.1 BTC because I know R

R

A trustless (Lightning) Network of payment channels

​

Alice

0.25 BTC

2-2 Multisignature Wallet

​

0.5 BTC

Bob

0.65 BTC

channel A-B

2-2 Multisignature Wallet

​

0.8 BTC

Carlie

0.4 BTC

channel B-C

0.25 BTC

0.4 BTC

0.25 BTC

0.4 BTC

Some Hash H of R

R

Bob must have payed Charlie otherwise he would not have known R.

I didn't need to trust him.

R

R

There are more technical details (Read the BOLTs)

• The Gossip Protocol (P2P Layer)
• Announce nodes
• Announce channels
• Announce channel Updates
• SPHINX Mix Format (Transport Layer)
• Source Based Routing
• Onion Routing of Payments
• Highly anonymized
• Key Derivation
• Revocation Keys
• Commitment Points
• BOLT11 Invoices
• Make a payment request
• Bech32 encoding

Problems with the Lightning Network (BOLT 1.0)

• What happens if a node goes offline?
• Watch Tower
• Topology of the network partially unknown (in particular channel balances)
• Routing protocols for creating routing tables and exchange local information
• Autopilot feature / Network flow theory
• Dried out channels or routes with channels that have too little capacity
• Atomic multipath routing
• Splicing
• Funds are being locked up in payment channels
• Splicing
• Funds are somewhat in a hot wallet for obvious reasons
• Not aware of people working on this
• Outputs could only go to a previously defined address from some cold wallet
• Can only be changed if both sides agree to this (semitrust)

Disclaimer: Don't take this too seriously (yet)

1. This is work in progress
• Prototype exists
• Many ideas are out in the wild

​

• Yes I am a Data Scientist but because of 1. It is not very scientific yet
• I realized while preparing the talk how many wild assumptions I used so far
• Assumptions have to be tested with experiments and simulations (yet)
• Design decisions might change drastically after experiments are conducted

A quick recap of chaincode labs

lightning residency

(Current) Autopilot in a nutshell

• A recommender system for a node

​

• Suggests channels to which the node should open channels

​

• Supposed to help users to automatically provide access to the lightning network

​

How does the LND Autopilot work?

• Barabasi Albert Model
• Aka preferential attachment
• Aka the rich get richer
• Random process
• Introducing randomization is often a surprisingly strong idea
• Don't use a uniform distribution
• Use a weighted distribution with popularity (measured by node degree) as a weight
• Result will be a graph with following properties
• Scale-free
• Similar as social network graphs (seems natural)
• Small world network (in particular small diameter)
• Likely high reachability
• Power law distribution of node degrees

Pitfalls with the lnd autopilot

• It creates highly popular hubs
• By the algorithm the hubs will have mainly inbound channels
• Could technically overwhelm nodes

​

• Number of triangles in the graph are relatively low
• Single edges (aka payment channels) become very important to ensure connectivity

​

• All created channels have the same balance
• It would make way more sense to choose a reasonable capacity for each candidate

​

Roasbeefs response (:

Why is it important to think about the autopilot early

• Even with the lightning network blockchain transactions will be precious
• We can change about 7 channels per second
• That is 630'000 per day
• If we grow the lightning network for a couple of years we
• Might detect the topology of the lightning network was not so great
• Can't change that topology quickly
• Routing success depends on network topology
• max flow min cut (in particular with upcoming AMP Routing)
• Less Routing errors → better user experience → more utility

Solution: Grow the network in a smart way to avoid future problems

​

Analogy to the Internet protocol stack

Analogy to the Internet protocol stack

Analogy to the Internet protocol stack is not perfect

• Layer 1 in the internet stack is really physical.
• Bitcoin / blockchain is already logical
• Unless you consider mining hardware
• An IP packet can easily interchange the lower level protocols.
• Lightning allows to specify a chainhash but for interconnection one needs to offer an atomic swap
• Also Lightning is Bitcoin in the sense that Bitcoin transactions are handled all the time.
• In IP it really does not matter what protocol the link layer speaks
• In particular packets can flow in both directions!
• No real transport layer in lightning yet.
• Nothing similar to being a connection oriented end to end protocol like TCP is there

​

(Not perfect) analogy to routing and routed protocols

• The IP forwarding algorithm is a routed protocol.
• Similarly: Onion routing of HTLCs is a routed protocol

​

• A routing protocol helps routers to build and maintain routing tables
• Similarly: the autopilot helps nodes to build and maintain channels
• Channels in turn determine how routing tables will be created.

​

• Historically on the Internet we had routed protocols before routing protocols
• People have been setting routing tables manually
• Same holds true in the Lightning Network (channels are created manually)

My approach / first prototype

• 4 different strategies for node selection
• 2 Strategies which are good for the user
• Barabasi Albert (look for popular loads)
• Respect centrality
• 2 Strategies which are healthy for the network
• Decrease diameter
• Erdoes Renyi (draw from uniform distribution just to increase entropy)
• Following an estimation / suggestion of balances for channels
• Let's look at the 4 strategies!
• Barabasi Albert is clear as we already discussed it
• Erdoes Renyi is also clear

​

Betweenness centrality

• For each pair of nodes calculate the shortest path between them
• For each node count on how many shortest path it lies
• The relative frequency is the betweenness centrality
• Nodes that have a high betweenness centrality can reach many other nodes quickly
• Being connected to such a node is certainly desirable
• So connect to nodes with probability proportional to their betweenness centrality
• Connecting to such a node will generally increase their centrality

​

Betweenness centrality distribution by Kupreet Singh

Decreasing the diameter of the network

• For each pair of nodes calculate the shortest path between them
• Keep track of the length of this path
• Find the pair for which the path is longest
• With higher probability open a channel to nodes which are increasing the diameter
• Makes the own node a little bit more central

Some technical details

• All strategies implemented to produce probability distributions
• There is always some randomization coming from sampling
• Can be smoothed with uniform distribution
• Can be cutoff to only consider top candidates according to a strategy
• There are two different strategies
• Diverse
• Average the distributions and sample from the average
• Merge
• Sample from each and merge the top results
• Cutoffs
• It is possible to only get a predefined top percentile of the distribution

API overview

Balance selection for candidates

• Estimate how much of the UTXO should be allocated to each channel

​

• Sum the the total balance of all channels

​

• Create a probability distribution proportional to the results

​

• Maybe smooth it to avoid dust channels

​

Future ideas

• Articulation points by Kulpreet Singh
• Look at points creating biconnected components
• Look at node age / channel age
• Make lightning nodes collect more statistics
• Uptime of nodes
• Routing fees
• Could indicate if a node / channel is available for inbound capacity
• Previous success / failure of routes
• Recommend to close channels
• Machine Learning

​

Roadmap

• Simulations
• Find out / describe desired properties
• Create a gossip protocol for autopilots to communicate on top of the lightning network (distributed autopilot)
• Request Inbound channels
• Offer outbound channels
• Maybe even exchange some information about channel balance
• Get it merged as a plugin into c-lightning 0.6.3

Conclusions / Thoughts about the autopilot

• Tradeoff between privacy and quality of recommendations
• Path finding and autopilot are related problems
• Recommending channel balances seems reasonable.
• Communication / information sharing might be the way to go
• Selecting routes yourself is perfectly fine
• We need simulation frameworks / research and some real world usage data

Other stuff I currently do

• Running a weekly show on youtube
• https://www.youtube.com/user/RenePickhardt
• (usually Mondays)
• focused on the lightning network
• Sometimes touches bitcoin of course
• Started to write an educational book about the Lightning Network
• https://tallyco.in/s/lnbook/
• Currently creating a custodial wallet service - Talk to me if you are ...
• a shop owner or another player in the lightning field
• a (frontend) developer
• a devops expert
• Consulting
• If time permits & if I need to pay my bills I offer paid consulting services
• I answer any question about lightning for free and if I have time if it is asked openly like on bitcoin.stackexchange.com

​

Thanks for your attention & Questions?

• https://github.com/ElementsProject/lightning/pull/1888
• https://twitter.com/renepickhardt
• https://www.youtube.com/user/RenePickhardt
• https://www.rene-pickhardt.de/improve-the-autopilot-of-bitcoins-lightning-network-summary-of-the-bar-camp-session-at-the-2nd-lightninghackday-in-berlin/

​

​

Copyright

• CC-0 https://pixabay.com/en/wormhole-time-travel-portal-vortex-2514312/
• CC-BY-SA Susette Bader
• CC-BY 3.0 Golang.org
• CC-0 https://commons.wikimedia.org/wiki/File:Rusty_Russell-lca2011%2Bcrop.jpg
• MIT: https://medium.com/@jungly/measuring-node-centrality-in-lightning-network-8102a59999f0

Videos:

• https://www.youtube.com/watch?v=4GDqJVtPEGg
• https://www.youtube.com/watch?v=IPgUi5y3_O8

​