Revocations and Watchtowers [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2019-09-19T14:54:56+00:00


Summary:

In a conversation between Christian and ZmnSCPxj on the Lightning-dev mailing list, they discuss the storage requirements for nodes and watchtowers in relation to state data. While shachain is used to store revocation transactions in O(1) space and O(log n) time to extract in case of breach, the storage requirements are not constant due to the need to keep information around to react to old states. Watchtowers with Poon-Dryja revocation mechanism still need to store O(n) transactions because shachain stores keys, and watchtowers do not possess revocation keys.To protect against "poisoned blob" attacks, where an attacker creates an encrypted blob that is just random data and feeds it into the watchtower, watchtowers need to store all O(n) transactions they receive for a channel. Even Decker-Russell-Osuntokun watchtowers have to either identify their clients or store all encrypted blobs related to a channel. To reduce the storage requirements, Christian proposes establishing an authenticated session with a watchtower by signing all encrypted updates using a session key. The watchtower would only replace updates that match the session, and the channel outpoint would be added to the update in plaintext to allow the watchtower to prune states for closed channels.Multiple sessions with a single watchtower or spreading across multiple watchtowers could be used to hide the activity and timing of channels. These proposals aim to effectively reduce the storage space for watchtowers in eltoo to O(1). However, implementing these methods would result in a loss of privacy since funding outpoints for unpublished channels would be revealed to the watchtower.The email thread also discusses the advantages of using SIGHASH_NOINPUT in lightning to keep state around in just one transaction. Rusty's shachain construct allows storing O(n) transactions in O(1) space and O(log n) time to extract in case of a breach. Watchtowers need to store all O(n) transactions they receive for a channel to protect against "poisoned blob" attacks. Decker-Russell-Osuntokun watchtowers offer the possibility of having multiparticipant offchain updateable cryptocurrency systems, but there is no work done on watchtowers to allow them to have O(1) storage of channel state without leaking channel activity to the watchtower.


Updated on: 2023-07-31T21:55:34.991361+00:00