1

In the open channel message in BOLT 02 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?

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
6
  • 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
    Mar 1, 2019 at 12:50
  • 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
    Mar 1, 2019 at 14:43
  • 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
    Mar 1, 2019 at 14:51
  • They do all use the same basepoints, but different per_commitment_points. The reasoning is further described here: github.com/lightningnetwork/lightning-rfc/blob/master/… 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
    Mar 1, 2019 at 15:00
  • Please be sure to include follow-up answers in your answer post! :) Comments are meant to be transient.
    – Murch ♦
    Apr 29, 2019 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.