NUT-18: Payment Requests #124

Egge21M · 2024-05-26T05:27:18Z

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.

xx.md

davidcaseria · 2024-05-26T11:07:42Z

xx.md

+```go
+type PaymentRequest struct {
+  A int         `amount (optional)`
+  U string      `unit`


Can the unit also be optional and default to sats?

I was thinking that as well, however I can receivers run into compatibility issues quickly if they let users choose the unit.

davidcaseria · 2024-05-26T11:09:07Z

xx.md

+- 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)


Is there a use case where transport is empty? Or should there be a minimum of one element in the list?

thesimplekid · 2024-05-26T11:40:34Z

What do you think of an optional condition that could specify spending conditions. For example if the receiver wants it locked using P2PK?

Egge21M · 2024-05-26T12:25:51Z

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

callebtc · 2024-05-27T08:16:19Z

What do you think of an optional condition that could specify spending conditions. For example if the receiver wants it locked using P2PK?

Very cool. The receiver could specify the secret as well.

Edit: maybe even better: Y – the sender doesn't need to know the secret.

Edit 2: Problem: it would require one Y per proof you expect, which is not likely to be known upfront in most cases.

Egge21M · 2024-05-27T08:41:58Z

Very cool. The receiver could specify the secret as well.

I added l for specifying a locking script. However specifying secret / Y is overkill I believe. It's nice to have, but introduces a lot of complexity and will bloat the request size quite a bit too.

xx.md

thesimplekid · 2024-05-27T09:53:46Z

xx.md

+  "r": str <optional>,
+  "d": str <optional>,
+  "m": str <optional>,
+  "l": str <optional>,


What is the format of the lock script?

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

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

callebtc · 2024-05-31T12:26:27Z

xx.md

+_Example_
+
+```sh
+cashrqAaVhQRVhVWNzYXRhTXgiaHR0cHM6Ly9taW50Lm1pbmliaXRzLmNhc2gvQml0Y29pbmFEeCNQbGVzYXNlIHBheSB0aGUgdmVyeSBmaXJzdCBjYXNodSBwcmFUgaJhVGVub3N0cmJUYXhGbnByb2ZpbGUxcXFzZG11cDZlMno2bWNwZXVlNno2a2wwOGhlNDloY2VuNXhucmMzdG5wdncwbWRndGplbWgwc3V4YTBrag


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]

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

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

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

xx.md

ngutech21 · 2024-09-10T11:35:10Z

xx.md

+- 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)


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]>

ngutech21 · 2024-09-10T11:39:01Z

xx.md

+- t: type of Transport
+- a: target of Transport
+
+There can be many transport layers, but here are some recommendations:


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.

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.

ngutech21 · 2024-09-10T11:40:48Z

xx.md

+- nostr
+  - type: "nostr"
+  - target: "<nprofile...>"
+- post


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

ngutech21 · 2024-09-10T11:47:28Z

Does this nut provide any information through the info-endpoint other than the supported-flag?
It could make sense to provide the supported currencies and min/max amounts like we do in nut-4 and nut-5. Or is this nut using the same values as nut-5?

prusnak · 2024-09-10T11:52:38Z

xx.md

+Regardless of the transport layer the payload should always (unless specified differently) be a JSON serialised object as follows:
+
+```json
+{ "token": "cashuAy..." }


Why not just the plaintext?

Sending JSON makes sense only for HTTP but for all other transports (e.g. SMS or E-mail) it is awkward.

I agree. I thought it would be good to define a reasonable standard that could work in any transport.

I an definitely open for suggestions

I favor removing this requirement and allowing the plaintext encoded token to be used.

I think it's better to use a structured object because:

We will break things once we decide to add stuff later

There is a new payment id field that the requester can ask for in the payment payload.

davidcaseria · 2024-10-09T19:04:32Z

xx.md

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


Should more than 1 mint be allowed?

davidcaseria · 2024-10-09T19:06:25Z

xx.md

+
+- nostr
+  - type: "nostr"
+  - target: "<nprofile...>"


Should the nostr transport follow NIP-61?

davidcaseria · 2024-10-09T19:08:37Z

xx.md

+Regardless of the transport layer the payload should always (unless specified differently) be a JSON serialised object as follows:
+
+```json
+{ "token": "cashuAy..." }


I favor removing this requirement and allowing the plaintext encoded token to be used.

davidcaseria · 2024-10-09T19:12:43Z

xx.md

+
+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.
+
+`"creq" + base64(versionByte + cbor(PaymentRequest))`


I don't have a strong opinion, but should we consider keeping the cashu prefix and using the version byte to differentiate a token and a payment request?

Also, NUT-00 doesn't encode the version byte in the base64; it is included in the prefix. We should keep the spec consistent with this treatment.

Egge21M · 2024-10-15T16:59:39Z

@callebtc thanks for adding the suggestions. This does indeed LGTM!

davidcaseria · 2024-10-15T20:39:56Z

xx.md

