-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NUT for DLC execution #128
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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\"}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here
"registrations": [ | ||
{ | ||
"dlc_root": "2db63c93043ab646836b38292ed4fcf209ba68307427a4b2a8621e8b1daeb8ed", | ||
"funding_amount": <int>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 unit
s 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.