Discreet Log Contracts

[lollerfirst]

Implementing @conduition 's awesome proposal (cashubtc/nuts#128) for discrete log contract execution on chaumian ecash mints.

[codecov]

Codecov Report

Attention: Patch coverage is 83.28691% with 120 lines in your changes missing coverage. Please review.

Project coverage is 59.31%. Comparing base (8675745) to head (d561dbe).
Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
cashu/mint/verification.py	69.46%	40 Missing ⚠️
cashu/mint/router.py	0.00%	21 Missing ⚠️
cashu/mint/db/write.py	84.88%	13 Missing ⚠️
cashu/mint/conditions.py	78.72%	10 Missing ⚠️
cashu/core/errors.py	81.81%	6 Missing ⚠️
cashu/mint/ledger.py	90.62%	6 Missing ⚠️
cashu/wallet/cli/cli.py	73.68%	5 Missing ⚠️
cashu/core/base.py	94.52%	4 Missing ⚠️
cashu/core/crypto/dlc.py	93.61%	3 Missing ⚠️
cashu/mint/crud.py	85.71%	3 Missing ⚠️
... and 5 more

❗ There is a different number of reports uploaded between BASE (8675745) and HEAD (d561dbe). Click for more details.

HEAD has 5 uploads less than BASE

Flag	BASE (8675745)	HEAD (d561dbe)
	9	4

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #576      +/-   ##
==========================================
- Coverage   69.02%   59.31%   -9.71%     
==========================================
  Files          92      101       +9     
  Lines        8674    11082    +2408     
==========================================
+ Hits         5987     6573     +586     
- Misses       2687     4509    +1822     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lollerfirst]

So now basically i wanted to add to the wallet the possibility of minting/swapping-for DLC locked proofs.
It would basically work like this:

cashu invoice <amount> --dlc-lock <dlc_root_hash> <-- mints dlc-locked proofs
cashu selfpay <amount> --dlc-lock <dlc_root_hash> <-- swap current proofs for dlc-locked proofs
cashu selfpay <amount> --dlc-unlock <dlc_root_hash> <-- swaps dlc-locked proofs for normal ones (using the backup secret)
cashu fund <dlc_root_hash> <-- generates a token with the proofs locked to dlc_root_hash.

Naturally this would imply a slight change in the DB table that holds the Proofs in order to accomodate dlc_root_hash and backup_secret where present

[lollerfirst]

And of course I am going to add tests for all of this.

[conduition]

Wow thanks for getting the ball rolling on this! I was surprised to see this as I hadn't received any comments on either NUT drafts. @lollerfirst Is there any discussion which needs to happen to validate the spec itself before we push ahead with this implementation? I would be happy to help out with the code if that's what the cashu team is aiming for now.

[lollerfirst]

Is there any discussion which needs to happen to validate the spec itself before we push ahead with this implementation?

I suppose so. But I thought I would get started in the meantime.
I believe in order to get it merged you'll have to give specific names the new type of requests/responses you're introducing (e.g. PostDlcRegistrationRequest, PostDlcPayoutRequest)

[lollerfirst]

By the way congrats on the proposal, it's very well written.

[gudnuf]

working on a wallet implementation. the router was a bit broken, opened a PR to fix it

• #Fix router paths and add POST /v1/dlc/settle lollerfirst/nutshell#5

[lollerfirst]

@gudnuf Thank you! I haven't tested the router well. The tests I wrote check the functionality but do not go through the router.

Right now the only thing missing from the mint side is POST /v1/dlc/payout.

It's great you're working on a wallet implementation! Since the beginning I thought that the DLC orchestration between clients should be a separate thing from this.

[gudnuf]

Right now the only thing missing from the mint side is POST /v1/dlc/payout.

Looks like that's already implemented, no?

Since the beginning I thought that the DLC orchestration between clients should be a separate thing from this.

I'm working on this to help me learn rust, so forking it into cdk-cli. It will use NIP88 for the DLC orchestration between wallets

[lollerfirst]

Right now the only thing missing from the mint side is POST /v1/dlc/payout.

Looks like that's already implemented, no?

Since the beginning I thought that the DLC orchestration between clients should be a separate thing from this.

I'm working on this to help me learn rust, so forking it into cdk-cli. It will use NIP88 for the DLC orchestration between wallets

Yea I implemented it yesterday.

Nice! Will read about NIP-88.

Not everything here is properly commented and named, so if you have any issue let me know.

[gudnuf]

This is inconsistent from the spec. There is no unit field defined in the responses. I think including the keyset ID in the status response would make more sense than unit if anything.

[lollerfirst]

Weird mistake. I'll be sure to fix that.

[lollerfirst]

Test failing randomly I don't think it's related to this PR.