Sergi Delgado / Sergi Delgado is on Nostr

Bitcoin Dev

Last Notes

2025-02-22 00:49:51 UTC

- reply

The funniest thing is that it is not even a 6 upside down lol

2024-11-03 14:15:21 UTC

Had a blast interviewing Phil Zimmermann alongside @nprofile…hxr7 at @nprofile…3g4z
https://image.nostr.build/cb23e387ef96bce72ca26fe2614cc2506d5b4dd124fc24a7ad5b66f1c828a2b8.jpg

2024-11-02 17:14:27 UTC

El directo en directo @nprofile…46jj @nprofile…6kam
https://image.nostr.build/08e311ab4be48a7c48caafa945eff08ec1292cde1b994181585cbd2cecab2f2c.jpg

2024-10-07 20:44:07 UTC

Running Erlay simulations 🧪
https://image.nostr.build/5f05e15672751d5023e2b69c45a6314452cdcacfe316669dd37dde4f83ec7333.png

2024-10-04 19:27:47 UTC

- reply

It's time
https://image.nostr.build/f6678b638d0f0c9a973a6cc14ebcab539dd2639e052efe1858f215a6cefb97bd.jpg
#nevent1q…xt9t

2024-10-04 00:53:40 UTC

Alright I downloaded a Nostr client again, let's see how long I last this time.

2023-07-10 01:46:19 UTC

- reply

Omg what's that!?

2023-06-23 03:12:59 UTC

- reply

Welcome to the fam
https://nostr.build/i/3bdb4b1b4717ecae74152037fb4d1ce8357c2588816595a4d2957304dae92668.jpg

2023-06-17 19:32:08 UTC

The look of happiness @npub1y67…q62h
https://nostr.build/i/23888ae183cfbdd02dac2904d6734c891417bf9d79e0653c578c0285c1d039aa.jpg

2023-05-05 13:41:47 UTC

So, the cat is out of the bag 😅
https://i.imgur.com/RJh8Q7r.jpg

2023-03-29 08:20:03 UTC

IYKYK #bitcoin
https://i.imgur.com/xFjtggL.jpg

2023-03-28 08:25:51 UTC

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.

2023-03-11 19:14:07 UTC

Hello, world!