Cashu Ecash Reaction

[wcat7]

I propose adding Cashu ecash reaction to NIP25.

With ecash reaction, you can directly send Cashu ecash token to achieve a similar effect as Zap, and it's even simpler than Zap.

a) You don't need to set up a Lightning address. b) You don't need a complex Zap flow. c) And you don't rely on Lightning wallets to send Receipt events.

Any thoughts?

Cashu Ecash Reaction

The client may also specify a Cashu Ecash token cashu*** in the reaction content. This Ecash token should utilize P2PK (NUT-11) and lock the token to the pubkey associated with the event being reacted to. Upon receiving the reaction content, the client is required to validate the DLEQ proof (NUT-12).

{
  "kind": 7,
  "content": "cashuAeyJ0b2tlbiI6W3sibWludCI6Imh0dHBzOi8vODMzMy5zcGFjZTozMzM4IiwicHJvb2ZzIjpbeyJhbW91bnQiOjIsImlkIjoiMDA5YTFmMjkzMjUzZTQxZSIsInNlY3JldCI6IjQwNzkxNWJjMjEyYmU2MWE3N2UzZTZkMmFlYjRjNzI3OTgwYmRhNTFjZDA2YTZhZmMyOWUyODYxNzY4YTc4MzciLCJDIjoiMDJiYzkwOTc5OTdkODFhZmIyY2M3MzQ2YjVlNDM0NWE5MzQ2YmQyYTUwNmViNzk1ODU5OGE3MmYwY2Y4NTE2M2VhIn0seyJhbW91bnQiOjgsImlkIjoiMDA5YTFmMjkzMjUzZTQxZSIsInNlY3JldCI6ImZlMTUxMDkzMTRlNjFkNzc1NmIwZjhlZTBmMjNhNjI0YWNhYTNmNGUwNDJmNjE0MzNjNzI4YzcwNTdiOTMxYmUiLCJDIjoiMDI5ZThlNTA1MGI4OTBhN2Q2YzA5NjhkYjE2YmMxZDVkNWZhMDQwZWExZGUyODRmNmVjNjlkNjEyOTlmNjcxMDU5In1dfV0sInVuaXQiOiJzYXQiLCJtZW1vIjoiVGhhbmsgeW91LiJ9",
  "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
  "created_at": 1682790000
}

[callebtc]

How about posting the actual Proof's instead of serializing the tokens? The token serialization is meant for human interfaces (copy pasting, QR codes etc), machines don't need that. It would also be unaffected by new serialization formats in the future.

Thank you for mentioning the DLEQ proofs, as it would be required for others to check the authenticity of the signature (specifically this part: Carol verifies DLEQ).

NIP25 reactions can also include the pubkey p of the recipient of the reaction and e of the event that it reacts to.

[wcat7]

Yes, reactions will include p and e tags. The example above just simplifies the event format :)

I place the serialized token into the content, as it can be identified as a cashu ecash reaction by matching the string header "cashu". If it's a Proof, it will be a JSON string without any identifier, which would be more suitable for a separate tag imo.

[thesimplekid]

How about posting the actual Proof's instead of serializing the tokens? The token serialization is meant for human interfaces (copy pasting, QR codes etc), machines don't need that. It would also be unaffected by new serialization formats in the future.

Proofs don't include the mint_url so that would need to be included as well.

One thing to note is there is nothing to stop someone from posting the same post to multiple events. If the event id is in the tag of the NUT-10 secret that can be verified and clients can hide tokens that don't include the event id and can be attached to multiple events.

[callebtc]

Proofs don't include the mint_url so that would need to be included as well.

good point, same for unit.

If the event id is in the tag of the NUT-10 secret that can be verified

Also very good point, it would require slightly different locking scripts that commit to the event ID but don't change the unlocking part (using the nonce field for example).

[vitorpamplona]

We can do a new kind with the public and private parts:

1. The public needs to know how to verify that the user did receive the amount or that the amount is available for that user and no one else.
2. The private part is for the receiver to claim the token.

[callebtc]

We can do a new kind with the public and private parts:

The nice thing is that both parts are one:

• Alice locks 10 sats of ecash to Carol's npub and (in the ecash token), commits to the note ID.
• Alice somehow attaches the token to the note (reaction, or different type), together with DLEQ proofs
• Dave (public) sees "Alice paid Carol 10 sats, zapped note ID, and DLEQ is valid" and shows "10 sats" in UI

[wcat7]

• Dave (public) sees "Alice paid Carol 10 sats, zapped note ID, and DLEQ is valid" and shows "10 sats" in UI

Is there a way for Dave to know if the ecash is from Alice?

[callebtc]

Is there a way for Dave to know if the ecash is from Alice?

The zap event is signed by Alice. Also, Alice can provide a refund pubkey of hers for the case if Carol never redeems the ecash. But I wouldn't make this a requirement.

[wcat7]

Is there a way for Dave to know if the ecash is from Alice?

The zap event is signed by Alice. Also, Alice can provide a refund pubkey of hers for the case if Carol never redeems the ecash. But I wouldn't make this a requirement.

Since it is public, Dave might can also take the token and zap it to Carol? Can we identify the sender using the refund pubkey?

[Egge21M]

I like the idea, but not this way. Reactions are not Zaps. This mixes two very different things and separation of concerns is difficult