Nostr notes by Bugtus

Zaps in polls like this should be a proof-of-burn instead. Else ...

2026-03-26T20:33:14+01:00

In reply to nevent1q…tlks
_________________________

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

I’m glad you like it! I think a fidelity bond per npub is much ...

2026-02-15T18:23:34+01:00

In reply to nevent1q…02ys
_________________________

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 ThomasV (nprofile…6yx3)).

Could someone point me to a writeup where this is discussed in ...

2026-02-15T13:09:38+01:00

In reply to nevent1q…n2uv
_________________________

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"

> I think the only solution is to really make sure that ...

2026-02-13T00:26:11+01:00

In reply to nevent1q…8wls
_________________________

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

quoting
nevent1q…p4uy
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.

How about backing Nostr events (or pubkeys) with timelocked ...

2026-02-12T20:14:08+01:00

In reply to nevent1q…msy8
_________________________

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.

Ouch 🥲 @nprofile…tdlr

2026-02-12T02:27:09+01:00

Ouch 🥲 awayslice (nprofile…tdlr)

> insert plane_with_red_dots.jpg But yeah, I agree for the ...

2026-01-28T12:53:24+01:00

In reply to nevent1q…0tmd
_________________________

> insert plane_with_red_dots.jpg

But yeah, I agree for the most part

Though this sort of deterrence is likely better for ...

2026-01-16T21:46:43+01:00

In reply to nevent1q…lhgz
_________________________

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.

Something I’ve been thinking about lately: time-locked ...

2026-01-16T21:33:22+01:00

In reply to nevent1q…flcz
_________________________

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.

quoting
nevent1q…6js9
> 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.

Exactly. PoW inevitably penalizes mobile users while being ...

2026-01-15T14:31:17+01:00

In reply to nevent1q…nu40
_________________________

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:

quoting
nevent1q…zeea
> 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.

Rate limiting mechanism for nostr based on time locking sats.

2026-01-14T17:25:25+01:00

In reply to nevent1q…ct95
_________________________

Rate limiting mechanism for nostr based on time locking sats.

Actually, the more I think about it, the more edge cases come up ...

2026-01-14T14:20:25+01:00

In reply to nevent1q…qx3l
_________________________

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.

Certainly! That should probably cover 99% of cases, so it makes ...

2026-01-13T17:13:26+01:00

In reply to nevent1q…jt7v
_________________________

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.

Very cool! I'll read through it more thoroughly but seems ...

2026-01-13T16:51:26+01:00

In reply to nevent1q…zkn5
_________________________

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!

First off, thank you so much for the reply! I'm really happy ...

2026-01-13T16:24:01+01:00

In reply to nevent1q…cc0s
_________________________

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!

> So now, we base the rate limiting on the number of requests ...

2026-01-12T19:48:49+01:00

In reply to nevent1q…e4se
_________________________

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

> I'm curious to hear more about your approach. Gladly! As ...

2026-01-12T19:45:27+01:00

In reply to nevent1q…e4se
_________________________

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

"We've also replaced IP-based rate limiting for rank ...

2026-01-12T02:53:43+01:00

In reply to nevent1q…m9xg
_________________________

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

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

2026-01-11T13:30:36+01:00

In reply to nevent1q…27sn
_________________________

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

Privacy Pass for rate limiting (on nostr) is actually exactly ...

2026-01-08T19:50:29+01:00

In reply to nevent1q…2d2f
_________________________

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.

Very nice work! Though I do worry that having to burn sats for ...

2026-01-07T19:18:41+01:00

In reply to nevent1q…gpw7
_________________________

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!

"Don't think I like deliberately burning the money", ...

2026-01-07T18:48:28+01:00

In reply to nevent1q…2dfp
_________________________

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

"I can cryprographically prove that I'm human" Are ...

2026-01-07T17:47:36+01:00

In reply to nevent1q…k9xh
_________________________

"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 😅

"Time locked sats as sybil/spam protection" If this ...

2026-01-07T17:33:52+01:00

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

Just realized that for the 'Blank Check' approach to ...

2026-01-07T16:36:58+01:00

In reply to nevent1q…ys6z
_________________________

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

Oh yes, this is the attack I meant.

2026-01-06T22:07:26+01:00

In reply to nevent1q…nfm6
_________________________

Oh yes, this is the attack I meant.

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

2026-01-06T22:06:34+01:00

In reply to nevent1q…qwhe
_________________________

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

I don't think this is a problem. If Alice and the Mint ...

2026-01-06T22:00:42+01:00

In reply to nevent1q…09mp
_________________________

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!

Still would love to collaborate!

2025-12-24T15:47:09+01:00

In reply to nevent1q…27sn
_________________________

Still would love to collaborate!

Gotcha! Thanks.

2025-12-05T13:50:08+01:00

In reply to nevent1q…ajvf
_________________________

Gotcha! Thanks.

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

2025-12-05T13:04:34+01:00

In reply to nevent1q…rvn2
_________________________

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

@nprofile…deta bruh

2025-11-20T00:48:38+01:00

In reply to nevent1q…4w55
_________________________

hal (nprofile…deta) bruh

