Conversation
| - `quote` is the opaque quote identifier used by subsequent requests. | ||
| - `request` echoes the share `header_hash` supplied in the request. | ||
| - `state` is one of `"UNPAID"`, `"PAID"`, or `"ISSUED"`. | ||
| - `expiry` is the Unix timestamp (in seconds) until which the share credit remains valid. |
There was a problem hiding this comment.
Share credits should remain valid until some time after the mining reward is received. The mint cannot know the expiry time until after the mining reward is received. For ehash, most quotes are expected to be issued before this time. For use cases that do not involve ehash (mining share -> quote -> mining reward -> issue bitcoin-backed ecash) the quote will remain UNPAID until the mining reward is found, at which time it will change to PAID and the expiry will be set.
There was a problem hiding this comment.
I haven't thoroughly explored the latter use case and don't have an implementation for it. Should I try to write this spec to solve for both use cases or use a separate specification? Or maybe just spec out ehash for now and punt on this question.
| "B_": "035015e6d7ade60ba8426cefaf1832bbd27257636e44a76b922d78e79b47cb689d" | ||
| }, | ||
| { | ||
| "amount": 256, |
There was a problem hiding this comment.
Why are there two proofs for the same amount? Seems like an invalid example.
| curl -X POST https://mint.host/v1/mint/mining_share \ | ||
| -H "Content-Type: application/json" \ | ||
| -d '{ | ||
| "quote": "621ea695-624b-4e53-9643-5e36fc1f8004", |
There was a problem hiding this comment.
cdk uses UUIDs but they are not required in the spec. Should probably change this to use an ellipsis like other spec examples.
|
|
||
| - Mints **MUST** treat `header_hash` values as unique payment identifiers and **MUST** reject duplicate shares. | ||
| - Wallets **SHOULD** generate a fresh NUT-20 key pair per mining-share quote to avoid linking multiple quotes. | ||
| - Wallets **SHOULD** redeem mining-share quotes before they expire and **SHOULD** discard any quote that remains in the `"UNPAID"` state once its `expiry` elapses, as the mint will reject further minting attempts. |
There was a problem hiding this comment.
Still some open questions around expiry. This comment seems incorrect in light of the intended (but not yet implemented) use of the expiry field. See this comment
1 participant
ehash spec
does not include melting because i haven't written it yet