Threshold signatures and ElectrumSV

Who signed what?

Exposed key multi-signature

One thing I have talked about recently is the lack of value in some of the criticisms about non-threshold approaches. Generally you know that there are m possible co-signers, and that at least n of those co-signers signed off on it, but not which of the m those n were. By either design, or as a side-effect of other choices, there is no way for an external observer to discern who actually signed off on a given payment.

Threshold signature

Something you may recall about threshold signature, is that if you lose your key share, you can work with the other parties to recreate it. The way this works is that there’s an inherent property that when you have made a threshold key, it has both a key recreation threshold and a signing threshold. There is a numerical relationship between these two thresholds and the key recreation threshold is always lower than the signing threshold.

Final thoughts

What I want for Christmas is a document that lays out the best practices. The best practices for exposed key multi-signature. The best practices for threshold signature. The best practices for managing coins so that the user is guided to never link their payments, and unknowingly expose what shouldn’t have to be exposed.

Back to ElectrumSV and threshold signatures

ElectrumSV uses a cross-platform Python library we have built, called electrumsv-secp256k1. This builds using VM images that ensure that even our Linux users on reasonable platform choices, do not have to compile it themselves. It should just install like any other Python package and be ready for use.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store