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
