Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NUT-18: Payment Requests #124

Merged
merged 27 commits into from
Oct 18, 2024
Merged
Changes from 5 commits
Commits
Show all changes
27 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 81 additions & 0 deletions xx.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# NUT-XX: Payment Requests

`optional`

---

This NUT introduces a standardised format for payment requests, that supply a sending wallet with all information necessary to complete the transaction. This enables many use-cases where a transaction is better initiated by the receiver (e.g. point of sale).

## Flow

1. Receiver creates a payment request, encodes it and displays it to the sender
2. Sender scans the request and constructs a matching token
3. Sender sends the token according to the transport specified in the payment request
4. Receiver receives the token and finalises the transaction

## Payment Request

A Payment Request is defined as follows

```json
{
"a": int <optional>,
"u": str,
"r": str <optional>,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should more than 1 mint be allowed?

"d": str <optional>,
"m": str <optional>,
"l": str <optional>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the format of the lock script?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just the well known secret without a nonce and the sender can add the nonce?

"t": Transport
}
thesimplekid marked this conversation as resolved.
Show resolved Hide resolved
```

while Transport is defined as

- a: The amount of the requested token (payment amount)
- u: The unit of the requested token (e.g. sats)
- r: The mint to use to mint the token
- d: A human readable description that the sending wallet will display after scanning the request
- m: The memo of the requested token (can be used for accounting purposes)
- l: The lock script of the requested token
- t: The method of transport chosen to transmit the created token to the sender (can be multiple, sorted by preference)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having multiple transports and letting the user choose which one they prefer makes sense to me. The json example you provided does not allow providing multiple transports. I think it should be an array of Transport

"t": <Array[Transport]>


The sending wallet MUST honor all parts of a payment request that are specified

## Transport

Transport is an important part of Cashu Payment Requests. Receivers can choose what kind of transport they want to support and where they want to receive the token. By making this clear in the payment requests, wallets can handle payment requests accordingly (or decline them if they do not support the transport layer). A transport consists of a type and a target.

```json
{
"t": str,
"ta": Target
Egge21M marked this conversation as resolved.
Show resolved Hide resolved
}
```
thesimplekid marked this conversation as resolved.
Show resolved Hide resolved

- t: type of Transport
- ta: target of Transport
Egge21M marked this conversation as resolved.
Show resolved Hide resolved

There can be many transport layers, but here are some recommendations:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to have a specific list of transport-types cashu supports in general instead of allowing everything. This list can be upgraded in the future without breaking the api. Otherwise a receiver could just add a new transport-type the wallet does not know how to handle.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That wouldn't be an issue though. If the PR does not include a transport that the wallet can handle, the wallet can not pay it and will let the user know.

I think we should curate a list of recommended / common transports though.


- nostr
- type: "nostr"
- target: `{nprofile: "nprofile..."}`
- post
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the transport-type post? Do you mean http with the method post? If so I would prefer the term http as the transport-type. Post could be misinterpreted as snailmail

- type: "post"
- target: `{url: "<endpoint url>"}`
- email
- type: "email"
- target: `{email: "<email adddress>"}`
- sms
- type: "sms"
- target: `{num: "phone number"}`

## Encoded Request

Cashu Payment Requests can be encoded and displayed/sent as string or qr code. They underlying object is serialised using CBOR and finally base64 encoded and prefixed with a version byte and standard prefix.

_Example_

```sh
cashrqAaVhQRVhVWNzYXRhTXgiaHR0cHM6Ly9taW50Lm1pbmliaXRzLmNhc2gvQml0Y29pbmFEeCNQbGVzYXNlIHBheSB0aGUgdmVyeSBmaXJzdCBjYXNodSBwcmFUgaJhVGVub3N0cmJUYXhGbnByb2ZpbGUxcXFzZG11cDZlMno2bWNwZXVlNno2a2wwOGhlNDloY2VuNXhucmMzdG5wdncwbWRndGplbWgwc3V4YTBrag
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it'd be better to use a prefix that doesn't look so visually similar to a token: creq?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a slightly different notation that makes it clear what exactly is concatianated and encoded when. Let me know what you think

```