NUT for DLC execution #128
Conversation
dlc.md
Outdated
| ```python | ||
| Ki_ = Ki + bi * G | ||
| ``` | ||
|
|
||
| ...for some blinding secret `bi` known to all DLC participants. Each locking point SHOULD be allocated a _unique_ blinding secret. |
There was a problem hiding this comment.
I think it should be safe to use a single blinding secret b to mask every locking point, like this
Ki_ = b * Ki
This would be easier on the client, as the wallet only needs to store one blinding secret per DLC instead of n secrets. We would not be exposing any additional information to the mint, because the mint only ever sees at most one blinded locking point, and thus could not use the common factor of b for any trickery.
Can somebody check me on this?
dlc.md
Outdated
|
|
||
| For each `Payout` object, the mint performs the following checks: | ||
|
|
||
| 1. Validate that `Payout.signature` is a valid [BIP-340] signature made by `Payout.pubkey` on `payout.dlc_root` |
There was a problem hiding this comment.
This could also be a hash preimage, or the dlog of Payout.pubkey.
Not all clients will want to support BIP340 signatures, so we should offer a way for them to claim a DLC by simply exposing a secret key to the mint.
| "dlc_root": "2db63c93043ab646836b38292ed4fcf209ba68307427a4b2a8621e8b1daeb8ed", | ||
| "outcome": { | ||
| "k": "8e935aec5668312be8f960a5ecc3c5dd290e39985970bfd093047df7f05cc9ec", | ||
| "P": "{\"361cd8bd1329fea797a6add1cf1990ffcf2270ceb9fc81eeee0e8e9c1bd0cdf5\":\"10000\"}" |
There was a problem hiding this comment.
shouldn't the value here be 1 as the lone payout gets the entirety of the funding amount?
There was a problem hiding this comment.
It can be any positive integer. Since payout values are computed by relative weights, this number can be anything if there is only one recipient in the payout weights map.
| "dlc_root": "2db63c93043ab646836b38292ed4fcf209ba68307427a4b2a8621e8b1daeb8ed", | ||
| "outcome": { | ||
| "timeout": 1716777419, | ||
| "P": "{\"361cd8bd1329fea797a6add1cf1990ffcf2270ceb9fc81eeee0e8e9c1bd0cdf5\":\"10000\"}" |
| "registrations": [ | ||
| { | ||
| "dlc_root": "2db63c93043ab646836b38292ed4fcf209ba68307427a4b2a8621e8b1daeb8ed", | ||
| "funding_amount": <int>, |
There was a problem hiding this comment.
So all the provided inputs must be signed by keys of the same denomination? Or is just funding_amount in sats?
There was a problem hiding this comment.
input proofs can be in any combination of denominations, as per the usual rules of swap/melt operations.
The new thing here is the funding_amount which is an explicit indicator to the mint, saying "i want to fund this DLC with exactly this much money". The value of all the input proofs will need to meet that threshold - or more if the mint charges fees. (see L254 for how fees are computed)
Note also that the threshold tag in the DLC secret is compared against the funding_amount
There was a problem hiding this comment.
Yes I understand this, but how do we know what denomination the funding amount is in? I, for now, just assumed it is always sats but maybe it should be specified in each registration as an additional field
There was a problem hiding this comment.
Oh sorry, I see what you mean. I forgot about multi-currency support. Yes, good idea, I added a unit field to disambiguate that for the mint. This is also something the mint needs to store (probably easier to just have different tables for DLCs funded under different units than to concretely store the unit as a string)
|
Note to self todo:
|
| ```python | ||
| leaf_hash = SHA256(Settlement.outcome.k * G || Settlement.outcome.P) | ||
| assert merkle_verify(dlc_root, Settlement.merkle_proof, leaf_hash) | ||
| ``` | ||
|
|
There was a problem hiding this comment.
see my other comment on the timeout redemption
Remove the atomic flags for client requests. It creates too much implementation complexity for too little use-case.
Also ensure proofs commit to the funding_amount, so that clients can verify the mint registered a DLC of the correct amount.
|
Added the following spec changes:
|
Depends on #127
Closes #122
Adds a NUT which enables DLC execution using a cashu mint as a blind intermediary. Based on this proposal.