NUT-18: Add optional P2PK options and transport field #243

Closed

callebtc wants to merge 0 commits from nut-18-p2pk-and-optional-target into main

callebtc commented

2025-03-26 13:42:20 +00:00

(Migrated from github.com)

Introduce optional p2pk options for specifying P2PK locking parameters in payment requests. Make the transport field optional to allow for in-band payment assumptions.

Supersedes and closes #204
Supersedes and closes #209

Todo:

use base64_urlsafe in encoding example

Introduce optional `p2pk` options for specifying P2PK locking parameters in payment requests. Make the `transport` field optional to allow for in-band payment assumptions. Supersedes and closes #204 Supersedes and closes #209 Todo: - [x] use `base64_urlsafe` in encoding example

thesimplekid (Migrated from github.com) reviewed

2025-03-27 08:19:58 +00:00

18.md

Question on the pubkeys we don't have a num_sigs here so if multiple pubkeys are defined any of them can but used or should all of them be used and it should be 1 of n?

Question on the pubkeys we don't have a `num_sigs` here so if multiple pubkeys are defined any of them can but used or should all of them be used and it should be 1 of n?

callebtc (Migrated from github.com) reviewed

2025-03-27 08:21:35 +00:00

18.md

Forgot num_sigs! Thank you. Should've included all tags.

thesimplekid commented

2025-04-02 09:36:22 +00:00

(Migrated from github.com)

cdk: https://github.com/cashubtc/cdk/pull/699

gudnuf commented

2025-04-10 21:07:07 +00:00

(Migrated from github.com)

Could this be changed to more generally define NUT-10 secrets? Instead of extending NUT-18 every time a new spending condition is introduced, could payment requests have a nut10 option where NUT10Option is something like:

{
   "kind": <str>,
   "data": <str>,
   "tags": [[ "key", "value1", "value2", ...],  ... ], // (optional)}
}

For p2pk this is more verbose, but it would allow requests to ask for proofs locked to any condition that follows NUT-10.

Could this be changed to more generally define NUT-10 secrets? Instead of extending NUT-18 every time a new spending condition is introduced, could payment requests have a `nut10` option where `NUT10Option` is something like: ```json { "kind": <str>, "data": <str>, "tags": [[ "key", "value1", "value2", ...], ... ], // (optional)} } ``` For p2pk this is more verbose, but it would allow requests to ask for proofs locked to any condition that follows NUT-10.

👍 1 👀 1

callebtc commented

2025-04-15 06:15:18 +00:00

(Migrated from github.com)

Could this be changed to more generally define NUT-10 secrets? Instead of extending NUT-18 every time a new spending condition is introduced, could payment requests have a nut10 option where NUT10Option is something like:
{
   "kind": <str>,
   "data": <str>,
   "tags": [[ "key", "value1", "value2", ...],  ... ], // (optional)}
}

Not a bad idea, worth considering IMO.

> Could this be changed to more generally define NUT-10 secrets? Instead of extending NUT-18 every time a new spending condition is introduced, could payment requests have a `nut10` option where `NUT10Option` is something like: > > ```json > { > "kind": <str>, > "data": <str>, > "tags": [[ "key", "value1", "value2", ...], ... ], // (optional)} > } > ``` Not a bad idea, worth considering IMO.

gudnuf commented

2025-04-15 18:31:15 +00:00

(Migrated from github.com)

Could this be changed to more generally define NUT-10 secrets? Instead of extending NUT-18 every time a new spending condition is introduced, could payment requests have a nut10 option where NUT10Option is something like:
{
   "kind": <str>,
   "data": <str>,
   "tags": [[ "key", "value1", "value2", ...],  ... ], // (optional)}
}
Not a bad idea, worth considering IMO.

I opened #248 with this proposed change and implemented in cashu-ts: https://github.com/cashubtc/cashu-ts/pull/285

> > Could this be changed to more generally define NUT-10 secrets? Instead of extending NUT-18 every time a new spending condition is introduced, could payment requests have a `nut10` option where `NUT10Option` is something like: > > ```json > > { > > "kind": <str>, > > "data": <str>, > > "tags": [[ "key", "value1", "value2", ...], ... ], // (optional)} > > } > > ``` > > Not a bad idea, worth considering IMO. I opened #248 with this proposed change and implemented in cashu-ts: https://github.com/cashubtc/cashu-ts/pull/285

Egge21M commented

2025-04-17 09:50:55 +00:00

(Migrated from github.com)

I think with the changes proposed by @gudnuf this LGTM. We can then move to discuss the exact structure of it in NUT-11

thesimplekid commented

2025-04-22 08:53:05 +00:00

(Migrated from github.com)

I think with the changes proposed by @gudnuf this LGTM. We can then move to discuss the exact structure of it in NUT-11

I agree doing it this way will prevent having to update the nut in the future for other conditions ie htlc

> I think with the changes proposed by @gudnuf this LGTM. We can then move to discuss the exact structure of it in NUT-11 I agree doing it this way will prevent having to update the nut in the future for other conditions ie htlc

thesimplekid commented

2025-05-04 06:46:17 +00:00

(Migrated from github.com)

We can close this for https://github.com/cashubtc/nuts/pull/248 right?

Egge21M commented

2025-05-04 08:17:29 +00:00

(Migrated from github.com)

We can close this for https://github.com/cashubtc/nuts/pull/248 right?

#248 is a branch of this. We can change target or merge it into this PR

> We can close this for https://github.com/cashubtc/nuts/pull/248 right? #248 is a branch of this. We can change target or merge it into this PR

gudnuf commented

2025-05-05 16:12:58 +00:00

(Migrated from github.com)

We can close this for #248 right?

#248 is a branch of this. We can change target or merge it into this PR

I just changed the branch for 248 to target main, so I'll close this... don't shoot ✋😮🤚

> > We can close this for #248 right? > > #248 is a branch of this. We can change target or merge it into this PR I just changed the branch for 248 to target main, so I'll close this... don't shoot ✋😮🤚