NUT-XX: Payment Requests #124
Conversation
xx.md
Outdated
| ```go | ||
| type PaymentRequest struct { | ||
| A int `amount (optional)` | ||
| U string `unit` |
There was a problem hiding this comment.
Can the unit also be optional and default to sats?
There was a problem hiding this comment.
I was thinking that as well, however I can receivers run into compatibility issues quickly if they let users choose the unit.
xx.md
Outdated
| - unit: The unit of the requested token (e.g. sats) | ||
| - mint: The mint to use to mint the token | ||
| - description: A human readable discription that the sending wallet will display after scanning the request | ||
| - transport: The method of transport chosen to transmit the created token to the sender (can be multiple, sorted by preference) |
There was a problem hiding this comment.
Is there a use case where transport is empty? Or should there be a minimum of one element in the list?
|
What do you think of an optional condition that could specify spending conditions. For example if the receiver wants it locked using P2PK? |
Yes, this should be included. I will add it later doday |
Very cool. The receiver could specify the Edit: maybe even better: Edit 2: Problem: it would require one |
I added |
| "r": str <optional>, | ||
| "d": str <optional>, | ||
| "m": str <optional>, | ||
| "l": str <optional>, |
There was a problem hiding this comment.
What is the format of the lock script?
There was a problem hiding this comment.
I was thinking to just make it the well known secret format. Basically what will become Proof.secret.
However thinking about it, that will not work because of the nonce. Do you have something in mind? Otherwise we just have to come up with another Type
There was a problem hiding this comment.
Maybe just the well known secret without a nonce and the sender can add the nonce?
xx.md
Outdated
| _Example_ | ||
|
|
||
| ```sh | ||
| cashrqAaVhQRVhVWNzYXRhTXgiaHR0cHM6Ly9taW50Lm1pbmliaXRzLmNhc2gvQml0Y29pbmFEeCNQbGVzYXNlIHBheSB0aGUgdmVyeSBmaXJzdCBjYXNodSBwcmFUgaJhVGVub3N0cmJUYXhGbnByb2ZpbGUxcXFzZG11cDZlMno2bWNwZXVlNno2a2wwOGhlNDloY2VuNXhucmMzdG5wdncwbWRndGplbWgwc3V4YTBrag |
There was a problem hiding this comment.
should this be a cashureq prefix?
can we add a version byte like with keysets? It would be good to add a paragraph explaining the payment request serialization like with tokenv3:
cashureq[version][request object]
There was a problem hiding this comment.
Maybe it'd be better to use a prefix that doesn't look so visually similar to a token: creq?
There was a problem hiding this comment.
Yes, good point. The first byte after the prefix is indeed a version byte. I'll update the text to be more clear about that
There was a problem hiding this comment.
I have added a slightly different notation that makes it clear what exactly is concatianated and encoded when. Let me know what you think
Cashu transactions are initiated by the sender and can be pushed to the receiver without any additional help. However for many use cases requesting a payment may be more desirable (e.g. point-of-sales). This proposal introduces a standardised format for payment requests, that supply a sending wallet with all information necessary to complete the transaction.