Let's see if I can force myself to stop using Twitter that much and replace it with Nostr.
Lately I've been revisiting how to deal with accountable watchtowers and data deletion, which is something that I never gave enough love to.
The gist of data deletion is pretty straight-forward: if a channel gets closed, a tower does not need to keep the data around anymore (it is useless at this point). For regular towers this is rather easy (modulo not leaking too much info to the tower), you just tell the tower to delete a bunch of data¹.
But how about accountable towers, i.e. towers that have agreed on watching something? Here things get interesting, given the user can trick a tower to delete some data for a channel that has not really been closed, close the channel with an old state, and claim the tower misbehaved (asume both sides of the channel belong to the same user). This will harm the tower's reputation. Hence, in order to delete data the tower needs to store data!1!, that is, a proof of the deletion request. It is easy to see how this is not good, given deletions will also pileup on the tower side.
So, how should we handle this? So far, accumulators seem the best approach: instead of keeping proof of everything that was added/deleted we could accumulate that and keep proof of the accumulated state. Sounds good right? Here's a draft of how that may look like:
https://gist.github.com/sr-gi/f91f007fc8d871ea96ead9b27feec3d5
¹ Bear in mind a tower does not know what data belong to what channel (for privacy reasons), so the user needs to tell the tower what to delete.
sergi / Sergi Delgado
npub1sr…f6kms
2023-03-28 10:25:51
Author Public Key
npub1srgdlg2pvpmgxeavu6cqvmrq8qqfyjmk2crg5dg4rj6rm0tgjr8sgf6kmsPublished at
2023-03-28 10:25:51Event JSON
{
"id": "94e5eb6abf40ecb6cd7b7a92df3156911243390dec398103e230b12746b32941",
"pubkey": "80d0dfa14160768367ace6b0066c603800924b7656068a35151cb43dbd6890cf",
"created_at": 1679991951,
"kind": 1,
"tags": [
[
"r",
"https://gist.github.com/sr-gi/f91f007fc8d871ea96ead9b27feec3d5"
]
],
"content": "Let's see if I can force myself to stop using Twitter that much and replace it with Nostr.\n\nLately I've been revisiting how to deal with accountable watchtowers and data deletion, which is something that I never gave enough love to.\n\nThe gist of data deletion is pretty straight-forward: if a channel gets closed, a tower does not need to keep the data around anymore (it is useless at this point). For regular towers this is rather easy (modulo not leaking too much info to the tower), you just tell the tower to delete a bunch of data¹. \n\nBut how about accountable towers, i.e. towers that have agreed on watching something? Here things get interesting, given the user can trick a tower to delete some data for a channel that has not really been closed, close the channel with an old state, and claim the tower misbehaved (asume both sides of the channel belong to the same user). This will harm the tower's reputation. Hence, in order to delete data the tower needs to store data!1!, that is, a proof of the deletion request. It is easy to see how this is not good, given deletions will also pileup on the tower side.\n\nSo, how should we handle this? So far, accumulators seem the best approach: instead of keeping proof of everything that was added/deleted we could accumulate that and keep proof of the accumulated state. Sounds good right? Here's a draft of how that may look like:\n https://gist.github.com/sr-gi/f91f007fc8d871ea96ead9b27feec3d5\n\n¹ Bear in mind a tower does not know what data belong to what channel (for privacy reasons), so the user needs to tell the tower what to delete.\n",
"sig": "378af4d462d1da35c32fd192648288286bd800dab110061ad83ce469472752f84c49404e61a24936ae870fc83370ad7a61805c3b7dfd52c5e6a6f4732733ccdf"
}