I don't think this paints an accurate picture, both when it comes to watchtowers for LN-penalty as well as for eltoo:
Technically the storage requirement for the shachain is also O(log(n)) and not O(1) due to the fact that we effectively have a cut through the height of the tree, along which we have to keep the inner nodes until we get the parent node which then allows us to infer the children. Given that we use a constant size for that tree, it is not really relevant but I thought it might be worth pointing this out. The shachain is currently limited to 2^48 updates, which is way beyond what we can hope to achieve on a single channel, so I agree with you that this limit is not important at all currently. Even with shachain the storage requirements for the nodes (not the watchtowers) are far from being constant either: since any old state, including anything that we built on top of it (HTLCs), so we need to keep information around to react to those as well (preimages that cannot be subsumed in a shachain since the HTLC preimage is chosen by many remote senders). When it comes to eltoo, just reusing the same watchtower protocol that we designed for LN-penalty, with unidentified blobs, randomly inserted by anyone, and encrypted with the commitment transaction is likely too simplistic, and results in the O(n) requirement you mentioned. My proposal would be to establish an authenticated session with a watchtower, e.g., by signing all encrypted updates using a session key, and the watchtower only replacing updates that match the session. An attacker could not replace my updates I stashed with the watchtower since it cannot hijack my session. This means that the watchtower can be certain that it can discard old states, but still have the correct reaction stashed when it needs it. Notice that this is already what the lnd watchtower protocol pretty much does, and it is likely that we'd like a session anyway in order to pay the watchtower for its service. I think it's unrealistic to expect altruistic watchtowers storing encrypted blobs for some random people out there in eternity, without getting compensation for it. To hide the activity and timing of our channels we could simply open multiple sessions with the watchtower, or spread them across multiple watchtowers. I'd even go further and just add the channel outpoint (or should I call it "contract outpoint"?) to the update in cleartext so that the watchtower can prune states for closed channels. We can still spread the states across multiple watchtowers to hide update rate and timing. So this effectively gets us to a O(1) storage space for watchtowers in eltoo. Cheers, Christian ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes: > 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 > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
