Threshold signatures and ElectrumSV
Where do I currently stand on threshold signatures as an ElectrumSV developer?
I am not a Bitcoin expert. The best way for me to get feedback on any ideas I have, or conclusions I reach, is to put them out there and let people point out problems.
This is a technical article from the perspective of someone who is trying to work out the best way to fit threshold signatures into a wallet. It is not intended as anything other than me laying out my thoughts. If you are a non-technical end user, you should not draw any conclusions from this article. Threshold signatures have some obvious advantages, I recommend people try out the only wallet I know about that allows people to do so, Laxo wallet.
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.
There is some loss of privacy in that you may know who could have signed off on a payment, and that it had to be a subset of these people. The structure of the payment makes it blatantly obvious that it is one of these payments, to the external observer. And it may be that with poor tooling you can link payments to the multi-signature account’s other payments, and this would lead to an additional loss of privacy.
What are the concerns of substance, though? If someone uses poor tooling, then that is on them, not the approach in general. We should both assume, and aim for the situation where the tooling pushes the user to follow best privacy practices. Then presumably, through the lack of linkage between payments in the multi-signature account, it is impossible to know that any given n of m payment other than the one you are personally involved with belongs to it.
The exposure of the keys also has another property. While an external observer may not be able to prove who the owner of a key is, and what they signed, that signer can prove their involvement. Beyond that they can prove who signed off on the payment, every single signer. These are extremely valuable properties in my book.
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.
If I want to be sure that a given number of people have to collaborate to sign off on a payment (or whatever else they are signing together), then I do not want a lesser number to be able to get together and recreate the private key among themselves. If they can do this, they can then sign off on the payment between themselves, and the effective signing threshold is actually the recreation threshold. Of course, when some of these signers are businesses like banks and your lawyer, the risk is low or not present — but people are people and sometimes they might not make the best choices in choosing trusted parties
It is said to be an advantage of threshold signatures that it looks just like a normal payment, which we call P2PKH. And it is quite an appealing quality, that the external observer cannot even discern if it is a multi-signature payment, let alone that there were n of m co-signers involved. But if a key is a key and something is signed with it, whether reconstructed or through the proper protocol, then how do you know which of the co-signers signed off on the payment? Can you prove that the colluding set acted without your involvement? Not as far as I can tell.
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.
Do I know these best practices? I have no clear picture at this time, only a vague notion of the path forward.
Would I use threshold signatures? Yes, but I would want my wallet to provide safe configurations, where the repercussions of choices of things like key reconstruction and signing thresholds are clear, and manage/guide the safe usage of it. Laxo looks like a pretty good start to me.
Would I use exposed key multi-signature? Yes, I would choose this first over threshold every single time if I were not 100% sure that my use case was matched to a safe threshold signature configuration. I love CYA and I would also love to have someone knowledgeable persuade me about how threshold signature does not lose CYA potential in a meaningful way.
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.
The path forward for us, is Nakasendo. Nakasendo also wraps the secp256k1 library, but it doesn’t do so in a way we can use as we do now. And it is not packaged and built as our library is. This means that the path forward is likely rewriting our code to use Nakasendo’s API, and also repackaging it in the cross-platform way we require.
The work required here just for the integration of Nakasendo is probably a couple of weeks, and beyond that there would be a lot of work in the UI and supporting systems. Threshold signatures are not HD (hierarchically deterministic), and co-signers must work together to create each new key they share.
This is currently in the pile that lies somewhere beyond Paymail, which is our next big task after we have 1.3.0 released.