Bugtus

Public Key

npub1sezgmhk40mk5znnqse5jz4mjx40vszz45zwqnf7wyxqvdz0t8wnq9mnhp3

Profile Code

nprofile1qqsgv3ydmm2ham2pfesgv6fp2aer2hkgpp26p8qf5l8zrqxx384nhfspzpmhxue69uhkummnw3ezuamfdejsz9thwden5te0v35hgar09ec82c30wfjkccte4w25kw

Publishing to

nostr.wine

ditto.pub/relay

nostr.cizmar.net

nostr.einundzwanzig.space

nostr.notribe.net

relay.398ja.xyz

Author Public Key

npub1sezgmhk40mk5znnqse5jz4mjx40vszz45zwqnf7wyxqvdz0t8wnq9mnhp3

Show more details

Last Notes

2026-06-02 12:12:51 UTC

- reply

> If the burn sats went directly to the miner within the same block, i.e. they were burned by giving them away as miner fees, then there is an attack that any miner - large or small - can easily do
Oh yes, of course. It can't be the *same* block. I guess my initial reply made it sound like it could.
> If a mining pool has 40% of hashrate, they can announce a service where you give them 10 sats and they will "fake burn" 15 sats. They'll get 6 of those sats back
Right, that’s the case I was trying to think through.
Is the problem here mainly that the signal is inflated, rather than that the miner is strictly better off vs normal mining?
For example, with 40% hashrate:
+10 sats from user
-15 sats for the burn
0.4 * 15 = +6 sats recovered
-> +1 sat profit
So the user gets a 15-sat proof while only paying 10 sats and the miner still profits overall.
But if the user had instead done a normal 10 sat burn through some other notary, that same 40% miner would expect:
0.4 * 10 = +4 sats profit
So the miner seems worse off doing the "fake burn" service than just passively mining.
I definitely might be missing something here 😅 just trying to understand the attack.
> That's why a few of us have advocated from the start that it should be sent decades into the future, using CLTV
Yeah I definitely think that sending them decades into the future would be a really cool/interesting way to help with the security budget! Though Iirc Thomas mentioned some reason why he didn't opt for CLTV over CSV, I'll have to look into that again.

2026-06-01 13:14:31 UTC

- reply

Right, I remember you discussing this with Thomas on here a while back.
> Last time I checked, Thomas's implementation does the long-term lockup, but I'm not sure of the status of the paper.
I believe the current lockup is 144 blocks, so roughly one day. I'm not sure if that's exactly *long-term*.
> The reason we can't burn them by giving them *immediately* to today's miners is that the miner could simply advertize a notarization service that says "give me 10 sats and I'll do 'fake notarization' for 1 million sats" where the miner just pays fees to themselves
Am I understanding correctly, the idea here is that the malicious miner/notary controls so much of the hashrate that there's a very high chance it'll mine the 1M 'fake notarization' after the delay? Otherwise why would it risk burning 100,000x the sats only for a different miner to end up claiming the reward?
And you want to mitigate this by moving the timelock so far into the future that it becomes increasingly uncertain who will control the majority of hash at that point?
I definitely agree that timelocks far into the future make sense, if only for the reason that it helps with security budget. Though CSV is limited in how far into the future funds can be locked.

2026-05-26 17:15:38 UTC

- reply

Well, a proof-of-burn goes to the miners, at least that's what @nprofile…7976 proposes in his paper. So it's not permanent destruction of sats.
But it's still a much stronger signal than a regular zap, because no one miner is guaranteed to mine the next block.

2026-03-26 19:33:14 UTC

- reply

Zaps in polls like this should be a proof-of-burn instead. Else sybil zapping just makes this pointless, no? Still fun!

2026-02-15 17:23:34 UTC

- reply

I’m glad you like it!
I think a fidelity bond per npub is much better UX than a straight payment, since you eventually get your sats back while still providing similar Sybil resistance.
The idea gets even more powerful if the fidelity bond is on-chain, because then every relay can verify it, rather than only the relay that received a payment.
Of course, this doesn’t scale well if every individual user needs their own on-chain bond. But I think we could aggregate lots of small fidelity bonds into a single on-chain transaction that commits to the set of npubs and their respective bond amounts (see the Proof of Burn paper by @nprofile…6yx3).

2026-02-15 12:09:38 UTC

- reply

Could someone point me to a writeup where this is discussed in more detail? How do we deal with the cold start problem?
I think per npub fidelity bonds could help:
"I'm not willing to even process your posts, if you're not able to timelock X satoshis for your npub"

2026-02-12 23:26:11 UTC

- reply

