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!