<p>Actually, the BOLT has been designed with very strong privacy properties with regard to watchtowers. You can give all your commitment tx id first halves to one watchtower and it still doesn't learn anything about the second halves, others txs or anything else about the state of the channel (or which channel it is watching at all), as long as the full commitment tx doesn't show up on the blockchain. Once it does, it still cannot learn anything beyond this one commitment state. That's what this is done for and it is rather remarkable IMHO.</p>

CC BY-SA 4.0
2019-03-01T12:50:15.573Z
sorry I don't get it. I see that I can give a partial of the commitment tx id to a watchtower service and that they could identify the tx if it apears on the blockchain. However once it does so the watchtower is supposed to claim the funds on my behalf by releasing my breach remedy tx. If it doesn't have that one (which would reveale the state of the channel) the watching service seems pretty useless to me. I guess I am missing something. Would be awesome if you could elaborate
Rene Pickhardt
CC BY-SA 4.0
2019-03-01T14:43:05.433Z
The remedy tx that you give to the watchtower is encrypted with the second half of the commitment tx id, so the watchtower cannot read it unless it first encounters the commitment tx on the blockchain.
stefanwouldgo
CC BY-SA 4.0
2019-03-01T14:51:57.477Z
ok that was the missing piece of the puzzle and is indeed a very interesting approach. What I still don't get is why your approach would not work if all commitment txs would have used the same basepoint for the private key. I mean the tx ids would still be different due to the different amounts or am I missing something?
Rene Pickhardt
CC BY-SA 4.0
2019-03-01T15:00:05.937Z
They do all use the same basepoints, but different per_commitment_points. The reasoning is further described here: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#key-derivation The general idea is that watchtowers or anyone else should not learn more about the channel than absolutely necessary, while at the same time ideally storing as little data as possible. The second part doesn't work so well in practice so far, it appears. Eltoo would improve that.
stefanwouldgo
CC BY-SA 4.0
2019-04-29T03:59:16.273Z
Please be sure to include follow-up answers in your answer post! :) Comments are meant to be transient.
Murch
CC BY-SA 4.0
2019-04-29T15:49:51.980Z
Really? How? Try and integrate all the back and forth in an artificial answer? Delete the comments? Falsify history? Sounds hard and dangerous to me.
stefanwouldgo
CC BY-SA 4.0
2019-03-01T10:40:00.203Z
2019-03-01T10:40:00.203Z
stefanwouldgo
<p>In the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message" rel="nofollow noreferrer"><code>open channel</code> message in BOLT 02</a> the following statement is written about the various basepoints. </p>

<blockquote>
  <p>The various _basepoint fields are used to derive unique keys as described in BOLT #3 for each commitment transaction. Varying these keys ensures that the transaction ID of each commitment transaction is unpredictable to an external observer, even if one commitment transaction is seen; this property is very useful for preserving privacy when outsourcing penalty transactions to third parties.</p>
</blockquote>

<p>I wonder about the last sentence. Why does this in particular help with the privacy of such services? I thought I increase privacy by using several third party watching services and not only one. In case I use one they would know my entire channel state history anyway. </p>

<p>One thing that I guessed was that once I know one commitment tx I could calculate all txids for all possible channelstates. But I thought the signatures depend on the amount of the outputs and the txid depend on the signatures.</p>

<p>Do I have a misconception or is the reason for the increased privacy another one that I don't see? </p>

<transactions><lightning-network><privacy><multi-signature><watchtower>
Why is the privacy for using watch tower services increased with unpredictable commitment tx ids?
Rene Pickhardt
# Why is the privacy for using watch tower services increased with unpredictable commitment tx ids?

(Asked by: username_0 on 2019-02-28)

In the [`open channel` message in BOLT 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message) the following statement is written about the various basepoints.

> The various \_basepoint fields are used to derive unique keys as described in BOLT #3 for each commitment transaction. Varying these keys ensures that the transaction ID of each commitment transaction is unpredictable to an external observer, even if one commitment transaction is seen; this property is very useful for preserving privacy when outsourcing penalty transactions to third parties.

I wonder about the last sentence. Why does this in particular help with the privacy of such services? I thought I increase privacy by using several third party watching services and not only one. In case I use one they would know my entire channel state history anyway.

One thing that I guessed was that once I know one commitment tx I could calculate all txids for all possible channelstates. But I thought the signatures depend on the amount of the outputs and the txid depend on the signatures.

Do I have a misconception or is the reason for the increased privacy another one that I don't see?

**Tags:** transactions, lightning-network, privacy, multi-signature, watchtower


---

## 1 answers

### Answer by username_1 on 2019-03-01. Score: 2 | Accepted answer

Actually, the BOLT has been designed with very strong privacy properties with regard to watchtowers. You can give all your commitment tx id first halves to one watchtower and it still doesn't learn anything about the second halves, others txs or anything else about the state of the channel (or which channel it is watching at all), as long as the full commitment tx doesn't show up on the blockchain. Once it does, it still cannot learn anything beyond this one commitment state. That's what this is done for and it is rather remarkable IMHO.

> **Comments:**
> **username_0**: sorry I don't get it. I see that I can give a partial of the commitment tx id to a watchtower service and that they could identify the tx if it apears on the blockchain. However once it does so the watchtower is supposed to claim the funds on my behalf by releasing my breach remedy tx. If it doesn't have that one (which would reveale the state of the channel) the watching service seems pretty useless to me. I guess I am missing something. Would be awesome if you could elaborate  
> **username_1**: The remedy tx that you give to the watchtower is encrypted with the second half of the commitment tx id, so the watchtower cannot read it unless it first encounters the commitment tx on the blockchain.  
> **username_0**: ok that was the missing piece of the puzzle and is indeed a very interesting approach. What I still don't get is why your approach would not work if all commitment txs would have used the same basepoint for the private key. I mean the tx ids would still be different due to the different amounts or am I missing something?  
> **username_1**: They do all use the same basepoints, but different per_commitment_points. The reasoning is further described here: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#key-derivation The general idea is that watchtowers or anyone else should not learn more about the channel than absolutely necessary, while at the same time ideally storing as little data as possible. The second part doesn't work so well in practice so far, it appears. Eltoo would improve that.  
> **username_2**: Please be sure to include follow-up answers in your answer post! :) Comments are meant to be transient.  
> **username_1**: Really? How? Try and integrate all the back and forth in an artificial answer? Delete the comments? Falsify history? Sounds hard and dangerous to me.  

---

