Bugtus

Public Key

npub1sezgmhk40mk5znnqse5jz4mjx40vszz45zwqnf7wyxqvdz0t8wnq9mnhp3

Profile Code

nprofile1qqsgv3ydmm2ham2pfesgv6fp2aer2hkgpp26p8qf5l8zrqxx384nhfspp4mhxue69uhkummn9ekx7mqpzpmhxue69uhkummnw3ezuamfdejspg6ngf

Publishing to

nostr.einundzwanzig.space

nostr.notribe.net

Author Public Key

npub1sezgmhk40mk5znnqse5jz4mjx40vszz45zwqnf7wyxqvdz0t8wnq9mnhp3

Show more details

Last Notes

2026-02-12 20:14:08 CET

- reply

How about backing Nostr events (or pubkeys) with timelocked fidelity bonds as an alternative/addition to proof-of-burn?
This seems to mitigate the perverse incentive you mention at the end of your paper:
> "Interestingly, this proposal creates an incentive for Bitcoin miners to spam unprotected Nostr relays, in order to force users to pay for their posts."
With a bond, the cost is capital lock-up rather than a per event sacrifice, so miners don’t receive the "attention fee" itself (only normal on-chain transaction fees). And the bond is still globally verifiable by anyone with a Bitcoin node.
The math on how bonds could be valued compared to burns is explained here:
> https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
(Although, if bonds were per event, I suspect the quadratic factor should be removed. However, if bonds are per pubkey for sybil resistance the quadratic factor makes sense.)
To avoid UTXO bloat, I suspect a notary could aggregate many small user timelocks into a single on-chain bond UTXO using an Ark-like construction, while still giving each user a unilateral exit path after the timelock if the notary stops cooperating. I'm unsure about the details though.

2026-01-13 16:24:01 CET

- reply

