NUT-XX: Efficient wallet recovery #342
No reviewers
Labels
No labels
breaking change
bug
documentation
enhancement
needs discussion
needs implementation
new nut
ready
wallet-only
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
forgejo-admin/nuts!342
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "Forte11Cuba/nut-xx-efficient-wallet-recovery"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.Just amazing.
It also speeds up recovery, because you send log N requests.
I would cut this and instead put in the PR description. This is more of a motivation.
Good point trimmed it down to a two-line summary. The detailed motivation is already in the PR description.
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.
@ -0,0 +39,4 @@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 is also the case where a wallet already has
dunspent 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.really good, although one doesn't know T until found.
I think this information is not necessary to implementors and can be documented elsewhere.
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
nut-xxwould be a more helpful tip.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.
@Forte11Cuba made a PR to your PR, addressing what we talked about.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.