The NUTs do not currently offer insights/recommendations on how to order the list of BlindedMessages that the client builds when it requests minting and splitting tokens. Because ordering those in specific ways is potentially a privacy leak to the mint, advising clients to sort this list of outputs before sending them over is helpful.
The paragraph added to NUT-04 and NUT-06 is the following:
Note that in order to preserve privacy around the exact amount a client might be trying to build a token for, the client SHOULD ensure that the list of BlindedMessages is always ordered by amount in ascending order. For example, a request for tokens expressed like so: [16, 8, 2, 64, 8] might imply the client is building a payment for 26 sat; the client should instead order the list like so: [2, 8, 8, 16, 64] to reduce extra information given to the mint.
A few questions for reviewers of this PR:
Are there any advantages to the ordering being ascending, descending, or random? I couldn't think of any so I just picked one (ascending), but let me know if you can see any reason to maybe pick a different one and I'll adjust the wording (my only thought was around the "random" sorting effectively adding a reliance on access to proper randomness; if it's not needed, better keep it out?).
I currently have this sorting as a SHOULD statement, but of course it could actually be a MUST as well, and the protocol could simply parse those requests as invalid if the outputs are not sorted the way they should be. It's a stricter approach. Not sure if it's better to be stricter or looser with these things.
The NUTs do not currently offer insights/recommendations on how to order the list of
BlindedMessage
s that the client builds when it requests minting and splitting tokens. Because ordering those in specific ways is potentially a privacy leak to the mint, advising clients to sort this list of outputs before sending them over is helpful.The paragraph added to NUT-04 and NUT-06 is the following:
A few questions for reviewers of this PR: