Bip Draft: Discrete Log Equality Proofs (DLEQ)

[andrewtoth]

This BIP specifies a standard way to generate and verify DLEQ proofs. This is motivated by sending to silent payments in PSBTs. However, there are also other uses where DLEQs could be useful, so it would be good to have this BIP for others to reference.

This is inspired by https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality, but is a little more specific.
There is an implementation of that already at https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/src/modules/ecdsa_adaptor/dleq_impl.h, which this BIP attempts to be compatible with.

Inital ML post: https://groups.google.com/g/bitcoindev/c/MezoKV5md7s

[andrewtoth]

There was some previous discussion on this gist before making this PR
https://gist.github.com/andrewtoth/df97c3260cc8d12f09d3855ee61322ea

[jonatack]

Maybe add a section on backwards compatibility, run git grep -A2 Backward on the repo root for ideas.

[andrewtoth]

Not sure there's anything to be backwards compatible with? This would be a new standard?
Perhaps it could discuss compatibility with https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/src/modules/ecdsa_adaptor/dleq_impl.h or any other widely used implementations (Joinmarket)?

[jonatack]

Perhaps

==Backwards Compatibility==

This proposal is compatible with all older clients.

Perhaps it could discuss compatibility with BlockstreamResearch/secp256k1-zkp@master/src/modules/ecdsa_adaptor/dleq_impl.h or any other widely used implementations (Joinmarket)?

Yes, it might be useful to add in a Compatibility section (perhaps somewhat like BIP197) with respect to those.

==Compatibility==

BIP 197 is compatible with [https://github.com/ethereum/EIPs/pull/1850 ERC 1850] for [https://arxiv.org/pdf/1901.05117.pdf atomic loans] with Ethereum. Can be extended in the future to be compatible with other HTLC and smart contract compatible chains.

[stratospher]

is it recommended to use a different r every time? I guess there's no risk of a being leaked with same r here.

[andrewtoth]

We could recommend this, perhaps as a footnote?

[andrewtoth]

Thanks for your comments @jonatack, @stratospher, @theStack. I've also updated the BIP to include the generator G as an input, and so the BIP is no longer specific to secp256k1. This was mentioned on the mailing list as an improvement to make this standard work with other curves as well.

[murchandamus]

From an editorial standpoint this looks good so far. As mentioned by Jon, please include a Backwards Compatibility section, if only to state that there are no concerns.

I did not verify the cryptography of the proof, but after staring at it for a few minutes, I and perhaps other would perhaps benefit from a couple sentences of why/how the proof works e.g. as a footnote. I was also wondering whether you might want to expand on related work, alternate designs, and design decisions in this document. For example you might want to mention some of the things from the opening comment on the PR here, in the footnotes.