+- `i`: Payment id to be included in the payment payload
+- `a`: The amount of the requested payment
+- `u`: The unit of the requested payment (MUST be set if `a` is set)
+- `s`: Whether the payment request is for single use


Should be r to match above

davidcaseria · 2024-10-15T20:42:45Z

xx.md

+
+## Payment payload
+
+Regardless of the transport layer, the payload sent to the receiver is a JSON serialized object as follows:


How would this work with NIP-61, where the nostr event is the payment, which has its own format and should be signed by the sender?

Egge21M · 2024-10-17T20:24:43Z

Are we ready to remove NIP-04, because the support for NIP-17 might be too limited still. Afaik nostr-tools does not have it yet.

But I agree that we probably should be looking forward and not carry stuff around that's already considered harmful

callebtc

LGTM

18.md

ok300 · 2024-10-18T15:25:13Z

18.md

+
+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


IMO it would be helpful to indicate in the Flow at which point user interaction or confirmation is needed (from the payer side), and if there is anything the app must / should show to the user before confirmation, similar to LNURL-pay / LNURL-withdraw.

18.md

ok300 · 2024-10-18T15:31:39Z

18.md

+
+### Transport types
+
+The supported transport types are:


Which are the transport types? Looks like a list was intended here, but missing.

Co-authored-by: ok300 <[email protected]>

prusnak · 2024-10-18T17:52:57Z

typo fix in #178

Egge21M added 2 commits May 26, 2024 07:25

added v1 draft

b7b0781

updated reference implementation

b12b4ee

callebtc reviewed May 26, 2024

View reviewed changes

xx.md Outdated Show resolved Hide resolved

davidcaseria reviewed May 26, 2024

View reviewed changes

Egge21M added 2 commits May 26, 2024 22:40

updated referece Impl. + began formatting

9021c09

formatting

0e9b53d

Egge21M marked this pull request as ready for review May 27, 2024 05:00

fixed typo & removed ref impl

80e6d6f

thesimplekid reviewed May 27, 2024

View reviewed changes

callebtc reviewed May 31, 2024

View reviewed changes

xx.md Outdated Show resolved Hide resolved

callebtc reviewed May 31, 2024

View reviewed changes

xx.md Outdated Show resolved Hide resolved

changed transport + token

50fc922

callebtc changed the title ~~Payment Requests~~ NUT-XX: Payment Requests Aug 29, 2024

ngutech21 reviewed Sep 10, 2024

View reviewed changes

prusnak reviewed Sep 10, 2024

View reviewed changes

davidcaseria reviewed Oct 9, 2024

View reviewed changes

callebtc added 3 commits October 15, 2024 18:31

suggestions

1632d88

fix

0c57a0d

Merge branch 'main' into requests

183d2bb

remove TokenV4 JSON, instead use mint unit proofs

3349e24

davidcaseria reviewed Oct 15, 2024

View reviewed changes

callebtc and others added 4 commits October 16, 2024 20:10

add to readme

ec0cb4e

fix transport and change tag

64dc463

change tags to support multiple values

5734943

remove NIP-04

40ec76b

callebtc and others added 6 commits October 18, 2024 14:23

Merge branch 'main' into requests

0f4ddc2

remove TokenV4 JSON, instead use mint unit proofs

28e6f9f

add to readme

459d66f

fix transport and change tag

4989f52

change tags to support multiple values

ec3bfa3

remove NIP-04

0663344

Egge21M force-pushed the requests branch from 40ec76b to 0663344 Compare October 18, 2024 13:23

callebtc added 3 commits October 18, 2024 16:39

readd nutix

a2c6172

:erge branch 'requests' of https://github.com/egge21m/nuts into requests

1c1050d

prettier

211864c

callebtc approved these changes Oct 18, 2024

View reviewed changes

ok300 reviewed Oct 18, 2024

View reviewed changes

callebtc changed the title ~~NUT-XX: Payment Requests~~ NUT-18: Payment Requests Oct 18, 2024

callebtc and others added 4 commits October 18, 2024 17:41

Update 18.md

4ec6ec7

Co-authored-by: ok300 <[email protected]>

remove wrong line

8002b5b

add example

09d70ec

prettier

c09e45f

callebtc merged commit ebed5ba into cashubtc:main Oct 18, 2024
1 check passed


		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.

		`"creq" + base64(versionByte + cbor(PaymentRequest))`


		## Payment payload

		Regardless of the transport layer, the payload sent to the receiver is a JSON serialized object as follows:


		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

NUT-18: Payment Requests #124

NUT-18: Payment Requests #124

Conversation

Egge21M commented May 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thesimplekid commented May 26, 2024

Egge21M commented May 26, 2024

callebtc commented May 27, 2024 • edited Loading

Egge21M commented May 27, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ngutech21 commented Sep 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Egge21M commented Oct 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Egge21M commented Oct 17, 2024

callebtc left a comment

Choose a reason for hiding this comment

ok300 Oct 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prusnak commented Oct 18, 2024

callebtc commented May 27, 2024 •

edited

Loading

ok300 Oct 18, 2024 •

edited

Loading