’m at the ISC West security expo today.

I have seen the words “AI,” “surveillance,” “autonomous,” “trust,” “safety,” and “threat monitoring” used more times than I can count and in various combinations…

L185 - Miedos de principiante en #bitcoin, junto a Carmen, Víctor y Diego Gurpegui

Hoy tratamos el miedo:

- a que no sea una alternativa al fiat

- a la volatilidad

- a no poder retirar del exchange

- a las prohibiciones

- al consumo energético

Y mucho + aquí

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: