NUT for DLC execution #128

conduition · 2024-05-27T16:14:48Z

Depends on #127

Closes #122

Adds a NUT which enables DLC execution using a cashu mint as a blind intermediary. Based on this proposal.

conduition · 2024-05-27T16:25:57Z

dlc.md

+```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.


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?

conduition · 2024-05-29T18:31:28Z

dlc.md

+
+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`


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.

lollerfirst · 2024-07-18T14:06:55Z

dlc.md

+      "dlc_root": "2db63c93043ab646836b38292ed4fcf209ba68307427a4b2a8621e8b1daeb8ed",
+      "outcome": {
+        "k": "8e935aec5668312be8f960a5ecc3c5dd290e39985970bfd093047df7f05cc9ec",
+        "P": "{\"361cd8bd1329fea797a6add1cf1990ffcf2270ceb9fc81eeee0e8e9c1bd0cdf5\":\"10000\"}"


shouldn't the value here be 1 as the lone payout gets the entirety of the funding amount?

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.

lollerfirst · 2024-07-18T14:07:32Z

dlc.md

+      "dlc_root": "2db63c93043ab646836b38292ed4fcf209ba68307427a4b2a8621e8b1daeb8ed",
+      "outcome": {
+        "timeout": 1716777419,
+        "P": "{\"361cd8bd1329fea797a6add1cf1990ffcf2270ceb9fc81eeee0e8e9c1bd0cdf5\":\"10000\"}"


lollerfirst · 2024-07-18T17:13:41Z

dlc.md

+  "registrations": [
+    {
+      "dlc_root": "2db63c93043ab646836b38292ed4fcf209ba68307427a4b2a8621e8b1daeb8ed",
+      "funding_amount": <int>,


So all the provided inputs must be signed by keys of the same denomination? Or is just funding_amount in sats?

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

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

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)

conduition · 2024-07-30T15:14:00Z

Note to self todo:

Remove the atomic flag. It adds an unnecessary database-rollback requirement to the implementation and realistically very few users will need to register or resolve multiple DLCs atomically.
Instead of a single dedicated key for funding proof signatures, use the first key from the relevant unit's active keyset

dlc.md

lollerfirst · 2024-08-02T18:03:26Z

dlc.md

+```python
+leaf_hash = SHA256(Settlement.outcome.k * G || Settlement.outcome.P)
+assert merkle_verify(dlc_root, Settlement.merkle_proof, leaf_hash)
+```
+


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.

conduition · 2024-08-04T18:21:25Z

Added the following spec changes:

No more 'atomic' flags ce22a20
Timeout timestamps are now encoded as uint64 instead of uint32 b67e62a
Add recommendations for clients to avoid being scammed by replay attacks 6990d59
Improve security of the funding_proof signature by the mint. It now commits to the funding_amount explicitly, and to the funding unit implicitly, by using a signing key from an active keyset instead of a dedicated key. 95f47ba a86a4e8

lollerfirst · 2024-09-14T09:38:04Z

dlc.md

+1. If `Payout.dlc_root` does not correspond to any known funded DLC, return an error.
+1. If `Payout.dlc_root` corresponds to a known DLC, but that DLC has not been settled, return an error.
+1. If `Payout.pubkey` is not a key in the `debts` map, return an error.
+1. If `sum([out.amount for out in Payout.outputs]) != debts[Payout.pubkey]`, return an error.


@conduition I think here it should be sum([out.amount for out in Payout.outputs]) != eligible_amount where eligible_amount is calculated as follows:

denom = sum(debts.values()) nom = debts[payout.pubkey] eligible_amount = int(nom / denom * funding_amount)

Also, I was thinking we can discriminate based on whether the requested amount is equal or less than the eligible amount:

if it's equal, we drop the pubkey entry from the debts map

if it's less, we adjust the debts map so that the pubkey entry displays a weight value calculated such that new_eligible_amount == old_eligible_amount - requested_amount

I think here it should be sum([out.amount for out in Payout.outputs]) != eligible_amount where eligible_amount is calculated as follows:

denom = sum(debts.values()) nom = debts[payout.pubkey] eligible_amount = int(nom / denom * funding_amount)

Earlier in the document, we define debts as follows:

weights = json.loads(Settlement.outcome.P) weight_sum = sum(weights.values()) debts = dict(((pubkey, funding_amount * weight // weight_sum) for pubkey, weight in weights.items()))

You can view debts as a mapping from weights[pubkey] to weights[pubkey] / sum(weights.values()) * funding_amount. Because sum((x / sum(set) for x in set)) == 1 for any set, we can assert:

sum(debts.values()) ~= funding_amount

(approximately, due to integer division rounding)

In your suggestion you have:

eligible_amount = int(debts[payout.pubkey] / sum(debts.values()) * funding_amount)

But as i just showed, sum(debts.values()) is approximately equivalent to funding_amount. Simplify your definition of eligible_amount and you'll find it's the same as debts[payout.pubkey]:

debts[payout.pubkey] / sum(debts.values()) * funding_amount debts[payout.pubkey] / funding_amount * funding_amount debts[payout.pubkey]

Also, I was thinking we can discriminate based on whether the requested amount is equal or less than the eligible amount:

Interesting. Is there any reason (other than a computational error) why a wallet wouldn't want to claim its full payout at once?

Aw, man. I think I might have misinterpreted/read too quickly that part of the spec. I thought the debts map was just the Settlement.outcome.P once it was validated (BTW that's also what I have implemented).

Any reason why it can't be?

[EDIT: forget it. much simplier your way]

Also, I was thinking we can discriminate based on whether the requested amount is equal or less than the eligible amount:

Interesting. Is there any reason (other than a computational error) why a wallet wouldn't want to claim its full payout at once?

It's just something that can happen. Do we let the mint just rug the claimant in that case? I thought it might be better not to.

This is something I was hoping to clean up once we had a working implementation we can test against.

Right now it should do everything. It surely has a million problems but you can test it if you want.

As for specifically why i'm trying to avoid partial claims, it's because it would allow one more vector for clients to DoS the mint (by consuming space with pubkeys for cheap). This is something I was hoping to clean up once we had a working implementation we can test against.

Right now if the DLC is overfunded, the mint automatically adjusts the funding amount. So one client might unknowingly provide an amount which doesn't exactly match their eligible amount, thereby failing the transaction.

So one client might unknowingly provide an amount which doesn't exactly match their eligible amount, thereby failing the transaction.

If a DLC is overfunded, all clients involved in the DLC must know about it. The funding_amount is committed to in the DlcFundingProof that the funder uses to prove DLC registration. If for some reason a funder goes silent after registering and overfunding a DLC, their peer clients can simply use GET /v1/dlc/status/{dlc_root} to see the true funding amount. This endpoint will also explicitly return the debts map once the DLC is settled, allowing faulty clients to recover gracefully if the POST /v1/dlc/payout request fails due to a mismatching output sum.

I just don't see the point in allowing partial payouts when all these options are available. It feels like an invitation to a class of "missing money" bugs in client implementations where clients withdraw some money and leave the rest on the table unknowingly. It also allows one more way to DoS the mint which we'll have to clean up later.

it's your call if you'd like to implement partial withdrawals (it's your code after all), but I would recommend against it.

Ok ok. I'll change it back.

gudnuf · 2024-10-27T10:06:48Z

dlc.md

+
+## Payout Structures
+
+Payout structures are serialized dictionaries which map `xonly_pubkey -> weight`.


Can we make the public keys 33-bytes to be consistent with the rest of Cashu? @lollerfirst already implemented this with 33-byte keys.

The use of 33-byte pubkeys for BIP340 signatures was a mistake. See #133. New NUTs should use xonly pubkeys when validating BIP340 signatures

conduition added 3 commits May 27, 2024 15:52

Add spending condition trees to multiplex NUT-10

29c75ef

NUT for DLC execution

6aaaa6e

TODO about proof of registration

37b985f

conduition commented May 27, 2024

View reviewed changes

conduition mentioned this pull request May 27, 2024

Add spending condition trees to multiplex NUT-10 #127

Open

use actual point in example

f676438

conduition commented May 29, 2024

View reviewed changes

example funding request should use SCT secret

1822875

conduition mentioned this pull request Jun 4, 2024

Add fees to NUT-02 #126

Merged

11 tasks

conduition added 4 commits June 4, 2024 02:37

fees, offline funding proofs, and anti-DOS measures

e44621b

outcome blinding can use a single secret

ff4295c

offer simpler ways to authenticate claims

741eac6

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.

use xonly pubkeys for BIP340 signatures

a788a8a

lollerfirst mentioned this pull request Jul 10, 2024

Discreet Log Contracts cashubtc/nutshell#576

Draft

conduition mentioned this pull request Jul 14, 2024

NIP-88: Discreet Log Contracts over Nostr nostr-protocol/nips#919

Draft

lollerfirst reviewed Jul 18, 2024

View reviewed changes

conduition added 6 commits July 19, 2024 06:10

specify currency-specific dlc funding parameters

e10d9f2

Merge branch 'main' into spending-condition-trees

7a8b238

Merge branch 'spending-condition-trees' into dlcs

66b1f57

Proof.witness must be a string to match other NUTs

d1ffefa

Proof.witness must be a string to match other NUTs

568c092

Merge branch 'spending-condition-trees' into dlcs

c72423f

supertestnet mentioned this pull request Aug 2, 2024

Topic suggestions for Socratic Seminar #2 guadalajara-bitdevs/BitDevsGDL.github.io#3

Closed

lollerfirst reviewed Aug 2, 2024

View reviewed changes

dlc.md Outdated Show resolved Hide resolved

lollerfirst reviewed Aug 2, 2024

View reviewed changes

conduition added 2 commits August 4, 2024 16:05

remove atomic flags

ce22a20

Remove the atomic flags for client requests. It creates too much implementation complexity for too little use-case.

encode timeout timestamp as a u64

b67e62a

conduition added 4 commits August 4, 2024 16:57

add note about bytewise concatenation symbol

f111e06

add section describing replay attack mitigations

6990d59

funding proofs use a key from an active keyset instead of dedicated key

95f47ba

Also ensure proofs commit to the funding_amount, so that clients can verify the mint registered a DLC of the correct amount.

add footnote about security of key reuse

a86a4e8

conduition mentioned this pull request Aug 23, 2024

fix funding proof signatures to match spec lollerfirst/nutshell#4

Merged

lollerfirst reviewed Sep 14, 2024

View reviewed changes

lollerfirst approved these changes Sep 16, 2024

View reviewed changes

gudnuf reviewed Nov 19, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NUT for DLC execution #128

NUT for DLC execution #128

conduition commented May 27, 2024 •

edited

Loading

conduition May 27, 2024 •

edited

Loading

conduition May 29, 2024

lollerfirst Jul 18, 2024

conduition Jul 19, 2024

lollerfirst Jul 18, 2024

lollerfirst Jul 18, 2024

conduition Jul 19, 2024

lollerfirst Jul 19, 2024 •

edited

Loading

conduition Jul 19, 2024

conduition commented Jul 30, 2024

lollerfirst Aug 2, 2024

conduition commented Aug 4, 2024 •

edited

Loading

lollerfirst Sep 14, 2024 •

edited

Loading

conduition Sep 14, 2024 •

edited

Loading

conduition Sep 14, 2024

lollerfirst Sep 14, 2024 •

edited

Loading

lollerfirst Sep 14, 2024

lollerfirst Sep 16, 2024

lollerfirst Sep 16, 2024 •

edited

Loading

conduition Sep 17, 2024

conduition Sep 17, 2024

lollerfirst Sep 21, 2024

gudnuf Oct 27, 2024

conduition Nov 23, 2024


		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`


		## Payout Structures

		Payout structures are serialized dictionaries which map `xonly_pubkey -> weight`.

NUT for DLC execution #128

Are you sure you want to change the base?

NUT for DLC execution #128

Conversation

conduition commented May 27, 2024 • edited Loading

conduition May 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lollerfirst Jul 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

conduition commented Jul 30, 2024

Choose a reason for hiding this comment

conduition commented Aug 4, 2024 • edited Loading

lollerfirst Sep 14, 2024 • edited Loading

Choose a reason for hiding this comment

conduition Sep 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lollerfirst Sep 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lollerfirst Sep 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

conduition commented May 27, 2024 •

edited

Loading

conduition May 27, 2024 •

edited

Loading

lollerfirst Jul 19, 2024 •

edited

Loading

conduition commented Aug 4, 2024 •

edited

Loading

lollerfirst Sep 14, 2024 •

edited

Loading

conduition Sep 14, 2024 •

edited

Loading

lollerfirst Sep 14, 2024 •

edited

Loading

lollerfirst Sep 16, 2024 •

edited

Loading