El directo en directo nostr:nprofile1qqszfcmuredsezagmh382j70l33mtv5elqrylrae9z70x9decjt97wcppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7q2fwaen5te0v3hrxc350ymhxcn0xd6nwmrjde3k2ettwvm8jvm4v34xy6npx56hydtnd5mkkvmnxge8zmm4d5ehqdtex5mx7dnfvshx7mnfdahr5dpcxcuj7h946jj nostr:nprofile1qqs9wsye59c9rv838e6l0jyn8csns3m32mqvvl4za7ty8zxu7w47hqqppemhxue69uhkummn9ekx7mp0q9yhwue69uhnvmthd35rxdtpxehk2drc0fmx7unk0q68wamcwdmxsvmyx4a8gap40pmnw7tyxekxxdrhvgmrvenswauhgdek0fckgtn0de5k7m36xsurvwf0q9yhwue69uhngmt6xcenva3jdeuhvur8xekxzurvxekxg7tcwqmkxmrzx3nhwdmjx35hgmtcvecxxdngw95kz7rsven827ncx3ckgtn0de5k7m36xsurvwf0p26kam
Running Erlay simulations 🧪
Alright I downloaded a Nostr client again, let's see how long I last this time.
You can take #zaps from my app, but you can’t take them from me. Zaps are open, forever, and for everyone.
nostr:npub1tfjyq4f6et95lqspy7qz789pkznxuurc8tts48mm4qwrjgg8uh2su32u0r 🙏🤙🫂 
Welcome to the fam
The look of happiness nostr:npub1y67n93njx27lzmg9ua37ce7csvq4awvl6ynfqffzfssvdn7mq9vqlhq62h
So, the cat is out of the bag 😅
IYKYK #bitcoin
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.
Hello, world!