Sergi Delgado / Sergi Delgado is on Nostr

Bitcoin Dev

Last Notes

2026-05-13 22:39:13 CEST

We've been cooking some great stuff at 2140. All open sourced, even our processes and learnings.
We believe in building in the open. This is our story so far. Read it here on our brand new substack:
👇🏻👇🏻👇🏻
https://2140blog.substack.com/p/our-first-annual-report

2026-05-06 15:46:40 CEST

- reply

No problem

2026-05-01 15:25:00 CEST

Nominations are open for the 2026 Bitcoin Research Prize! 🏆🏆🏆
Submit papers that made an impact on Bitcoin or Lightning published after 2022:
https://forms.gle/DzN1gt7XbgEcMFxw6
Have you (co)authored any papers that fit the submission criteria? Be shameless, submissions are anonymous.

2026-05-01 15:24:15 CEST

Nominations are open for the 2026 Bitcoin Research Prize! 🏆🏆🏆
Submit papers that made an impact on Bitcoin or Lightning published after 2022:
https://forms.gle/DzN1gt7Xb gEcMFxw6
Have you (co)authored any papers that fit the submission criteria? Be shameless, submissions are anonymous.

2025-02-22 01:49:51 CET

- reply

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

2024-11-03 15:15:21 CET

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

2024-11-02 18:14:27 CET

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

2024-10-07 22:44:07 CEST

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

2024-10-04 21:27:47 CEST

- reply

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

2024-10-04 02:53:40 CEST

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

2023-07-10 03:46:19 CEST

- reply

Omg what's that!?

2023-06-23 05:12:59 CEST

- reply

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

2023-06-17 21:32:08 CEST

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

2023-05-05 15:41:47 CEST

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

2023-03-29 10:20:03 CEST

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

2023-03-28 10:25:51 CEST

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 20:14:07 CET

Hello, world!