Bolt12 #170

Closed

thesimplekid wants to merge 2 commits from bolt12 into main

thesimplekid commented

2024-10-04 10:43:30 +00:00

(Migrated from github.com)

CDK https://github.com/cashubtc/cdk/pull/709
Nutshell
cashu-ts
gonuts
nutmix

- [ ] CDK https://github.com/cashubtc/cdk/pull/709 - [ ] Nutshell - [ ] cashu-ts - [ ] gonuts - [ ] nutmix

a1denvalu3 commented

2024-10-18 18:11:09 +00:00

(Migrated from github.com)

Following up on your hackaton presentation at BTC++ we could make it so that a bolt12 quote has a different status enum:

EMPTY
MINTABLE
RETIRED

The states can go from EMPTY to MINTABLE and back, but once the quote is RETIRED no more state changes.
One might always expect to save and re-use the same quote to mint ecash multiple times, as that is the purpose of the bolt12 (to be paid multiple times).

And then we might introduce a new endpoint through which one can retire the quote.

Following up on your hackaton presentation at BTC++ we could make it so that a bolt12 quote has a different status enum: * `EMPTY` * `MINTABLE` * `RETIRED` The states can go from `EMPTY` to `MINTABLE` and back, but once the quote is `RETIRED` no more state changes. One might always expect to save and re-use the same quote to mint ecash multiple times, as that is the purpose of the bolt12 (to be paid multiple times). And then we might introduce a new endpoint through which one can retire the quote.

ok300 (Migrated from github.com) reviewed

2024-10-31 18:58:12 +00:00

19.md

Would it make sense to specify the length and type of the quote? For example, 64 char hex string?

IMO that makes it clear for implementors and avoids quick-and-dirty (and-insecure) solutions like incrementing from 1, or current unix timestamp, etc.

This also avoids complications if some mints decide to try out exotic characters, which some wallets may not expect.

Would it make sense to specify the length and type of the `quote`? For example, 64 char hex string? IMO that makes it clear for implementors and avoids quick-and-dirty (and-insecure) solutions like incrementing from 1, or current unix timestamp, etc. This also avoids complications if some mints decide to try out exotic characters, which some wallets may not expect.