<p>I suppose that when you refer to "third-party watchers" you mean watchtowers. I do agree that 'trustless' is probably an ambiguous word in this context. At the time of writing, the only actual proposal with a protocol that I am aware of is <a href="https://eprint.iacr.org/2018/582.pdf" rel="nofollow noreferrer">PISA</a>, by Andrew Miller et al. PISA allows users to select a custodian that will be incentivised in publishing. Users pay the custodian, and the custodian loses funds if it does not perform (i.e. if the counterparty node manages to publish an old state).</p>

<p>At the moment, seems like <a href="https://tokyo2018.scalingbitcoin.org/presentations" rel="nofollow noreferrer">Roger Wattenhofer is working on it too</a>. However, They have not proposed a protocol yet. Their idea is to incentivise through rewards when channels are 'saved', instead of through penalisation when a watchtower does not save on time. </p>

<p>Both sides have pros and cons. </p>

<ul>
<li><p>The con of Miller's proposal is that one must choose the watchtower, having to trust in it. The counterparty might try to bribe the watchtower, so that they both earn more than the penalisation. </p></li>
<li><p>Wattenhofer's proposal does not have this problem, as anyone in the network can retrieve the reward, and thus everyone is the watchtower. The problem of this proposal is that there are incentives for people to attack other people and prevent them from publishing themselves. </p></li>
</ul>

<p>This is a work in progress. As for a self-claimed trustless watchtower, there has been some discussion in the ligthing-dev mailing list <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html" rel="nofollow noreferrer">here</a> and <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001194.html" rel="nofollow noreferrer">here</a>, but it is yet a work in progress.</p>

CC BY-SA 4.0
2018-11-02T17:09:23.617Z
2018-11-02T17:09:23.617Z
ranchalp
<p>Watchtowers are not trustless, you trust them to monitor the blockchain on your behalf and broadcast a justice transaction in the event of your remote party (counterparty) broadcasting a revoked state. If the watchtower fails to do this you could still lose funds. As a result you may choose to use multiple watchtowers to diversify the risk of an individual watchtower failing to recover your funds.</p>

<p>The early implementation of watchtowers in <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.7.0-beta" rel="nofollow noreferrer">lnd 0.7</a> differentiates between "altruistic" and "basic reward" watchtowers where the latter receives a fee if they broadcast a justice transaction. The remote party could bribe the watchtowers if they knew which watchtower(s) were monitoring the chain on your behalf. This is not public information nor does it need to be shared with the remote party and so it should be extremely difficult for the remote party to discover this information.</p>

<p>For more information on the current implementation of watchtowers in lnd here is a presentation from Conner Fromknecht (Lightning Labs).</p>

<p>Video: <a href="https://www.youtube.com/watch?v=2tyr05tLF4g" rel="nofollow noreferrer">https://www.youtube.com/watch?v=2tyr05tLF4g</a></p>

<p>Transcript: <a href="http://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-conner-fromknecht-watchtowers/" rel="nofollow noreferrer">http://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-conner-fromknecht-watchtowers/</a></p>

<p>Here is a link to the lnd watchtower GitHub repo: <a href="https://github.com/lightningnetwork/lnd/tree/master/watchtower" rel="nofollow noreferrer">https://github.com/lightningnetwork/lnd/tree/master/watchtower</a></p>

<p>The other Lightning implementations do not include watchtower functionality as of today's date (August 2019) but c-lightning seems likely to follow a <a href="https://github.com/ElementsProject/lightning/issues/1353#issuecomment-498274355" rel="nofollow noreferrer">similar approach to lnd</a>.</p>

CC BY-SA 4.0
2019-08-13T09:25:41.920Z
2019-08-13T09:25:41.920Z
Michael Folkson
<p>The main point with LN is the need to monitor the blockchain. The reason for this is to detect if the counterparty misbehaves by publishing an old channel state to the blockchain. For a node running on a server, that is not a big problem since it is always online, but mobile nodes might go offline for days, so how do we deal with this issue?</p>

<p>The need to monitor the blockchain actually only exists if the channel is used in both directions: if you are only paying, any outdated commitment transaction will be more in your favor than the current one, so there is really nothing to do!</p>

<p>But in case of two-way payment channels, this seems to be resolved by "trustless third-party watchers". Since I can't find much literature on the internet about them, I was wondering, how do they work and how exactly are they trustless? For that matter, how do you actually trust that anybody is going to publish on your behalf, and why? Are there incentive mechanisms in place for this to be completely trustless?</p>

CC BY-SA 3.0
2017-07-28T13:03:37.317Z
Here's something I found online: http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/unlinkable-outsourced-channel-monitoring/
Luca Matteis
CC BY-SA 4.0
2018-07-11T09:18:28.077Z
Correct me if I'm wrong, but even if the channel is one-directional, doesn't the counterparty also have an incentive to monitor the blockchain for old commitment txs? So watchtowers are also needed in that case.
Paul Razvan Berg
CC BY-SA 4.0
2018-10-30T18:22:48.243Z
@PaulRBerg no, for one-directional payment channels this would not be needed.

