NUT-XX and NUT-XX+1: Mint / Melt Bitcoin On-Chain #107
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!107
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "mint-melt-onchain"
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?
First draft for minting and melting tokens On-Chain.
looks great so far, nice work!
question about the minting
How do we know when the payment is complete? Do we just try to proceed with mint, and see if it works? Or is there a way to look up the
paidstatus of a mintQuote?Also, is there a way to let the client know, how many more confs are required, before the mint can take place?
Last question, what happens if the tx confirmation time exceeds the expiry?
Should be
methodMight be better to use a realistic minimal amount for on-chain here.
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainI think it's worth mentioning that there are (at least) two ways of handing the variable fee rate problem here.
One option could be that the wallet chooses a fee in
PostMeltQuoteBtcOnchainRequestthis would be a bit like a Lightning node choosing themax_feefor a payment. The mint could then respond with a response or an error depending on whether it agrees. I think this would have to accompanied with some info setting where the mint announces it's accepted fee range.The other option, as you've proposed, would be for the mint to limit the users's choices by returning multiple melt quotes.
Did you consider the first option as well? I wonder if it has any benefits. Happy to hear thoughts from others on this as well.
You can use the following endpoint as per
17.md:This would be cool but I suspect it won't be generally possible to determine this number with every on-chain backend. Take for example a service like Strike or Blink. Obviously, this would be possible with a bitcoin core, lnd, cln, ... on-chain wallet.
That's a very good question. While LN invoices can have a clear expiry, on-chain is a bit more tricky. It might be worth to consider removing this from onchain mints. I think melt expiry doesn't have this problem.
This expiry field might be problematic (cf @gandlafbtc's comment).
Awesome NUT, feels complete! Looking forward to implementing it.
Left a few comments, I don't see any issues other than the
expiryfield for minting.@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-Chain@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainInteresting idea. No haven't thought about it yet.
Good point. I think it's problematic in both way: A wallet could choose a fee that is to low to get in the next block before the quote expires.
On the other side it might be problematic to have a quote that never expires. The way I see a quote is an offer or a contract between the mint and the wallet. If the quote would never expire, the offer is still valid and it would not be possible for a mint to switch to a different onchain backend. I know this is a very rare case. Maybe it would be a good idea to make the expiry optional and recommend a long expiry like 14 days as default for the mint. Any other suggestions?
Worth noting that for sat denominated quotes a long expiry is fine, but for units with an exchange rate (ie sat/usd) it introduces some risk to the mint where wallets could attempt to arbitrage the exchange rate since its up to them to execute the quote or not so i don't think long expiry times should be recommended for non sat units.
EDIT: Is this NUT limited to only the sat unit like NUT04? if so the above can be ignored.
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-Chain@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainDo you have other use cases for the general
descriptionfield? If its always fee rate maybe a specificfee_ratefield as an int would be better?@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainCan be null if not paid yet
What if we change this from an address to a BIP-21 URI? This would enable the mint to optionally support BIP-78 payjoins.
IUC, BIP-21 is meant for clickable links, additional information such as comments, amount etc, should not be part of the
addressfield as it would introduce ambiguity. I think it's fair to assume that the backend would be able to pay most common address formats, and should error (for melt quote) if it doesn't support a particular address format.should there be a way for mints to charge a fee upfront in a mint quote request?
regarding these questions, would it help or are there any concerns if the mint responded with the number of confirmations it requires to consider the mint quote paid?
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-Chainis this
paidfield different than callingGET /v1/melt/quote/btconchain/{quote_id}and getting thatpaidstatus there?@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainI think this should be removed. I don't see any benefit over just using
GET /v1/melt/quote/btconchain/{quote_id}.A related open question I have is should the mint broadcast the transaction as soon as it receives valid proofs for the melt, or can the mint decide to wait and include it in a batch of multiple melts?
The number a confs a mint needs in order to consider a transaction as final should be added to either the quote or the
infoendpoint under the on chain nut settings.@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-Chainyeah
interesting. That will require some changes to the response of the quote state call
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainOther use cases are "next block" or "5 blocks" if the backend uses target blocks instead of sat per vbyte. But I think in most cases it would be sats per vbyte and therefore the description should be an optional field. What do you think?
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainYeah I agree I don't think the description should be required. If a wallet wants to display some estimation like confirmation time it can choose an block explorer to get that from.
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainNo idea if this is relevant but was reviewing it and thought of this thread/PR/NUT.
Note: All
PostMintQuoteBtcOnchainRequest's are denominated in sat.@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainWhy should we remove the unit-field from the PostMintQuoteOnchainRequest? If the mint uses blink as a backend for handling the onchain transactions it can support onchain snd/receive with usd as a currency. Hopefully in the future there will be similar services. https://dev.blink.sv/api/usd-onchain-send
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainThe description is now optional
So what should we do? I think it would be best to change the expiry for mint-requests to optional so a mint can use a expiry for usd based mints and no expiry for sat based mint requests? Any other suggestions @gandlafbtc @callebtc @thesimplekid
What is the difference between issued and pending? Is issued the initial state?
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainThanks for the suggestion. I replaced the boolean flag paid with the enum
This is a question of scoping this NUT. To support other units where a conversion rate is involved how expiration is handled as well as how confirmation time is defined is much more important as the conversion rate could change outside an acceptable slippage. So in order to support other units how confirmation and expiration is defined needs to be included as well.
The issue with on chain is there is no way to expire an address unlike ln, so how is a deposit after an expiration handled is it considered a donation to the mint? If that is that case I think that needs to be made explicit. I think this maybe okay since even in the case of removing expiration that is effectively the case if a deposit is made to a mint that is no longer in operation (if the mint operator still has the keys), so having the explicit handling of expiration might be an improvement.
Of course there is the opportunity for a benevolent mint operator to settle a quote paid after out of band if they are known or have contact info set in the NUT-06. I noticed this is how the strike api handles it, though that has its own trade offs.
As i mentioned above definition of confirmation needs to be included as well with the expiration to signal what needs to happen before the expiration in order for the quote to be settled, num blocks conf, transaction broadcast. This could even be split for example transaction needs to be broadcast before x time to get the exchange rate, but ecash wont be issued until x confirmations.
Yes, good point. I have added min_confirmations to the info-endpoint
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainI removed the redundant GET https://mint.host:3338/v1/melt/btconchain/{tx_id} endpoint
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainIMO the mint can decide if it wants to batch transaction or not. This is same as centralized btc exchanges handle this. We could add a property to the info-endpoint to signal that a mint might delay the melt for batching, but I don't think this is necessary
@ -0,0 +1,208 @@NUT-18: Mint tokens Bitcoin On-ChainI think we do need to signal this and it needs to be more concrete then the mint may delay. I would suggest we add a time component to the
MeltQuoteResponsethis way if the user wants the withdrawal more quickly they will need to pay a higher fee if they are willing to wait and allow the mint to batch they can select aQuotewith a lower fee and wait longer.Allowing the mint to delay for batching but not defining what a delay means will lead to a bad user experience where they don't know when their transaction will be process and they may need it immediately and be willing to pay for that.
@ -0,0 +62,4 @@"address": "bc1qkyfgd7mus7ykfd7qkwakq75qsf7rtm...","state": "UNPAID","expiry": 1701704757}Is it worth adding the txid here?
@ -0,0 +62,4 @@"address": "bc1qkyfgd7mus7ykfd7qkwakq75qsf7rtm...","state": "UNPAID","expiry": 1701704757}It might though this question made me think what if a a quote is payed with multiple transaction, I think that should still be valid? So to cover that it would need to be a list of txid? Unless we explicitly say it MUST be paid in one tx.
@ -0,0 +66,4 @@```The wallet **MUST** store the `amount` in the request and the `quote` id in the response in its database so it can later request the tokens after paying the request. After payment, the wallet continues with the next section.I think it would be worth adding a note here that wallets SHOULD display the quote as a BIP21 URI or BIP21 URI encoded as a QR code to the user. This would help reduce errors of underpaying or overpaying accidentally.
NOTE: There is a draft to replace BIP21 https://github.com/bitcoin/bips/pull/1555 but as its backwards compatible i suggest we say bip21 for now and can update later.
I wonder if we want to allow minting/melting on Liquid chain and if yes, then whether it should be part of these two nuts or a new pair of nuts.
I think it makes more sense to keep separate NUTS, especially since its support should be signaled differently by NUT-06.
Ah yes, that is indeed a good reason.
It does not necessarily impact the spec, but something like this should be the recommended way to handle address generation: https://blog.zaprite.com/optimizing-address-usage-for-the-gap-limit/
@ -0,0 +42,4 @@}]```The mint can return multiple `PostMeltQuoteBtcOnchainResponse` with different `fees` and `expiry` dates. The wallet can choose which one to pay and the other ones will expire. Where `quote` is the quote ID, `amount` the amount that needs to be provided, and `fee` the additional fee that is required. The mint expects `Alice` to include `Proofs` of *at least* `total_amount = amount + fee`. `paid` indicates whether the request as been paid and `expiry` is the Unix timestamp until which the melt quote is valid.It maybe better if we express fee in sats but also with a time component. This would allow the mint to batch transactions. For example fee of x sats will be paid within the hour, fee of y sats within the day etc. This leaves it up to the mint to actually set the final sats per vbyte to meet whatever time period they agreed to in the quote.
@ -0,0 +34,4 @@"state": <str_enum[STATE]>,"expiry": <int>}```If unit is included here don't we need to add an amount in sats to the quote response so the mint can signal the exchange rate. Otherwise if it is non bitcoin unit the wallet will not know how much bitcoin to send to the address to fill the quote.
That being said because of the imprecise nature of sending a bitcoin onchain transaction I would be for removing the unit and limiting it to sat denominated quotes.
@ -0,0 +34,4 @@"state": <str_enum[STATE]>,"expiry": <int>}```I agree. I support keeping it simple to start and only supporting sats as the unit.
@ -0,0 +62,4 @@"address": "bc1qkyfgd7mus7ykfd7qkwakq75qsf7rtm...","state": "UNPAID","expiry": 1701704757}I think it should be explicit only one transaction is supported.
@ -0,0 +41,4 @@`state` is an enum string field with possible values `"UNPAID"`, `"PAID"`, `"PENDING"`, `"ISSUED"`:- `"UNPAID"` means that the quote's request has not been paid yet.- `"PAID"` means that the request has been paid.- `"PENDING"` means that the quote is currently being issued.Is this when the transaction is still confirming?
@ -0,0 +62,4 @@"address": "bc1qkyfgd7mus7ykfd7qkwakq75qsf7rtm...","state": "UNPAID","expiry": 1701704757}Should we return the number of confirmations the transaction currently has?
@ -0,0 +42,4 @@}]```The mint can return multiple `PostMeltQuoteBtcOnchainResponse` with different `fees` and `expiry` dates. The wallet can choose which one to pay and the other ones will expire. Where `quote` is the quote ID, `amount` the amount that needs to be provided, and `fee` the additional fee that is required. The mint expects `Alice` to include `Proofs` of *at least* `total_amount = amount + fee`. `paid` indicates whether the request as been paid and `expiry` is the Unix timestamp until which the melt quote is valid.Should the client specify how fast they want the transaction confirmed in the quote request (e.g., with a
target_blocksfield)?@ -0,0 +42,4 @@}]```The mint can return multiple `PostMeltQuoteBtcOnchainResponse` with different `fees` and `expiry` dates. The wallet can choose which one to pay and the other ones will expire. Where `quote` is the quote ID, `amount` the amount that needs to be provided, and `fee` the additional fee that is required. The mint expects `Alice` to include `Proofs` of *at least* `total_amount = amount + fee`. `paid` indicates whether the request as been paid and `expiry` is the Unix timestamp until which the melt quote is valid.As its currently written the mint returns a list of quotes with different fees for different speed of confirmation. That could be flipped and the client tells the mint what it wants and the mint returns only one quote for that target.
I lean towards how its currently written where the mints returns a set of options and then the client picks the one that best suits it. But as i comments i think we need a time component in addition to the fee so that could be expressed in block time.
@ -0,0 +42,4 @@}]```The mint can return multiple `PostMeltQuoteBtcOnchainResponse` with different `fees` and `expiry` dates. The wallet can choose which one to pay and the other ones will expire. Where `quote` is the quote ID, `amount` the amount that needs to be provided, and `fee` the additional fee that is required. The mint expects `Alice` to include `Proofs` of *at least* `total_amount = amount + fee`. `paid` indicates whether the request as been paid and `expiry` is the Unix timestamp until which the melt quote is valid.Should the spec offer guidance to the mint implementors on what fee rates should be returned so wallet experiences can be similar even though the wallet isn't in control of requesting its fee rate?
@ -0,0 +42,4 @@}]```The mint can return multiple `PostMeltQuoteBtcOnchainResponse` with different `fees` and `expiry` dates. The wallet can choose which one to pay and the other ones will expire. Where `quote` is the quote ID, `amount` the amount that needs to be provided, and `fee` the additional fee that is required. The mint expects `Alice` to include `Proofs` of *at least* `total_amount = amount + fee`. `paid` indicates whether the request as been paid and `expiry` is the Unix timestamp until which the melt quote is valid.Should the spec offer guidance to the mint implementors on what fee rates should be returned so wallet experiences can be similar even though the wallet isn't in control of requesting its fee rate?
All, Is there an implementation of this on-chain mint/melt? I'm thinking of starting one with nutshell. Checking to make sure I'm not duplicating work.
PR for cdk is here https://github.com/cashubtc/cdk/pull/172 haven't seen anything for nutshell.
great. thanks. Will start to work on Nutshell.
@ -0,0 +34,4 @@"state": <str_enum[STATE]>,"expiry": <int>}```Feels simplest to say
So if you wanted to get e.g. "USD eCash by making an onchain tx", it's a two-step process. Has the advantage of a swap being atomic, much faster and less flaky than a mint depending on N confirmations
@ -0,0 +62,4 @@"address": "bc1qkyfgd7mus7ykfd7qkwakq75qsf7rtm...","state": "UNPAID","expiry": 1701704757}It is always going to be possible to make multiple transactions paying the same address, so someone will do that... so how to handle? Multiple transactions also make reorg risk more complex and add consolidation cost for the Mint.
Feels resonable that the requirement should be for a single transaction with one output paying the mint, anything else and the Mint can 'fail' the mint request and refund whatever it got somehow -- would need the user to provide a refund address, or the mint would have to issue an ecash claim on it (but then, consolidation cost etc., would be a 'mint with on-chain dust and then drain the mint's lightning channels' attackable behaviour)
@ -0,0 +42,4 @@}]```The mint can return multiple `PostMeltQuoteBtcOnchainResponse` with different `fees` and `expiry` dates. The wallet can choose which one to pay and the other ones will expire. Where `quote` is the quote ID, `amount` the amount that needs to be provided, and `fee` the additional fee that is required. The mint expects `Alice` to include `Proofs` of *at least* `total_amount = amount + fee`. `paid` indicates whether the request as been paid and `expiry` is the Unix timestamp until which the melt quote is valid.Surely the mint should be able to pick whatever fee it wants? Needs to be flexible to feerate market swings, but also some mints might want to disincentivise on-chain melts by adding a premium, others might offer it at cost
Pull request closed