Skip to content
Closed
Changes from all commits
Commits
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
2 changes: 1 addition & 1 deletion 00.md
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ A `Proof` is also called an _input_ and is generated by `Alice` from a `BlindSig
}
```

`amount` is the amount of the `Proof`, `secret` is the secret message and is a utf-8 encoded string (the use of a 64 character hex string generated from 32 random bytes is recommended to prevent fingerprinting), `C` is the unblinded signature on `secret` (hex string), `id` is the [keyset id][02] of the mint public keys that signed the token (hex string).
`amount` is the amount of the `Proof`, `secret` is a string of 64 hex characters generated from 32 bytes of random data, `C` is the unblinded signature on `secret` (hex string), `id` is the [keyset id][02] of the mint public keys that signed the token (hex string).

## 0.2 - Protocol
Copy link
Contributor

Choose a reason for hiding this comment

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

For NUT-11, refund is variable length, same as pubkeys. From testing, around 4-5 total pubkeys (spread over data, refund and pubkeys) will reach the 512 limit.

Perhaps not a hard character limit (as that requires calculating secret before submitting a swap/melt)... but maybe a total limit on pubkeys over all three fields.

Eg a limit of, say, 5 would allow an n-of-5 multisig with no refund keys, or single lock (data) key with 4 refund keys.

Overall I'd prefer a case-by-case limit as suggested by @lollerfirst over a hard 512 limit to allow flexibility for future NUT-10 spending conditions

Copy link
Contributor

@a1denvalu3 a1denvalu3 Apr 24, 2025

Choose a reason for hiding this comment

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

This is a good idea although data is not variable length. Maybe a hard-cap on the number of pubkeys over refund and pubkeys would do (for NUT-11)

Copy link
Contributor

Choose a reason for hiding this comment

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

Correct, data isn't variable, but is a public key field for P2PK. I mentioned it just because it is a locking PK field.. eg an n-of-3 multisig would include data key plus 2 keys in pubkeys.

But essentially, for NUT-11, a limit on total keys over refund and pubkeys is where I'd prefer to go.


Expand Down