Watchtower support is coming to Bitcoin Lightning Wallet
As of 0.2–76 update BLW will have watchtower functionality present and enabled by default. You will no longer have to care about getting your wallet online periodically if you use BLW to receive Lightning payments.
For those interested in details I’d like to explain here what exact problem is being addressed and how my implementation tries to do it in a technologically sound and economically sustainable way.
What is the problem?
Every Lightning payment attempt creates a valid Bitcoin commitment transaction which fixates current channel balance distribution. This transaction can be broadcasted by either party at any time, even if a state it captures gets invalidated later by subsequent Lightning payments.
To understand why this can be dangerous let’s consider the following picture which illustrates a channel opening and a number of following payments which create a trail of valid commitment transactions.
States b) through d) depict outgoing payments. After each outgoing payment you only have less money and your peer only has more so if they want to break a channel at some point the only rational choice is to spend the last commitment transaction, otherwise it would be a gift to you. This is the idea behind send-only wallets such as Eclair for Android: they don’t allow receiving Lightning funds but also don’t require you to become online periodically and there is no need for a watchtower.
Now let’s look at the last e) payment. This is an incoming one which shifts part of channel balance back to you. The issue here is that commitment transactions for payments c) and d) don’t go anywhere and your peer may be tempted to broadcast those since they are more beneficial to peer than current channel state.
What protects you from funds loss here is that each commitment transaction sends funds to a limbo address which is designed in such a way that your peer needs to wait a number of blocks in order to finally transfer those coins into their wallet, but you can sweep the whole channel balance right away once your wallet sees a broadcasted commitment transaction.
Obviously, for this to work someone capable of punishing a misbehaving peer needs to be online periodically. In BLW the wait period is set to 2016 Bitcoin blocks and up until now this long delay was the only thing protecting users from channel breaches.
This approach was far from perfect as it’s absolutely reasonable to assume someone could just forget to launch an app at least once per 2016 blocks and thus get into risk of funds getting stolen.
How watchtower improves a situation
The idea is simple: watchtower is a service which is always online and watching for channel breaches even at times when your wallet is offline. Implementation is also pretty straightforward, here is a complete high-level overview of an algorithm:
1. On every incoming or outgoing Lightning payment BLW creates a blob of signatures and public keys required to punish a peer in case if corresponding commitment transaction gets broadcasted. This blob is then saved into local BLW database.
2. After every incoming payment BLW futher looks into local database and searches for past payments which your peer might be now tempted to broadcast (those would be c) and d) in a picture above).
3. For every found payment BLW encrypts a punishment blob with it’s corresponding commitment transaction ID used as decryption key, then cuts TXID in half so we obtain an (encrypted blob, halfTXID) pair.
4. Once all the pairs are ready BLW sends them to watchtower in a series of packs each containing of up to 20 pairs (the reason for such batching is explained below).
5. Watchtower saves every pair in a database and continuously listens to new blocks looking if any new halfTXID matches the one it has in a database. If it does, this means your peer has broadcasted an old channel state. Watchtower now has a fullTXID which it uses to decrypt a corresponding blob and broadcast punishment transactions.
Watchtower service has economical challenges
Running it requires a reasonable infrastructure: at a minimum watching server needs to have enough resources to store potentially billions of blobs and run a Bitcoin node. As such, it can not be expected for watchower to provide a service for free, there should be a reward of some kind or else an owner might be tempted to just stop an operation at some point and leave wallet users insecure*.
* Even if watchtower is not there all of a sudden you still can punish a peer all by yourself if they breach a channel and you manage to get your wallet online during the next 2016 blocks.
One popular proposal for making it incentive compatible is to include a watchtower reward in every punishment blob so when a breach happens watchtower gets a part of channel balance by just publishing a punishment transaction. In my opinion this approach is flawed for two reasons:
1. Channel breaches are not expected to happen often so it does not seem to me that service will be able to sustain itself by earning on rewards alone.
2. This gives some weird incentives: watchtower now wants all peers to breach their channels as often as possible. This may result in hacks and other attempts to influence LN node owners.
Storage tokens as a solution
Those who use BLW already know it has an accompanying maintenance server called Olympus which takes Chaumian-style ecash tokens for storing various user data.
Until now these tokens were only used to store encrypted channel backups but now Olympus also provides a watchtower service which requires one storage token for watching of up to 20 encrypted blobs. This is the reason BLW batches pairs of (encrypted blob, halfTXID) into packs of up to 20 items before sending them to Olympus: every pack has a storage token attached so watching service gets paid every time it accepts a blob.
Currently Olympus charges 1000 SAT per 50 tokens so each token costs 20 SAT. Thus, storing each commitment transaction costs about 1 SAT.
BLW acquires tokens automatically when there is a need for them by fulfilling an LN payment issued by Olympus server, the whole process is mostly transparent to users, the only noticeable thing would be 1000 SAT Lightning payments occasionally popping up in a wallet payment list.
All that said, user is free to opt out of this scheme at any time and rely solely on getting online per 2016 block periods, as shown on a screenshots below.