First off, thank you so much for the reply! I'm really happy to have someone engage with the stuff I've been thinking about. As for your questions...
> do Privacy Pass tokens have value?
They don't have value in the sense that Cashu tokens have value. They are an unlinkable credential. All a Privacy Pass token encodes in this case is "this user time-locked some amount of sats for some amount of time." Tokens are short-lived and tied to a key epoch.
> are tokens accepted across relays?
I haven't quite made my mind up about this, so I thought you might have some insight into what makes the most sense for Nostr.
The simplest approach is the Issuer and Relay being the same entity. This allows the relay to stay fully offline by checking tokens against an internal spent list, whereas portability across multiple relays (where the Issuer is a separate entity) would likely require an online check to sync the tokens 'spent' state.
This isn't ideal if we want a user to be able to publish the same event to multiple relays with a single token. I have some ideas for redemption without having to contact the issuer:
1. Bind to event_id: We could choose the Nostr event_id as the secret that gets blind signed. The token is then tied to that exact event and acts as a ticket usable across multiple relays. However, this prevents batched issuance (you can't create the token until you know the event), and allows for time-correlation attacks if spent immediately after issuance.
2. Bind to Ephemeral Keys: We choose ephemeral pubkeys as the secrets. In addition to attaching the token, the user signs the event with the corresponding ephemeral privkey. No observer (e.g. a malicious relay) can reuse that token because they don't know the privkey. However, a user could theoretically use a single token to send 1,000 different events to 1,000 different relays. I'm not sure if that is a problem. What do you think?
> Do Issuers have a reputation and how do they become reputable?
Yes definitely, we need reputation if the Relay isn't the same entity as the Issuer! So a relay would most likely advertise "I only accept PP tokens from this list of Issuers I find reputable." Reputation would be built over time (sats always get unlocked on time, total token volume from the Issuer aligns with other metrics, etc.). If Cashu Mints actually end up issuing PP tokens as well, reputation could be inherited from the Mint's existing reputation. Hope I understood your question right.
> On the other hand, I think that Cashu might be the best fit for this use case
It definitely makes it a lot simpler. I just wanted to include the trust-minimized option because of how some people react to giving up their custody over sats.
> Do you imagine mints and PP token issuers being the same entity?
I think it would make sense if Cashu Mints and PP token issuers are the same entity. Of course, that's not for me to decide. If Mint operators agree that something like this would be worthwhile, then they might adopt it.
Thanks again, I really appreciate it!

2026-01-12 19:45:27 CET

- reply

> I'm curious to hear more about your approach.
Gladly! As you mentioned, traditional rate limiting is a bit lacking for permissionless, decentralized networks. IP based rate limiting penalizes privacy-conscious users (VPN/Tor), everybody hates interactive CAPTCHAs (and AI is getting better at them than humans anyway), behavioral CAPTCHAs are a privacy nightmare, and PoW discriminates against mobile devices. Paying for events (e.g., proof-of-burn, Thomas Voegtlin) definitely works, but I worry it creates too high a UX hurdle for widespread adoption.
What I'm proposing is an economic, privacy-preserving mechanism that works by time-locking sats instead of burning them. Ideally, this has near-zero cost for legitimate users (minus opportunity costs and routing fees), whereas spammers must immobilize capital proportional to the event throughput they want to sustain.
For example, a normal user might lock a trivial amount (e.g. $10) to generate enough tokens for a full day of activity. In contrast, capital requirements scale linearly for spammers. To sustain 10,000 requests/sec, an attacker hits a massive liquidity wall, effectively needing to lock millions of dollars just to keep the attack running. Crucially, relays can also dynamically adjust the lock requirement based on load (like 'surge pricing'). While this slightly increases the bond for honest users, it forces the attacker’s capital requirements to scale more than linearly.
The mechanism works by requiring events to include Privacy Pass tokens. These work very similarly to Cashu tokens: Users go to an Attester/Issuer (the Mint) with blinded secrets, perform an action (locking sats), and get signed secrets in return. The user unblinds them to get a batch of tokens, which they attach to events. This allows the Relay to verify the sats were locked without them or the Mint being able to link the event back to the locking transaction.
> Are you basing your solution on something like Cashu, or just LN with hold invoices?
Yes, those are the two options I have in mind.
1. Cashu: Users lock ecash. Cashu Mints are well positioned to issue Privacy Pass tokens as well, but users run the risk of the Mint rugging their funds.
2. LN Hold Invoices: This is more trust-minimized. I "tweaked" the standard flow so that the sender chooses the preimage that unlocks the hold invoice (rather than the receiver/Mint). This ensures the Mint cannot possibly settle the invoice and rug the user.
The issue with the Hold Invoice approach is that, because the invoice never gets settled, routing nodes don't get compensated for the locked liquidity. So this likely requires upfront/holding fees for the routing nodes (no longer near-zero cost) or a direct channel from User to Mint.
That's the gist of my idea! I'm currently writing my Master's thesis on this, so I'm really looking for feedback from people actually dealing with these constraints in production. Since my applied crypto group at university doesn't focus heavily on Bitcoin, I've unfortunately had very limited input from experts in LN/cashu/nostr so far. I'd absolutely love any thoughts you have, or if you know anyone else who might be interested, that would be incredibly helpful.

2025-12-24 15:47:09 CET

- reply

Still would love to collaborate!

2025-06-13 20:05:07 CEST

- reply

Yeah that does in fact sound like a mistake 😂Canned 'Krombacher' from Aldi will always remind me of my days at university so it has a special place in my heart but there sure are much better beers out there

2025-06-13 18:59:21 CEST

- reply

Which one?

2025-06-12 20:28:04 CEST

- reply

Hope you don't mind me asking but shouldn't NUT-12 be mandatory, because without the DLEQ proofs a mint could theoretically tag every minted token with its own private key? As far as I understand it, this could then be used to recognise the tokens once they eventually get redeemed?
I could definitely be off, just trying to understand it better. Thanks for all the great work you do, very inspiring!