Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-19 📝 Original message: I don't think this paints ...
📅 Original date posted:2019-09-19
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev