Nostr Broadcast (or a better name TBD)

[lollerfirst]

This NUT aims to address this privacy concern when wallets check for token melt status, while also possibly facilitating future implementations of the famously proposed PoL scheme by calle. This is because the mint is effectively building a Proof of Liabilities attestation (or report) composed by all the nostr notes containing all of the secrets/blinded signatures.

[davidcaseria]

We should note how the pubkey field is a compressed public key and how Nostr public keys are x-only.

Also, this is unrelated to this NUT, but I assumed the pubkey field was for the LN node ID, but maybe that's not the case.

[lollerfirst]

We should note how the pubkey field is a compressed public key and how Nostr public keys are x-only

True.

Also, this is unrelated to this NUT, but I assumed the pubkey field was for the LN node ID, but maybe that's not the case.

It would make sense if it could be specified as an env setting. In Nutshell it's derived from the seed. I am not sure of this but i believe you are required to have a seed because a bunch of other things depend on it.

[lollerfirst]

I am thinking we should probably add another event case for letting the Mint (or Mint operator, manually) publish the signed outstanding balance for that particular epoch, to be consistent with the PoL scheme (see the example picture i've included)

[davidcaseria]

With the current event structure, a client must query for all the mint events since sending the token, decode the contents, and check when it is claimed. This may be an overwhelming number of events for the client to process for a large mint or token that has not been claimed for a while. Can the event be structured to be partially filtered on the relay
while not leaking privacy?

[lollerfirst]

@davidcaseria

While not leaking privacy

If they are filtered on the relay, and there is cooperation between the relay and the Mint (or they are operated by the same entity) then you are back to square one. The idea here is the wallet should not communicate x or Y to anybody else other than the receiver of the token.

What we COULD do is have the client request a relay the Bloom filter for a particular mint and epoch, where all the burnt secrets have been inserted. The relay calculates (or has it cached) the Bloom filter, as they have all the necessary information. Then they send it to the client.

Then looking for spent secrets in the Bloom filter is much easier for the client if there have been many BURN events since the timestamp of sending.

[lollerfirst]

TO BE CLEAR:
The Mint BATCHES the MINT and BURN events to be broadcast.
I thought it was obvious from the wording of "regularly" updates but apparently it's not.
We don't want to publish events on every client request the Mint processes.

[lollerfirst]

I have opened a PR for the NIP: nostr-protocol/nips#1526

[AngusP]

I don't think I agree conceptually with using a stream of Nostr events for this use -- you're right that "when the recipient attempts to claim the e-cash, they will reveal the same Y to the Mint, allowing it to potentially associate that token with both the sender's and recipient's identity"; However, adding a dependency on Nostr and streaming many notes for spends is a lot of overhead (and data) to address the problem.

When a sender transfers e-cash to a recipient, they need to confirm that the recipient has claimed the payment in order to safely mark the proof in their wallet as SPENT.

This is of-course true, but I don't think it's an immediate concern -- it's OK if a token is in some PROBABLY_SPENT state for some-time™, as we only want to claw it back if the recipient never actually spent it. So we can check later in the next day or week and assume the payment 'failed' if the recipient hasn't spent it. Additionally, there's an open question of "how long should I wait for a recipient to claim a token before I take it back" as a legitimate recovery for a failed payment rather than basically stealing from someone who thinks you've paid them and was going to claim the token but hasn't yet, especially in a offline/poor-connectivity use-case. Ideally a recipient doesn't give you the stuff you're paying for before they've claimed the token, but ideally isn't guaranteed -- best real-world argument I can give for this is that merchants do this all the time with fiat payment cards.

If we expect that for some payments the recipient may claim hours after we sent them a token, then with Nostr events being published every ~5 seconds by the mint, that's also a lot of events and network requests a wallet may need to chew through to check if the recipient claimed.

That being the case, then a simple solution like the mint publishing a daily spend bloom filter (or similar construct) for all the tokens spent on a given day would allow the wallet to check for a spend without revealing to the mint which Y in-particular it's interested in (Bloom filters can have false-positives so we'd have to handle that edge-case). Or even better, if the mint publishes a Proof of Liabilities daily, then you know the token is unspent by the recipient if there's a proof in the PoL for it, and is spent if there is not. I like how this also 'forces' PoL to be implemented and checked frequently by wallets, because it gives them an incentive to do so other than to check if they might be getting rugged 🤣.

Lastly, it's also 'kinda nice' that there isn't necessarily a public record of "when what token got spent" -- obviously the sender, recipient and mint could know, but otherwise it's private. If the mint publishes events to Nostr, then that's no-longer the case?

[lollerfirst]

If the mint publishes events to Nostr, then that's no-longer the case?

The information published only makes sense to the sender and receiver. Others can only see "some" token of "some" amount has been spent.

But to be quite honest I don't believe this is a good idea anymore.