Seed Based Payment
Channel Recovery
David VorickBackground
Lightning network is a payment channel network that
improves Bitcoin’s transaction scalability
Scalability comes from continually updating these channels
off-chain

Problem
Keeping these payment channel midstates is critical for theuser’s security.
Loss of the mid-state can result in an inability to use thechannel, and can allow your counterparty to steal funds byposting an old state.
User backups need to remain up to date.

Partial Solution: Watchtowers
Watchtowers track midstate for the user.
Watchtowers can penalize counterparties that cheat.
Watchtowers cannot post the ﬁnal state of a transaction if
both the user and the counterparty are ofﬂine.

Watchtower Complications
Watchtowers need to store data for every mid-state of achannel, which is expensive for high usage channels.
Watchtowers need to have high reliability and uptime to behighly effective.
Watchtowers are non-trivial infrastructure to add into thelightning ecosystem. Practical, but non-trivial.

Alternate Solution: Seed-Based Midstate
RecoveryOur goal is to provide the user with a method to recover theirchannel mid-states that does not depend on any external
party such as a watchtower.

Major Assumption
This technique depends on a user forming channels with a hub
which can be expected to be more reliable. In a purely
peer-to-peer environment, the “hub” can be substituted with awatchtower that gets updated after every payment channeltransaction.
Future research may enable this research in a purepeer-to-peer environment without a watchtower.

General Strategy
The user will leverage their payment hubs as storage devices for
all recent payment channel information.
Each time the user connects to the hub, the user will require thehub to provide all information.
All interactions are identical, even after the user has lost data.
The hub does not know when there is an opportunity to cheat.

Information Stored
The hub will be storing the most recent midstate of thechannel.
The user can also require the hub to store the most recent
midstate of other channels (other hubs, and other p2p peers).
The data will be presented as a single encrypted blob of ﬁxed
size, suggested 40 KiB.

Information Stored
The blob can be encrypted using a password derived from theuser’s wallet seed and the hub’s public key.
40 KiB leaves room for the midstates of a large number ofchannels, without being burdensome to the hub.
The hub can support hundreds of thousands of users with justa few GiBs.

Information Stored
The blob will contain a counter/version, allowing the user todetermine which blobs are most recent.
Because the blob is ﬁxed size, there is also potentially room inthe blob for additional arbitrary data.

User Requirement
The user will store the information that is kept in theencrypted blob. This allows the user to verify that the hub ishonest in the typical case.

Payment Protocol (Normal Operation)
The payment protocol will require that the hub provide theuser with the most recent version of the 40 KiB blob before
the user makes any transactions.
If the user has not experienced data loss, the user will decrypt
the blob and compare it to the blob that the host is supposed
to be storing.

Payment Protocol (Normal Operation)
If the user has channels to other hubs, the user will open aconnection with them and request the most recent blob fromeach of them as well.
If the blob matches, the user will prepare the desiredtransaction and give each honest hub a new blob to store
which contains the updated midstate.

Payment Protocol (Normal Operation)
After all hubs have conﬁrmed receipt of the most recent blob,the ﬁnalized transaction can be sent. This completes theprotocol.

Payment Protocol (Dishonest Hub)
If any hub is dishonest and provides an outdated blob, theuser completes a transaction and later requests that the hub
close the channel.
When the channel is closed with the outdated state, the user
can submit a penalty transaction.

Protocol Extension
The protocol can be extended to have all hubs sign eachmessage with a timestamp. If a hub ever attempts to act
maliciously, the user has explicit proof that can be provided toother users on the lightning network.

Payment Protocol (User Recovery)
If the user has lost data, the user can still perform thepayment protocol.
The payment protocol starts like normal. The user pretends
that all data is available, and requires the hub to send the mostrecent version of the blob.

Payment Protocol (User Recovery)
After receiving the blob from the hub, the user will request
the same blob from all other hubs that the user has channels
with.
So far, there has been no deviation from the typical protocol.
The hubs have no way of knowing yet that the user has lostdata.

Payment Protocol (User Recovery)
The user has now received encrypted blobs from all hubs.
The user is able to decrypt the blobs with just the wallet seed,
and then cross-reference the counters and payment channel
states in each blob.
So long as at least one hub is honest, the user is able toperform a successful payment channel midstate recovery.

Peer to Peer Channels
So long as the user has a channel with at least one hub, theuser can use this protocol to store payment channel midstate
updates for all peer to peer channels.

Tradeoﬀs Overview
The biggest tradeoff is that all hubs must be contacted eachtime a payment channel update occurs.
A small tradeoff is that each hub must now store 40 KiB peruser. This should be trivial, especially if users are paying
transaction fees to the hubs.

Incentives Observation
An honest hub can provide the user with information that
potentially allows the user to penalize a competing hub.
This acts as a mild incentive for hubs to be honest.

Security Limitation
If all of a user’s hubs are collaborating dishonestly during auser recovery, the user will be unable to detect the malice andbecomes vulnerable to penalty transactions from the hubs.

Seed Based Midstate Recovery: Missing Pieces
This presentation has covered how to recover a midstate froma hub.
If the user has lost all data and has only a wallet seed, the userneeds to undertake the task of ﬁguring out which on-chain
payment channels belong to the user, and which hubs are thecounterparties to each channel.

Payment Channel Coloring
The user can color each opening payment channel transaction
with some extra identiﬁer data in the transaction.
The identiﬁer can be a message encrypted using a password
derived from the user’s seed and the output id of the ﬁrst
output in the transaction.
The identiﬁer will be called a “color”.

Payment Channel Coloring
Every transaction will have a different color. External parties
will be unable to link related transactions based on the color.
The owner of a transaction can identify all of their payment
channels using nothing but the public blockchain and theirwallet seed.

Counterparty Discovery
The on-chain transaction will need to contain a reference to a
public key of a counterparty.
If privacy is desired, this reference can be encrypted using theuser’s wallet seed.

Counterparty Discovery
The public key can be used to look up the counterparty in a
public key infrastructure.
This PKI could be stored on-chain, on a side-chain, or could bea more traditional PKI.
The PKI must map from the public key to an IP address or
hostname that can be used to contact the counterparty.

Tradeoﬀs
The transaction coloring and on-chain public key eachincrease the on-chain size of a payment channel.
These strategies can likely be deployed in ways that do not
impact privacy.

Better than Watchtowers?
Requires hubs.
Requires slightly increased on-chain storage.
Transacting requires contacting more parties.
Probably simpler than watchtowers in practice.
Not a perfect replacement for watchtowers.

Future Research
The increased on-chain transaction sizes can probably bereduced.
The ‘contact all hubs each transaction’ requirement canprobably be reduced.
Better deﬁned fee mechanisms for hubs.
Elimination of hubs as a requirement.

Questions?