> I think the only solution is to really make sure that today's miners don't see any value from the burning, so either notarizing to an OP_RETURN, or use CLTV to send it very far in the future
What do you think of this as a solution? I think it might address some of the perverse incentives of proof-of-burn, although it unfortunately loses the nice *security-budget* property.
#nevent1q…p4uy

2026-02-12 19:14:08 UTC

- 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-02-12 01:27:09 UTC

Ouch 🥲 @nprofile…tdlr

2026-01-16 20:46:43 UTC

- reply

Though this sort of deterrence is likely better for high-throughput, resource exhaustion abuse, where the attacker’s advantage comes from cheaply generating and coordinating large numbers of Nostr identities to consume relay resources and crowd out legitimate (especially new) users.

2026-01-16 20:33:22 UTC

- reply

Something I’ve been thinking about lately: time-locked liquidity as a spam deterrent.
If those 405 keys had to immobilize even a trivial amount of sats (e.g. 500 sats) for each of those 7M events, the spammer would likely hit a liquidity wall quickly. This could be done with a Privacy Pass like mechanism that makes the liquidity lock unlinkable to the individual events.
Legit users incur near-zero net cost (funds are returned after the lock), while attackers are forced to immobilize capital proportional to spam throughput. Relays could also surge lock amount under load.
Would absolutely love to hear your thoughts on whether "locked liquidity" could be a useful for spam deterrence.
#nevent1q…6js9

2026-01-15 13:31:17 UTC

- reply

Exactly. PoW inevitably penalizes mobile users while being trivial for spammers with specialized hardware.
That's in part why I'm working on a solution that uses time-locked liquidity as the scarce resource instead of hash power.
The thesis is that the ratio of Spammer Liquidity vs. User Liquidity is much more favorable for defense than Spammer Hash vs. User Hash. I would absolutely love to get your thoughts on this. Thank you for the great work you do on Amethyst!
I explained the mechanism in a bit more detail in this thread:
#nevent1q…zeea

2026-01-14 16:25:25 UTC

- reply

Rate limiting mechanism for nostr based on time locking sats.

2026-01-14 13:20:25 UTC

- reply

Actually, the more I think about it, the more edge cases come up with reusing the same token across multiple relays. At this point, I think it makes the most sense to treat tokens as single-use per relay. If a user wants to send the same event to multiple relays, they need multiple tokens.

2026-01-13 16:13:26 UTC

- reply

Certainly! That should probably cover 99% of cases, so it makes perfect sense to prioritize stability over prioritization logic for now.
Thanks for walking me through how you deal with spam. It’s really helpful to have these real world examples to compare against my theoretical work.

2026-01-13 15:51:26 UTC

- reply

Very cool! I'll read through it more thoroughly but seems like the concept (using Cashu Mints for access tokens) is adjacent to what I had in mind, minus the sat time-locking part. Thanks for chiming in!

2026-01-13 15:24:01 UTC

- 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 18:48:49 UTC

- reply

> So now, we base the rate limiting on the number of requests per second that the relay can send to the rank provider. It's simpler, more effective, and users are not penalized for being behind an IP group
Nice, this should definitely make UX much better for VPN users!
I am curious though, if you hit that rate limit (say, during a spam wave), how does the relay decide which requests to prioritize? It seems like a spammer could still "crowd out" legitimate requests by jamming the queue. That is one of the key problems I'm targeting: giving the relay a way to distinguish and prioritize higher "bonded" traffic over cheap spam when resources are scarce.

2026-01-12 18:45:27 UTC

- 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.

2026-01-12 01:53:43 UTC

- reply

"We've also replaced IP-based rate limiting for rank lookups with an approach that no longer penalizes users behind VPNs, and improved response handling to be more robust under real-world conditions."
Very curious about how this works. Mind sharing more?
I'm also working on a rate limiting mechanism for nostr where users have to time lock sats in order to make requests (based on Privacy Pass). It's for my master thesis, so I'd love to compare it to whatever you're using. Thanks!

2026-01-11 12:30:36 UTC

- reply

Apologies for sending the unsolicited pdf, if that was the issue.

2026-01-08 18:50:29 UTC

- reply

Privacy Pass for rate limiting (on nostr) is actually exactly what I'm working on in my master's thesis. Thanks for the words of encouragement some months back, btw!
While I find Thomas Voegtlin's Proof-of-Burn proposal interesting, I worry that burning sats for every event creates too high of a UX hurdle for widespread adoption.
My idea was that instead of burning sats, Clients have to time lock them in order to receive Privacy Pass tokens. A legit user incurs near-zero costs for normal usage, whereas spammers must immobilize capital proportional to the number of events they want to sustain, capping their throughput based on their available liquidity.
I would love to share more with you if you have the time. I'd really value feedback from people deep into this stuff, as my university lab focuses less on Bitcoin specifically.