Imagine a one-directional channel from Alice to Bob. The latest state is always the most lucrative for Bob, so he wouldn't cheat because he's lacking the incentive to do so. I know, you already knew that and you care more about what happens the other way around. So why wouldn't Alice broadcast an old state? Simple: she can't. While Alice is sending tx after tx to Bob, spending their 2-of-2 multisig she would always sign the transactions, while Bob actually neither has to sign nor send the transaction anywhere.
Dalit Sairio
CC BY-SA 4.0
2018-10-30T18:24:13.320Z
The first time Bob would need to sign and broadcast the transaction is when he wants to close the channel.
Dalit Sairio
<lightning-network><ln-node-reliability><watchtower>
How do "trustless third-party watchers" work in Lightning Network?
Luca Matteis
# How do "trustless third-party watchers" work in Lightning Network?

(Asked by: username_0 on 2017-07-28)

The main point with LN is the need to monitor the blockchain. The reason for this is to detect if the counterparty misbehaves by publishing an old channel state to the blockchain. For a node running on a server, that is not a big problem since it is always online, but mobile nodes might go offline for days, so how do we deal with this issue?

The need to monitor the blockchain actually only exists if the channel is used in both directions: if you are only paying, any outdated commitment transaction will be more in your favor than the current one, so there is really nothing to do!

But in case of two-way payment channels, this seems to be resolved by "trustless third-party watchers". Since I can't find much literature on the internet about them, I was wondering, how do they work and how exactly are they trustless? For that matter, how do you actually trust that anybody is going to publish on your behalf, and why? Are there incentive mechanisms in place for this to be completely trustless?

**Tags:** lightning-network, ln-node-reliability, watchtower

> **Comments:**
> **username_0**: Here's something I found online: http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/unlinkable-outsourced-channel-monitoring/  
> **username_1**: Correct me if I'm wrong, but even if the channel is one-directional, doesn't the counterparty also have an incentive to monitor the blockchain for old commitment txs? So watchtowers are also needed in that case.  
> **username_2**: @PaulRBerg no, for one-directional payment channels this would not be needed.  Imagine a one-directional channel from Alice to Bob. The latest state is always the most lucrative for Bob, so he wouldn't cheat because he's lacking the incentive to do so. I know, you already knew that and you care more about what happens the other way around. So why wouldn't Alice broadcast an old state? Simple: she can't. While Alice is sending tx after tx to Bob, spending their 2-of-2 multisig she would always sign the transactions, while Bob actually neither has to sign nor send the transaction anywhere.  
> **username_2**: The first time Bob would need to sign and broadcast the transaction is when he wants to close the channel.  

---

## 2 answers

### Answer by username_3 on 2018-11-02. Score: 2

I suppose that when you refer to "third-party watchers" you mean watchtowers. I do agree that 'trustless' is probably an ambiguous word in this context. At the time of writing, the only actual proposal with a protocol that I am aware of is [PISA](https://eprint.iacr.org/2018/582.pdf), by Andrew Miller et al. PISA allows users to select a custodian that will be incentivised in publishing. Users pay the custodian, and the custodian loses funds if it does not perform (i.e. if the counterparty node manages to publish an old state).

At the moment, seems like [Roger Wattenhofer is working on it too](https://tokyo2018.scalingbitcoin.org/presentations). However, They have not proposed a protocol yet. Their idea is to incentivise through rewards when channels are 'saved', instead of through penalisation when a watchtower does not save on time.

Both sides have pros and cons.

* The con of Miller's proposal is that one must choose the watchtower, having to trust in it. The counterparty might try to bribe the watchtower, so that they both earn more than the penalisation.
* Wattenhofer's proposal does not have this problem, as anyone in the network can retrieve the reward, and thus everyone is the watchtower. The problem of this proposal is that there are incentives for people to attack other people and prevent them from publishing themselves.

This is a work in progress. As for a self-claimed trustless watchtower, there has been some discussion in the ligthing-dev mailing list [here](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html) and [here](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001194.html), but it is yet a work in progress.


---

### Answer by username_4 on 2019-08-13. Score: 0

Watchtowers are not trustless, you trust them to monitor the blockchain on your behalf and broadcast a justice transaction in the event of your remote party (counterparty) broadcasting a revoked state. If the watchtower fails to do this you could still lose funds. As a result you may choose to use multiple watchtowers to diversify the risk of an individual watchtower failing to recover your funds.

The early implementation of watchtowers in [lnd 0.7](https://github.com/lightningnetwork/lnd/releases/tag/v0.7.0-beta) differentiates between "altruistic" and "basic reward" watchtowers where the latter receives a fee if they broadcast a justice transaction. The remote party could bribe the watchtowers if they knew which watchtower(s) were monitoring the chain on your behalf. This is not public information nor does it need to be shared with the remote party and so it should be extremely difficult for the remote party to discover this information.

For more information on the current implementation of watchtowers in lnd here is a presentation from Conner Fromknecht (Lightning Labs).

Video: <https://www.youtube.com/watch?v=2tyr05tLF4g>

Transcript: <http://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-conner-fromknecht-watchtowers/>

Here is a link to the lnd watchtower GitHub repo: <https://github.com/lightningnetwork/lnd/tree/master/watchtower>

The other Lightning implementations do not include watchtower functionality as of today's date (August 2019) but c-lightning seems likely to follow a [similar approach to lnd](https://github.com/ElementsProject/lightning/issues/1353#issuecomment-498274355).


---

