Re: [Lightning-dev] Revocations and Watchtowers
Good morning Christian, > 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). Ah, right. I forgot these. More specifically, even though the HTLC outputs are revocable with only knowledge of the revocation key, the SCRIPT itself needs to be provided in full, including the payment hashes. > 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. It seems that even with multiple sessions with a single watchtower, if the watchtower assumes you are not under direct attack (a reasonable assumption), it would still get all the information on all activity on a channel. Spreading across multiple watchtowers assumes other watchtowers are somehow not sybils of an existing Big Brother watchtower. > 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. Would this not mean revealing funding outpoints for unpublished channels as well, at least to the watchtower? It seems to me there is significantly more privacy loss with these kinds of watchtowers. Before, I proposed to continue using encrypted-blob watchtowers, except rather than triggering on txid[:16], instead trigger on sighash[:16] (so it would work with either Poon-Dryja or Decker-Russell-Osuntokun). This would work with `SIGHASH_NOINPUT` on the update transactions (by matching the computed sighash for `SIGHASH_NOINBPUT`), letting watchtowers rebuild the entire sequence of updates (by also looking at further matches of sighash[:16]) in case of a breach, but *only* in case of a breach. With this style, watchtowers cannot know, even within a session, whether a hundred updates you send are for a single channel updating 100 times or for a hundred channels updated once each. Similarly to Poon-Dryja watchtowers you would send the (sighash[:16], encrypted_blob) pair for an update tx that has just been replaced with a new version. And if the old update tx is never put onchain, the watchtower never learns about what channel it was watching (unlike the proposed style where the key is the actual channel outpoint, which reveals to the watchtower the channel it was watching). Of course, I suppose privacy is less important in practice for most users than convenience and low price, sigh. A privacy-conscious person might run one or more private watchtowers for their nodes, and distribute them physically as much as he or she can. But there is still the risk that one or more of these are hacked (indeed there is increased risk if they are not within easy physical reach of the owner), and it would be best still if the watchtowers so created have as little practical information to reveal as possible, so I believe my point still stands. Nonetheless, code talks, so feel free to ignore me here. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Revocations and Watchtowers
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 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 > * >
[Lightning-dev] Revocations and Watchtowers
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
