ECDSA-2P resources

[chris-belcher]

Here are some resources I've managed to collect so far.

I'm not working on ECDSA-2P yet, but sharing this in case other people want to spend time on it.

2018 scaling bitcoin a talk by lightning labs iirc http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/ https://github.com/cfromknecht/tpec

2019 scaling bitcoin threshold scriptless scripts has a list of all threshold ecdsa papers from 2017 until today

lindell's paper is the starting point for most presented at the conference crypto 2017 apparently one protocol uses pallier another protocol uses which works better with EC

big list of resources https://github.com/rdragos/awesome-mpc

theres an iphone wallet called zengo which apparently uses ecdsa-2p mentioned here https://stephanlivera.com/episode/119/

https://twitter.com/NicolasDorier/status/1307333060996689925

14/10/2020 https://github.com/ZenGo-X/multi-party-ecdsa

is this one of the rust libs you mentioned? https://github.com/ZenGo-X/multi-party-ecdsa the examples there are pretty cool

[LLFourn]

I'm interested in this project because I'd like to have something like this in gun. Isn't it more practical to use Schnorr and burn all 2pECDSA papers in a ritual sacrifice to the gods of time wasted?

[moneyball]

See here for relevant discussion: https://github.com/bitcoin-teleport/teleport-transactions/issues/37#issuecomment-942386013

[LLFourn]

To add to the resources list I implemented 2pECDSA adaptor signatures with the Lindell implementation from the zengo libraries a few years ago for the sake of atomic swaps: https://github.com/coblox/ss-ecdsa-poc. That code has probably completely bitrotted now (I was too lazy to fix git revisions). But if zengo still uses the Lindell protocol then the communication complexity of a new implementation based on it would probably be the same. Looking at the entry point for the PoC: https://github.com/coblox/ss-ecdsa-poc/blob/master/src/bin/ss_ecdsa_poc.rs it has 10 (!) rounds of communication to produce an adaptor signature.

From my recollection 2pECDSA is such a PITA that my preference for gun would be to start with the right crypto (schnorr) and then just let anon set improve as "number go up".

[chris-belcher]

Thanks for your thoughts @LLFourn

How hard was it to implement 2pECDSA 2-of-2 multisig? So that's just creating a 2of2 address and signing a transaction spend from it.

Coinswap wont need 2pECDSA adaptor signatures, they can be done with schnorr instead which is only broadcast to the chain in the rare "unhappy" case when one of the peers aborts or deviates from the protocol.

[GeneFerneau]

There are a few protocols for ECDSA-2P implemented in the ZenGo X multi-party-ecdsa library. The Gennaro-Goldfeder protocol allows for M-of-N threshold (including 2-of-2) signatures, mostly consists of offline communication rounds, and one online communication round. Overall, it has less communication rounds than other protocols (including Lindell).

We may not need M-of-N threshold now (2-of-3, etc.), but it would be nice to have the possibility to use it for things like arbitration.

Gennaro-Goldfeder also has the possibility for identifiable abort, so that makers could reliably reject individual takers that deviate from the protocol. If users don't need identifiable abort, the protocol gets even simpler.

My vote is to use Gennaro-Goldfeder for the ECDSA-2P impl.

[LLFourn]

Thanks for your thoughts @LLFourn

How hard was it to implement 2pECDSA 2-of-2 multisig? So that's just creating a 2of2 address and signing a transaction spend from it.

Coinswap wont need 2pECDSA adaptor signatures, they can be done with schnorr instead which is only broadcast to the chain in the rare "unhappy" case when one of the peers aborts or deviates from the protocol.

I see. Unfortunately taking away the adaptor requirement from the implementation doesn't make things much simpler. The hard part is the 2pECDSA -- I don't think it even removes a single round of communication from the Lindell protocol at least.

as @GeneFerneau the state of the art has improved since the Lindell protocol so maybe things are less bad now. Personally, I'd rather not go deeper into 2pECDSA. The amount of review and implementation work is not worth it for something that will hopefully be depreciated in the next 3-5 years.

[GeneFerneau]

as @GeneFerneau the state of the art has improved since the Lindell protocol so maybe things are less bad now. Personally, I'd rather not go deeper into 2pECDSA. The amount of review and implementation work is not worth it for something that will hopefully be depreciated in the next 3-5 years.

Understandable. From the CoinSwap point-of-view, ECDSA-2P is a significant value add (specifically in the timeframe you mention, possibly longer). We're discussing the trade-offs of ECDSA-2P v. Taproot in the issue @moneyball linked.

I can see where it might not be as important/worth-time-effort for something like Lightning or other use cases.

Hopefully, the ZenGo X libs will cut down significantly on impl time. They have also had an audit performed, which is encouraging.