Non repudiation

[jimthematrix]

Add a new circuit that adds encryption with a published authority key of all the secret values of a transaction. This allows the smart contract to enforce non-repudiation with the ZKP, while allowing the authority (which possesses all the secret values of all transactions) to be the arbitrator in disputes.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.44%. Comparing base (7d97f65) to head (dc0f729).
Report is 12 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #37      +/-   ##
==========================================
+ Coverage   65.61%   70.44%   +4.83%     
==========================================
  Files          12       12              
  Lines         538      538              
==========================================
+ Hits          353      379      +26     
+ Misses        145      112      -33     
- Partials       40       47       +7     

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

[Chengxuan]

Functionally look good to me, some comments on the documentation

[Chengxuan]

LGTM. Thanks for addressing all the comments @jimthematrix

[EnriqueL8]

I'm not grasping this, we generate a key using the input owner private key to then sign the values passed in so in the future we can check with the public key that the entity that had the private key was the one that tried to perform this transaction?

[Chengxuan]

my understanding is it's used by ECDH to compute the shared key

[EnriqueL8]

But we also have an input into the circuit of the authority public key

[EnriqueL8]

It's a key pair of the public key provided and the private key of the input owner?

[jimthematrix]

the shared secret is used to encrypt rather than sign, the goal is so that the receiver of the encrypted values (the one whose public key is used here) can use their private key and the sender's public key, to derive the same shared secret (this is per the Diffie-Hellman key agreement protocol) to decrypt

[EnriqueL8]

Got it now!

• The inputs are signed by a shared key of the initiator so their private key and the public key of the regulator so only the regulator can in the future decipher them
• The regulator can then verify that the cipher matches all the other inputs into the circuit by decrypting with a shared key of the regulator private key and the initiator public key!

Awesome

[jimthematrix]

we also have an input into the circuit of the authority public key

yes that's the right observation. we are performing two separate encryptions, targeted for two identities (the receiver of the output UTXO, as well as the authority). so we use two separate ECDH to deriver two separate shared secrets to do the encryption