[Lightning-dev] Revocations and Watchtowers

[ZmnSCPxj]

Good morning list,

I was reading through the transcript of recent talk: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/

In section "Revocations and SIGHASH_NOINPUT":

> There's another issue in lightning, which is the revocation transactions. There are basically, every time you do a state update, there's an extra transactions that both parties need to hold forever. If you're doing watchtowers, then the watchtowers need to keep all this evergrowing state.
>
> ...
>
> using SIGHASH_NOINPUT ... You have state to keep around, but it's just one transaction and it scales with O(1) instead of O(n).


I thought I would just like to point out a few things:

* Rusty created shachain so that we can store the O(n) transactions in O(1) space (though with large constant) and O(log n) time to extract in case of breach (and breach is expected to be a rare operation).
  (Rusty can correct me if I am incorrect in the performance of this shachain construct).
  * For the most part we can ignore (I think) the storage of revocation keys at this point in LN development.
  * There is a limit to the number of updates possible, but my understanding is that this is so large as to be impractical for users to reach even with long-lifetime channels.
* Admittedly, watchtowers with Poon-Dryja revocation mechanism need to store O(n) transactions.
  This is because shachain stores keys, and we do not want watchtowers to possess revocation keys, only pre-built signatures to revocation transactions that pay a partial fee to the watchtower (else the watchtower could sign a revocation transaction paying only to itself without giving the client any money at all).
  But!
  * Watchtowers, even with Decker-Russell-Osuntokun, still need to store *all* O(n) transactions it receives for a channel.
    This is needed to protect against "poisoned blob" attacks, where an attacker creates an encrypted blob that is just random data and feeds it into the watchtower.
    See:
      * https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html
      * https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001267.html
  * Of note is that even Decker-Russell-Osuntokun watchtowers either need to identify their clients so that attackers cannot spoof the clients (meaning clients trust the watchtower with their financial information!) or have to store all encrypted blobs related to a channel (meaning O(n) data is still stored by the watchtower for each channel, despite the other advantages of Decker-Russell-Osuntokun).

I do not know if work has been done on watchtowers to allow them to have O(1) storage of channel state, without leaking channel activity to the watchtower.

That is, even for Decker-Russell-Osuntokun I think it is better to make an effort to keep channel activity from being correlated by the watchtower, and this will require O(n) storage at the watchtower where n is number of updates in channel.

I think the main advantage of Decker-Russell-Osuntokun (and thus the `SIGHASH_NOINPUT` it requires) is the possibility of having multiparticipant offchain updateable cryptocurrency systems, not the storage advantages.


Regards,
ZmnSCPxj