Conversation
|
Just amazing. |
It also speeds up recovery, because you send log N requests. |
XX.md
Outdated
| The recovery procedure defined in [NUT-13][13] reveals the wallet's entire transaction history to the mint. During recovery, the wallet sends every `BlindedMessage` it has ever generated — including nonces for tokens that were never issued — to the mint in sequential batches. This has two consequences: | ||
|
|
||
| 1. **Privacy**: The mint can correlate all of the user's past ecash activity retroactively, defeating the unlinkability guarantees of ecash. | ||
| 2. **Efficiency**: Recovery requires O(T/b) network requests, where T is the total number of issued notes and b is the batch size. |
There was a problem hiding this comment.
I would cut this and instead put in the PR description. This is more of a motivation.
There was a problem hiding this comment.
Good point trimmed it down to a two-line summary. The detailed motivation is already in the PR description.
There was a problem hiding this comment.
Not specific to this pr but we should also make sure we include context like this not just in the PR description but in the git log so we don't lose it the day github enviably doesn't work.
| 2. **On send (swap-to-send)**: A send operation involves a [NUT-03][03] swap that creates new outputs (send proofs + change proofs), which increases T. If this increase causes any remaining unspent proofs (those not involved in the swap) to have index `i ≤ T - d`, the wallet **MUST** consolidate them. Note: a pure melt (paying a Lightning invoice without swap) does not increase T and therefore cannot violate the invariant. | ||
|
|
||
| 3. **Coin selection**: Wallets **MAY** use arbitrary coin selection. After any operation that increases T, the wallet **MUST** check whether any unspent proof now has index `i ≤ T - d` and consolidate if so. This preserves free coin selection while enforcing the invariant. | ||
|
|
There was a problem hiding this comment.
There is also the case where a wallet already has d unspent proofs, and adding any more would violate the constraint no matter if you reissue the old ones. In that case, the operation should fail and compaction should be done to compress all of the existing unspent proofs into fewer ones.
XX.md
Outdated
| ### Breakeven points | ||
|
|
||
| This NUT reveals **more** nonces than [NUT-13][13] for small wallets: | ||
|
|
||
| - **Privacy breakeven**: T ≈ 132. For wallets with T < 132, [NUT-13][13] reveals fewer nonces. | ||
| - **Efficiency breakeven**: T ≈ 825 (with batched gap scan). For wallets with T < 825, [NUT-13][13] makes fewer requests. | ||
|
|
||
| For wallets below these thresholds, the overhead of binary search (32 sequential round-trips) and the fixed recovery window (`d` nonces) exceeds the cost of a simple linear scan. Wallets **MAY** use a heuristic: if a previous recovery or local state suggests T < 200, fall back to the [NUT-13][13] linear scan. | ||
|
|
There was a problem hiding this comment.
really good, although one doesn't know T until found.
XX.md
Outdated
| ### Privacy properties | ||
|
|
||
| The privacy gain for wallets above the breakeven comes from two properties: | ||
|
|
||
| 1. **Bounded leakage**: The number of revealed nonces is constant (182) regardless of wallet history size. A wallet with T = 1,000 reveals the same number of nonces as one with T = 100,000. | ||
| 2. **Non-sequential probes**: The 32 binary search probes are spread across the entire nonce space and are non-contiguous, making transaction history correlation significantly harder for the mint compared to the sequential batches of [NUT-13][13]. |
There was a problem hiding this comment.
I think this information is not necessary to implementors and can be documented elsewhere.
Co-authored-by: a1denvalu3 <43107113+a1denvalu3@users.noreply.github.com>
…emove privacy properties
|
|
||
| --- | ||
|
|
||
| This NUT defines an improved recovery algorithm for [NUT-13][13] wallets that reduces the number of `BlindedMessages` revealed to the mint from O(T) to a constant (~182), improving both privacy and efficiency. It combines a binary search to locate the last issued nonce index T with a **Depth Invariant** that confines all unspent tokens to the last `d` nonce indices. |
There was a problem hiding this comment.
[...] reduces the number of
BlindedMessagesrevealed to the mint from O(T) to a constant (~182)
Why costant 182?
|
On the cdk call we discussed that a wallet birthday would be useful so a wallet knows if it need to use the old linear scan or can use the new method. We could use NUT27 to store a birthday in addition to the mint list. Currently there is a timestamp in the body of the backup but I think that's the time stamp of the backup, adding a optional wallet birthday to that json structure would be a simple backwards compatible change and helpful here. |
|
@thesimplekid Thinking more about it, the birthday doesn't really tells us if we can use the fast recovery. Maybe storing an explicit hint that the wallet respects the properties defined in |
|
Good point. I think that would be reasonable to add to the event as well. Since the event body is just json we could specify that it can be extended by other nuts with optional json fields this way nut-27 does not define it or need to change for possible future nuts and each nut can define that. |
3 participants
Motivated by #301 . Replaces the NUT-13 linear scan with binary search + a depth invariant that bounds unspent proofs to the last
dnonce indices.Reduces BlindedMessages revealed to the mint from O(T) to ~182 (constant), and requests from O(T/b) to ~35. No mint changes required.
Builds on the binary search and d-invariant ideas from #301 . Credit to @a1denvalu3 for the original proposal and algorithm design, @robwoodgate for the halfway-house approach and the concerns around coin-selection that shaped the final invariant, @gandlafbtc for the local-search alternative that framed the trade-offs, and @davidcaseria for raising the practicality constraints that led to the relaxed invariant.
Open for discussion this is a draft NUT, not final. Feedback welcome especially on: the Depth Invariant definition, the gap-tolerance approach, and the default value of
d.