Although Bob is the mint

2025-11-20T00:43:02+01:00

In reply to nevent1q…gg4r
_________________________

Although Bob is the mint

Good bot 🫡

2025-11-20T00:40:33+01:00

In reply to nevent1q…fwrd
_________________________

Good bot 🫡

@nprofile…deta Why does Bob send hash(r1, r2, a, c') to ...

2025-11-20T00:32:45+01:00

In reply to nevent1q…dtyq
_________________________

hal (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?

Jesus the comments on there are depressing... I guess that's ...

2025-11-19T14:10:20+01:00

In reply to nevent1q…lc3l
_________________________

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!

Cashu tokens backed by a time lock of sats, not actual sats. ...

2025-11-17T17:48:20+01:00

Cashu tokens backed by a time lock of sats, not actual sats.

Maybe a useful spam deterrent 🤔

Too late haha ...

2025-09-10T13:30:50+02:00

In reply to nevent1q…nsw8
_________________________

Too late haha

Glad it made you laugh 🤓 Thanks for your work on Hashpool, ...

2025-06-13T23:37:54+02:00

In reply to nevent1q…4jse
_________________________

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

Yeah that does in fact sound like a mistake 😂Canned ...

2025-06-13T20:05:07+02:00

In reply to nevent1q…6nux
_________________________

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

Tell me about it... Writing my master thesis at the applied ...

2025-06-13T19:59:37+02:00

In reply to nevent1q…he39
_________________________

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 😅

Which one?

2025-06-13T18:59:21+02:00

In reply to nevent1q…4w2h
_________________________

Which one?

Hope you don't mind me asking but shouldn't NUT-12 be ...

2025-06-12T20:28:04+02:00

In reply to nevent1q…5df8
_________________________

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!

Wait, I missed that the PoL actually got implemented?? Just read ...

2025-06-12T00:11:42+02:00

In reply to nevent1q…k632
_________________________

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

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

2025-06-11T22:21:21+02:00

In reply to nevent1q…r4lk
_________________________

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

Making your own templates mining on Ocean and why that's so ...

2024-09-16T17:13:18+02:00

In reply to nevent1q…ka73
_________________________

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

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

2024-04-10T01:00:16+02:00

In reply to nevent1q…j2ns
_________________________

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

What thesis are you referring to?

2024-04-10T00:58:57+02:00

In reply to nevent1q…su93
_________________________

What thesis are you referring to?

Bomb throw...nice one!

2024-02-12T02:54:48+01:00

In reply to nevent1q…2gkp
_________________________

Bomb throw...nice one!

Sweet, thanks!

2024-02-12T02:51:31+01:00

In reply to nevent1q…07sa
_________________________

Sweet, thanks!

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

2023-11-11T02:29:11+01:00

In reply to nevent1q…dzr5
_________________________

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

Welcome back 🫂

2023-07-23T03:01:00+02:00

In reply to nevent1q…a6w3
_________________________

Welcome back 🫂

Nostr event nevent1qqsz524zp4tgccnfw2fkjfqxeqlsu48nwgcxtsynyywz3pzmfyc90pszyzryfrw764lw6s2wvzrxjg2hwg64ajqg2ksfczd8ecscp35fava6vrctenw

2023-07-18T18:14:56+02:00

Testing my Nostr Relay!

Test invoice ...

2023-03-04T01:52:50+01:00

Test invoice

lnbc210n1pjq99jjpp54aa9245x3hg464yavxqh2w0tmt05z09jghttump5lqrheeqs52dsdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5uhytc2uw32uz0a2r9gjea06l465tx27nycp0p6ydn7k33jrpsdpq9qyyssq4tu8h5cen0pedcyyh090f3v8nxsauus86g57ud4epddwq2rrugl3gnpf2690vntgavrqnkx9j6q7jm6zske4kh782v4awtwj3u79j0sp9gr94z

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

2023-02-26T21:27:20+01:00

In reply to nevent1q…cyt3
_________________________

I'm ready to pass the love forward 💜🧡

lnbc1m1p3lhsqnpp596q6geal9hqw2n3q03rzn0c3qq82kgak7pqrwkgcy5evlrdh20lqdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5stqcd33ydtl9zrv3qk9treq67n6v07207f0famf7e8tsrw76crkq9qyyssqns353ahjzg5v5t464xxfttqy6ygkxfaadjeljp8c9qrfe3le023z0zwkxp92906vrdqlqals3npekvl986zd5nvnvxta94wrnugcy9cq78g3tt

Just trying out Wallet of Satoshi so if anyone happens to see ...

2023-02-26T20:57:49+01:00

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

lnbc420n1p3lhwt0pp5gngefea40c3mh5srzqnlc2aedh2267hvcuthyvvggyfjlgfpmltsdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5c5hu93y0gz70plhsan6kcj0mjnfv57n5lnwu2yyd63ns0zsyxhgq9qyyssqsrtue2e0n4tu608e8ajwve3v98lwkj9m36gj8snfr0skexuzgp9j3tef8khvh9z7jwssx6fct5w625v4s80j25nkk28u9kerlv7wmssp7mr4cs