Add NUT-XX: Describe a primes-based keyset, proof scheme

[ok300]

Draft describing a primes-based keyset and proof scheme to achieve smaller tokens.

For easier viewing: https://github.com/ok300/nuts/blob/ok300-keyset-token-primes/xx.md

[prusnak]

Isn't this terrible for privacy?

[ok300]

Good question.

Intuitively, I think not because except for 1 and the prime token amounts, all amounts have multiple ways to be represented as a sum of keyset amounts. This means the mint cannot assume the decomposition, because different clients may find different ones for the same token amount.

I ran some tests to see what's the distribution of the keyset amounts used to represent tokens between 1 and 1000. Sorted by occurrences, it's this:

Click to show table

keyset amount	occurrences
1	333
3	294
5	206
7	161
11	68
13	48
19	41
31	16
919	15
... (2x)	14
17	13
... (7x)	11
... (11x)	10
... (5x)	9
.... (13x)	8
... (7x)	7
... (58x)	6
... (13x)	5
... (14x)	4
... (28x)	3
997	2

No keyset amount appears only once. The biggest one (997) appears twice, then 28 of them appear 3 times each, 14 of them appear 4 times, and so on.

For 997 appearing twice, it means

• if Alice mints 999 (using 997, 2)
• if Susan mints 997 (using only 997)
• if Carol swaps or melts 997, the mint can't know who she got it from

The more users the mint has, the harder this becomes. As part of Carol's swap or melt, fees are paid so 997 becomes 996 or lower and has to be further decomposed.

It gets exponentially harder for other amounts, which are used more often.

[callebtc]

Isn't this terrible for privacy?

Yes, it seems. The whole idea with keysets for different amounts is to reduce the number of keys so we can gain privacy. We're purposefully trade efficiency vs privacy in favor of privacy with the keysets that we use. Here, 1000 keys can't even represent 10000 sats. With powers of two, we can represent the entire bitcoin supply with just 54 keys.

@ok300 appreciate the effort but I don't see why this should be a NUT. A mint can choose whatever keyset they like, nothing stops them from using (way too many!) prime numbers for decomposing the amounts. Then, it becomes a wallet-side issue to decompose these amounts efficiently. I don't see why anything should have to be specified in the spec for that, everyone can just do it without breaking compatibility (although, I would strongly advice against it because of the privacy implications).

Another note, on the format. Although I think the tables and the benchmarks are very interesting, however, they should rather be written up in an article or gist, but the specs is not a place for them. The specs have the sole purpose of establishing consensus. We want to keep them concise, specific, and quick and easy to read.

[callebtc]

nACK

[prusnak]

NACK, the proposal decreases privacy significantly