2026-01-07 18:18:41 UTC

- reply

Very nice work!
Though I do worry that having to burn sats for every event will be too big of a UX hurdle to gain widespread adoption.
That's why I've been working on a spam deterrent where users have to time lock sats instead of actually having to spend them. A legit user incurs near-zero costs, whereas attackers must immobilize capital proportional to the number and lifetime of identities they maintain. If you, or anyone reading this, is interested, check out my latest post. I'd love feedback from the community!
Still, proof-of-burn is very interesting and might be needed as the ultimate deterrent at some point. Thanks for writing the paper!

2026-01-07 17:48:28 UTC

- reply

"Don't think I like deliberately burning the money", "Maybe better, but still makes messages mostly for the rich?"
100% agreed. That's why I'm trying to create a spam deterrent that works by time locking sats, not actually spending then. While proof-of-burn is really interesting and would definitely be a strong deterrent, I do worry the UX hurdle of having to spend sats for every little action might be too high to gain widespread adoption.
If you, or anyone reading this, is interested, check out my latest post. I'm desperately looking for feedback from the community!

2026-01-07 16:47:36 UTC

- reply

"I can cryprographically prove that I'm human"
Are you talking about WoT here? Would love to know!
I'm trying to tackle the problem of bots being everywhere while legit users still have to deal with annoying counter measures (e.g. CAPTCHAS) in my master's thesis. The idea is to time lock sats to get tokens that can then be spend to access web resources. A legit user incurs near-zero costs, whereas attackers must immobilize capital proportional to the number and lifetime of identities they maintain.
See my latest post if anyone's interested. I'm desperately looking for feedback from the community 😅

2026-01-07 16:33:52 UTC

"Time locked sats as sybil/spam protection"
If this sounds interesting to anyone, I'd love to share the whole draft with you. I'm desperately looking for feedback! 😅
https://blossom.primal.net/11c331f1da57dd2664ba0612c5a38801666ca737a5d568e7e3e3c398f0baad3c.jpg

2026-01-07 15:36:58 UTC

- reply

Just realized that for the 'Blank Check' approach to work, we have to make sure that only a single party has access to a specific set of blank checks.
Otherwise, we run the risk that a check gets used twice but Carol can only redeem it once.
If we have to restrict access to the checks, that probably defeats the original purpose: 'An offline receiver could publish their public key and the online sender can prepare a suitable BlindSignature from the mint.'

2026-01-06 21:07:26 UTC

- reply

Oh yes, this is the attack I meant.

2026-01-06 21:06:34 UTC

- reply

"She can *spend* it later when she is back online" not "unblind".

2026-01-06 21:00:42 UTC

- reply

I don't think *this* is a problem. If Alice and the Mint collude they can always unblind C_, so this isn't really a downgrade from standard cashu.
However, there is an attack where Alice just lets the Mint sign Y twice. Once with Carol's public key B_ = Y + r * F and once the standard way with B_' = Y + rG.
Now, (x, r_, C_, DLEQ) looks like a valid token to Carol even when offline. However if Alice spends her token before Carol, Carol's token will get denied because the secret x is already in the Mint's spent set.
An idea to fix this:
1. Carol generates a bunch of secrets x, blinds them (B=Y+rG), and publishes these "Blank Checks" (B_'s) somewhere. She can then go offline.
2. Alice grabs a B_, pays the Mint to sign it (C_), and sends it to Carol. Alice cannot have Y signed twice (like in the prior attack) because she doesn't know x.
3. Carol receives C_ and the DLEQ proof. She verifies the proof against her original blank checks and the Mint's public key. If one of them passes, she has cryptographic proof that C_ is the valid signature for her specific B_. Since only she holds the secret x, she knows the token is safe and unspent. She can unblind it later when she is back online.
Not sure if I'm making any mistakes or the first step defies the purpose you want to use this for. I'm pretty new to all of this myself. Would love to hear what you think!

2025-12-24 14:47:09 UTC

- reply

Still would love to collaborate!

2025-12-05 12:50:08 UTC

- reply

Gotcha! Thanks.

2025-12-05 12:04:34 UTC

- reply

pos as in proof of stake? Where can I read more about this?

2025-11-19 23:48:38 UTC

- reply

@nprofile…deta bruh

2025-11-19 23:43:02 UTC

- reply

Although Bob is the mint

2025-11-19 23:40:33 UTC

- reply

Good bot 🫡

2025-11-19 23:32:45 UTC

- reply

@nprofile…deta Why does Bob send hash(r1, r2, a, c') to Alice in the first place? Afterall, can't Bob just send r1 and r2 to Alice, Alice challenges him by sending back a random number e and Bob sends back s = r + e*a. Wouldn't that also prove that he used the same private key for the signature and his pubkey?

2025-11-19 13:10:20 UTC

- reply

Jesus the comments on there are depressing... I guess that's what happens when you cater to the anti AI crowd. A lot of the comments sure sound bott-y though.
Hope the vibe will shift eventually, genuinly would love to see the app succeed!

2025-11-17 16:48:20 UTC

Cashu tokens backed by a time lock of sats, not actual sats.
Maybe a useful spam deterrent 🤔

2025-08-07 22:59:03 UTC

- reply

Always thought we'd know when Elon's built a positions once Bitcoiners are on Lex Friedman again. Guess this confirms it.

2025-06-13 21:37:54 UTC

- reply

Glad it made you laugh 🤓 Thanks for your work on Hashpool, looks really cool!

2025-06-13 18:05:07 UTC

- 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 17:59:37 UTC

- reply

Tell me about it... Writing my master thesis at the applied cryptography lab just because I really enjoy btc/LN/cashu might not be the way to go 😅

2025-06-13 16:59:21 UTC

- reply

Which one?

2025-06-12 18:28:04 UTC

- 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!

2025-06-11 22:11:42 UTC

- reply

Wait, I missed that the PoL actually got implemented?? Just read through the github gist recently when I stumbled upon the StarkNut idea.

2025-06-11 20:21:21 UTC

- reply

Amazing! This is thanks to NUT-12, correct?

2024-09-16 15:13:18 UTC

- reply

Making your own templates mining on Ocean and why that's so signifact! Love the videos and podcast appearances btw

2024-04-09 23:00:16 UTC

- reply

This? https://dspace.mit.edu/handle/1721.1/14871

2024-04-09 22:58:57 UTC

- reply

What thesis are you referring to?

2024-02-12 01:54:48 UTC

- reply

Bomb throw...nice one!

2024-02-12 01:51:31 UTC

- reply

Sweet, thanks!

2023-11-11 01:29:11 UTC

- reply

What app (I assume) did you use for translating the conversation?

2023-07-23 01:01:00 UTC

- reply

Welcome back 🫂

2023-07-18 16:14:56 UTC

Testing my Nostr Relay!

2023-03-04 00:52:50 UTC

Test invoice
lnbc210n1pjq99jjpp54aa9245x3hg464yavxqh2w0tmt05z09jghttump5lqrheeqs52dsdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5uhytc2uw32uz0a2r9gjea06l465tx27nycp0p6ydn7k33jrpsdpq9qyyssq4tu8h5cen0pedcyyh090f3v8nxsauus86g57ud4epddwq2rrugl3gnpf2690vntgavrqnkx9j6q7jm6zske4kh782v4awtwj3u79j0sp9gr94z

2023-02-26 20:27:20 UTC

- reply

I'm ready to pass the love forward 💜🧡
lnbc1m1p3lhsqnpp596q6geal9hqw2n3q03rzn0c3qq82kgak7pqrwkgcy5evlrdh20lqdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5stqcd33ydtl9zrv3qk9treq67n6v07207f0famf7e8tsrw76crkq9qyyssqns353ahjzg5v5t464xxfttqy6ygkxfaadjeljp8c9qrfe3le023z0zwkxp92906vrdqlqals3npekvl986zd5nvnvxta94wrnugcy9cq78g3tt

2023-02-26 19:57:49 UTC

Just trying out Wallet of Satoshi so if anyone happens to see this, I'd really appreciate it 🧡
lnbc420n1p3lhwt0pp5gngefea40c3mh5srzqnlc2aedh2267hvcuthyvvggyfjlgfpmltsdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5c5hu93y0gz70plhsan6kcj0mjnfv57n5lnwu2yyd63ns0zsyxhgq9qyyssqsrtue2e0n4tu608e8ajwve3v98lwkj9m36gj8snfr0skexuzgp9j3tef8khvh9z7jwssx6fct5w625v4s80j25nkk28u9kerlv7wmssp7mr4cs

2023-01-25 02:00:11 UTC

Liking this a lot so far #[0]

2023-01-24 01:09:42 UTC

- reply

Thanks for linking me to nostr-resources.com
Danke dir!

2023-01-24 01:02:17 UTC

- reply

Your tweet made me aware of Amethyst. Excited to finally try out nostr. Thank you!