WIP: Add NUT-XX for batched minting #273
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!273
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "batch-mint"
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?
This commit introduces a new specification, NUT-XX, for batched mint operations. It allows wallets to mint multiple proofs in a single transaction, improving efficiency.
I started this as a draft to gather feedback by mint implementors (as the wallet side is trivial). The Cashu side of things should be very easy to do, however getting payment state of multiple payment requests might introduce challenges.
@ -0,0 +24,4 @@- **quote**: an array of **unique** quote IDs previously obtained via the [NUT-04 creation process][04-creation].The mint returns a JSON array of quote objects, each containing:What is the behavior if one of the quote IDs is not found?
@ -0,0 +24,4 @@- **quote**: an array of **unique** quote IDs previously obtained via the [NUT-04 creation process][04-creation].The mint returns a JSON array of quote objects, each containing:I think the best would be to simply omit it from the response. That way the client could handle that case and still use the available data without resending the request
@ -0,0 +1,104 @@# NUT-XX: Batched Mintwhat happens if we have repeated quote_ids? should we fail it?
@ -0,0 +1,104 @@# NUT-XX: Batched Minthow would you thing NUT-20 signed mint should be handled?
may be just a new field called
signaturesand if they are mix we just do a null value?@ -0,0 +1,104 @@# NUT-XX: Batched MintYes, I think making that an invalid request is the best thing to do here. I guess as long as the output sum still matches, a mint could go through with the request, but this feels like adding to much complication. Clients should not include quotes twice.
@ -0,0 +1,104 @@# NUT-XX: Batched MintPerhaps out of scope for this NUT but I have identified a need to query quotes by NUT-20 locking key for the mining share payment method NUT, aka ehash. I intend to propose this change to NUT-04.
@ -0,0 +1,104 @@# NUT-XX: Batched MintIt's looking like my proposal might turn into an API that queries quote ID by NUT-20 locking key. Which means I could make one API call to get the quote IDs and then call this API as-is to mint the tokens.
So I guess all I'm saying is LGTM!
@ -0,0 +1,104 @@# NUT-XX: Batched Mint@ -0,0 +1,104 @@# NUT-XX: Batched Mint@ -0,0 +1,104 @@# NUT-XX: Batched Mintmaybe better nomenclature?
@ -0,0 +1,104 @@# NUT-XX: Batched Mint@ -0,0 +1,104 @@# NUT-XX: Batched MintI don't know if this is a terminology difference between implementations. My understanding is that a proof is an unblinded tuple of secret/signature. Multiple proofs in a quote are guaranteed unless your mint amount is a power of 2. I think it would be less ambiguous to say multiple quotes in the NUT description.
We should require all quotes to share the same payment method. BOLT11 quotes expire, BOLT12 quotes do not. This would be very difficult to reconcile in a single batch mint function for little benefit.
agreed!
close for https://github.com/cashubtc/nuts/pull/323
Pull request closed