Resilient Custody of Crypto-Assets, and Threshold Multisignatures

[fillippone]

The italian user vincenzo, who is Vincenzo di Nicola, co-founder at Conio, shared on a post a new paper he co-wrote with the mathematics department of University of Trento.

I found it very interesting, and I want to share it with you.
He also asked feedback from the community, so I think you could help here!

Resilient Custody of Crypto-Assets, and Threshold Multisignatures

ABSTRACT:

Ensuring safe custody of crypto-assets, while at the same time allowing a user to easily access and transfer them, is one of the biggest challenges of this nascent industry. This is even harder considering also the multiple technological implementations behind each crypto-asset. Here we present a survey of the various solutions for this custody problem, comparing advantages and disadvantages. Then we delve deeper into some interesting schemes based on secure multiparty computation, which give a blockchain-agnostic solution that balances security, safety, and transactional ease of use, and in particular, a protocol that enhances practicality by exploiting a party that may stay offline during the key generation.

Conio is providing multi signature solution, amongst the other, to the italian while label bank Hype, where an user can safely store bitcoins (real Bitcoins, not shitty CFD's à la Revolut), on their wallet, perfectly integrated with the other bank's products.

The paper starts quite descriptive and progressively gets more technical. Definitely worth a read.

[1714103588]

1714103588

[1714103588]

1714103588

[ABCbits]

Sounds interesting, i'll read the paper later since it's not full of math formula.

P.S. looks you haven't include link to the paper, here's the link if anyone wants to read https://www.mdpi.com/2227-7390/8/10/1773

[Charles-Tim]

2.1. Self-Custody
One of the most immediate and trivial solutions to the problem of crypto-assets custody is self-custody: no third party is involved—the user is entirely responsible for the security and protection of the private key. An aid may come from a mnemonic passphrase (usually comprised of 12 or 24 common words) that can be used to reconstruct the key and, for example, facilitate the transfer to a new device. This solution is particularly appreciated by those who want complete control of their digital assets, usually due to a lack of trust or confidence in a third party’s transparency, policies, and behavior.

I want to comment about this, it was a mistake I think, the 12 to 24 words are not mnemonic passphrase, they are actually called mnemonic seed phrase, which are simple words to be used to generate the keys of a wallet, passphrase is different and it is just like a password used to protect the seed phrase which is introduced through a process called salting in which the passphrase will lead to generation of different seed entirely.

[HeRetiK]

Interesting, however it looks like the benefits of this approach over the current multi-sig scheme (ie. smaller signature size, better privacy) will become nullified by the deployment of Schnorr signatures. The added complexity, both user-facing and in terms of protocol logic, would then further detract from the attractiveness of this approach.

Depending on how easy it is to layer on top of existing cryptos it could be a neat addition to the cryptocurrency-toolbox though. At least I assume that's what they mean by this approach being a "blockchain-agnostic solution".

[pooya87]

~

technically it is correct.
according to RFC-8018 the octet string P that is given to the pseudorandom function to derive keys is called "password".
that is essentially what BIP-39 does. P is the mnemonic, and "S" or the salt is the additional but optional user input which the wallets can call "password/passphrase" too and applies 2048 rounds on it (as defined by RFC-8018 that is PBKDF2) to derive a key which is then used as the entropy/seed for BIP-32.

https://tools.ietf.org/html/rfc8018#section-5.2

[ABCbits]

The method is far more complicated than i thought and it uses various things that i never heard previously (such as Feldman’s verifiable protocol). Additionally there are many things that i couldn't understand such as

1.They convert the(2, 3)-threshold shares xi of x into(2, 2)-threshold shares wi of x with appropriate Lagrangian coefficients

I don't say it's bad method (rather i find it interesting), but it's very complex while involving third party (Service Provider and Recovery Server in this case).It's definitely not for people like me.

[fillippone]

The method is far more complicated than i thought and it uses various things that i never heard previously (such as Feldman’s verifiable protocol). Additionally there are many things that i couldn't understand such as

1.They convert the(2, 3)-threshold shares xi of x into(2, 2)-threshold shares wi of x with appropriate Lagrangian coefficients

I don't say it's bad method (rather i find it interesting), but it's very complex while involving third party (Service Provider and Recovery Server in this case).It's definitely not for people like me.

This method an evolution of the one that is currently used by Conio to provide a safe clients’ bitcoin custody at Hype.

The setup is meant to provide the user the full control of his bitcoin without the hassle and the responsibility of custody of his private key. We know that users are seldom their own worst enemy, not backing up her private key, losing access to their devices or generally doing stupid things.

So this setup is meant to “protect” the waekest link in the user/custody/service provider, letting him in control of his private key, but being able to recover access to funds in case of a major disaster.

In the coming months, I’ve been told Conio will release a wallet under this scheme, and next they will implement in their Hype solution.

[o_e_l_e_o]

Mathematically, it is an interesting piece of work. However, not only will be made more or less obsolete by Schnorr signatures as HeRetiK says, but I have some concerns with it being implemented in practice.

First of all, it still requires trust. It is essentially a 2-of-3 system, meaning the "Service Provider" and "Recovery Server" can collaborate to steal the user's funds. Given that this method does not yet exist, then presumably whichever company first sets it up and offers it to their customers will also be hosting the recovery server, meaning they have complete control over your coins should they turn evil. It also completely relies on this company continuing to operate.

Second of all, even if the "Service Provider" and "Recovery Server" could be spread between two different companies, you are still entirely dependent on this one implementation of the software. If that disappears from wherever it will eventually be hosted, could you recreate it and recover your coins? Again, it involves a lot of trust.

[fillippone]

<...>

I think both of your points are correct, but I also think @vincenzo has an answer to disclose a little bit on those design choices. I hope to drag him on this discussion.

[Karartma1]

The method is far more complicated than i thought and it uses various things that i never heard previously (such as Feldman’s verifiable protocol). Additionally there are many things that i couldn't understand such as

1.They convert the(2, 3)-threshold shares xi of x into(2, 2)-threshold shares wi of x with appropriate Lagrangian coefficients

I don't say it's bad method (rather i find it interesting), but it's very complex while involving third party (Service Provider and Recovery Server in this case).It's definitely not for people like me.

This method an evolution of the one that is currently used by Conio to provide a safe clients’ bitcoin custody at Hype.

The setup is meant to provide the user the full control of his bitcoin without the hassle and the responsibility of custody of his private key. We know that users are seldom their own worst enemy, not backing up her private key, losing access to their devices or generally doing stupid things.

So this setup is meant to “protect” the waekest link in the user/custody/service provider, letting him in control of his private key, but being able to recover access to funds in case of a major disaster.

In the coming months, I’ve been told Conio will release a wallet under this scheme, and next they will implement in their Hype solution.

So basically this company, Conio, has a multisig (3keys wallet) and they provide such service to a bank, Hype by Bank Sella? This is unbelievable! You are telling me that a bank in Italy allows people to buy bitcoin so easily! That's crazy

[Charles-Tim]

2.5. On-Chain Multisignature
All of the solutions seen so far for the crypto-assets custody problem can be somehow categorized into user-responsible solutions or third-party-responsible solutions. An alternative approach to the crypto-asset custody problem is to split up the responsibility of the crypto-assets among more parties in order to avoid a single point of failure. For instance, the Bitcoin [21] protocol natively makes use of the multisignature [22], a type of signature that allows a group of users to authorize transactions combining multiple unique key signatures. The multisignature transactions are also referred to as M-of-N transactions, in the sense that N private keys are associated with a Bitcoin address. In order to make a transaction with this address, at least M (the threshold) signatures corresponding to M distinct private keys (out of the N associated with the address) must be affixed.
Dividing the responsibility between different parties increases security since even if some of the private keys are compromised, as long as they are less than M, the address remains secure. It also works well for the key recovery issue: if if n≤N−M users lose their private keys, the remaining users associated with that address still have access to the funds and can move them to a new address.

Please, never mind my question, I am still somehow new. It is about the statement that 'funds can be moved to a new address' if one of the n≤N−M users of the multisig wallet lost his private keys, I am confused and I will appreciate clear explanation, I was thinking if one of the users n≤N−M lost his private keys to control the bitcoin on multisig wallet, that means M users that still have control over the bitcoin will move the bitcoin to a new wallet entirely, which means a new private keys will be generated entirely. Is this what the statement is implying?

[nc50lc]

2.5. On-Chain Multisignature
An alternative approach to the crypto-asset custody problem is to split up the responsibility of the crypto-assets among more parties in order to avoid a single point of failure.
-snip-
Dividing the responsibility between different parties increases security since even if some of the private keys are compromised, as long as they are less than M, the address remains secure. It also works well for the key recovery issue: if n≤N−M users lose their private keys, the remaining users associated with that address still have access to the funds and can move them to a new address.

Please, never mind my question, I am still somehow new. It is about the statement that 'funds can be moved to a new address' if one of the users of the multisig wallet lost his private keys, I am confused and I will appreciate clear explanation, -snip-

That's because the highlighted part isn't stand-alone, you need to base it on the first sentences in order to understand it  

What's it's saying is if there are more cosigners for the MultiSig Address,
there will be less chance that the funds will get locked since there are more other cosigners to replace the ones who lost their keys.
n≤N−M simply means: number of cosigners who lost their keys (n) is less than or equal to (≤) the total number of signatures (N) minus the number of required signatures (M).
Example: For 3/5 multisig (5-3), as long as it's only 2 or 1 of the cosigners lost their keys, they can still spend from that address because it only requires 3.

I believe moving the funds to a new address after losing/compromising some of the keys is a must for security reasons that's why it's written.

[Charles-Tim]

That's because the highlighted part isn't stand-alone, you need to base it on the first sentences in order to understand it  

What's it's saying is if there are more cosigners for the MultiSig Address,
there will be less chance that the funds will get locked since there are more other cosigners to replace the ones who lost their keys.
n≤N−M simply means: number of cosigners who lost their keys (n) is less than or equal to (≤) the total number of signatures (N) minus the number of required signatures (M).
Example: For 3/5 multisig (5-3), as long as it's only 2 or 1 of the cosigners lost their keys, they can still spend from that address because it only requires 3.

And it states that it's still safe as long as the compromised keys won't reach the required number of cosigners.

Yes, I understood now, and thanks for the more clarification, the statement only means that more addresses can be generated and still be used for transaction and be signed by M.

What I do not understand is that, assuming if one of user with n lost his private keys, but still needed to be included and needed his own private keys, and it is agreed upon by other users. What will happen? Will the users have to create another multisig wallet, and M users send all the bitcoin in their previous multisig wallet to the new multisig wallet? So that things can be like before.

[nc50lc]

What I do not understand is that, assuming if one of user with n lost his private keys, but still needed to be included and needed his own private keys, and it is agreed upon by other users. What will happen? Will the users have to create another multisig wallet, and M users send all the bitcoin in their previous multisig wallet to the new multisig wallet? So that things can be like before.

Yes, since you cannot recreate the address from the remaining keys and new ones so a new Multisig address must be created if the user(s) who lost his/their key need to save a new one.
And I have edited the previous post before you replied, it has an additional answer.

Yes, I understood now, and thanks for the more clarification, the statement only means that more addresses can be generated and still be used for transaction and be signed by M.

It only states that the current MultiSig address can still spend as long as there are still enough keys.

It's quite off-topic BTW.
You can read about multisig in Bitcoin Wiki.

[Charles-Tim]

I have been reading this paper and understanding it little by little. Now, I have known about Threshold Multiparty Computation (MPC) Signatures, and to be specific, (2,3)-threshold multisignature protocol which the paper really focused on. A user which is the client can depend on Service Provider and on Recovery Server in a way private keys can be well protected in a way the two (service provider and recovery provider) can be able to provide the user with the private key at a point in time, maybe due to private key loss.

For example, if the user lost his private keys, the private keys can be recovered in a secure and safe way from the service provider, but if the service provider is affected and can not provide the private keys, the user can recover back the private key from the recovery server also in a safe and secure way.

But, I have a question. Assuming the service provider and recovery server are both affected, hope the private key is not lost forever? Or, no matter what, the recovery server can not be affected and will always be able to provide the private key even if the service provider is affected?

[HeRetiK]

I have been reading this paper and understanding it little by little. Now, I have known about Threshold Multiparty Computation (MPC) Signatures, and to be specific, (2,3)-threshold multisignature protocol which the paper really focused on. A user which is the client can depend on Service Provider and on Recovery Server in a way private keys can be well protected in a way the two (service provider and recovery provider) can be able to provide the user with the private key at a point in time, maybe due to private key loss.

For example, if the user lost his private keys, the private keys can be recovered in a secure and safe way from the service provider, but if the service provider is affected and can not provide the private keys, the user can recover back the private key from the recovery server also in a safe and secure way.

But, I have a question. Assuming the service provider and recovery server are both affected, hope the private key is not lost forever? Or, no matter what, the recovery server can not be affected and will always be able to provide the private key even if the service provider is affected?

Private keys are never transmitted as that would be insecure. 2 out of 3 parties are signing transactions together, without knowing each others private key.

Since the threshold is 2 out of 3, if both the service provider and recovery server lose their keys, the user will be unable to access their coins.

[o_e_l_e_o]

But, I have a question. Assuming the service provider and recovery server are both affected, hope the private key is not lost forever? Or, no matter what, the recovery server can not be affected and will always be able to provide the private key even if the service provider is affected?

As HeRetiK says, if both are affected then the coins are lost. The user only holds one of the three shares - if the other two shares are both lost, then the one remaining share is insufficient to meet the 2-of-3 threshold.

This is why I mentioned above that this system is built on an uncomfortable level of trust for me to use it. Because it is a new and niche application of a key splitting scheme, then at least initially both of the other two keys are going to be held by the same entity, albeit on different servers. The same company will be the Service Provider, as well as host the Recovery Server. I would also argue that it is highly unlikely that an independent third party is going to go to the effort of implementing this brand new protocol on their own Recovery Server, as the number of people who will use it plus any fee they might earn from these people is going to be incredibly small and therefore simply not worth their time.

And so, if that one company ceases operating for any reason, then your coins are lost forever.

[Charles-Tim]

...

I appreciate your answers. (2,3)-threshold multisignature protocol is even off-chain in its entirety, and with what I have read on news lately, I am very sure that BIP340 (Schnorr signature), BIP341 (Taproot) and BIP342 (Tapscript) is now well ready, but only remian to be included in bitcoin core, if this is included in bitcoin core, multisig transactions will be indistinguishable, and I hope the payment for multisig transactions will be lower and be like normal single key payment. So, I think this will be the best choice which is even included in blockchain rather than off-chain.

[HeRetiK]

...

I appreciate your answers. (2,3)-threshold multisignature protocol is even off-chain in its entirety, and with what I have read on news lately, I am very sure that BIP340 (Schnorr signature), BIP341 (Taproot) and BIP342 (Tapscript) is now well ready, but only remian to be included in bitcoin core, if this is included in bitcoin core, multisig transactions will be indistinguishable, and I hope the payment for multisig transactions will be lower and be like normal single key payment. So, I think this will be the best choice which is even included in blockchain rather than off-chain.

Based on this quote I do believe they are leaning towards targeting alt coins rather than Bitcoin anyway:

The compatibility of the signature with the standard algorithm means that this custody solution does not depend on blockchain support, namely, it is blockchain-agnostic. As a result, it can be applied to many current prominent or in-progress (e.g., Libra) cryptocurrencies that do not natively support multisignature schemes.

Thing is, I'm not aware of any major alt that is lacking multisig support? My altcoin knowledge is not really up to speed though, so maybe there's projects out there for which this solution could be particularly interesting.


That being said, o_e_l_e_o's concerns about introducing third party trust really need to be emphasized.

If two other parties can collaborate to move your funds (either due to voluntary cooperation or one party deceiving the other) it's just a sneaky way to introduce custodial wallets, ie. the "not your keys, not your coins" problem -- made worse by adding a false sense of security.

[vincenzo]

First of all, thanks everyone for the interest in the paper. I am one of the authors, and we're also working on its real implementation with a Bitcoin wallet (hopefully by end of the year).

Mathematically, it is an interesting piece of work. However, not only will be made more or less obsolete by Schnorr signatures as HeRetiK says,

You're probably right on this. Though, before the Schnorr upgrade is effectively available, the solution we propose can be of help. And (even though irrelevant to Bitcoin) this is applicable to any ECDSA and EdDSA signature for other coins.

First of all, it still requires trust. It is essentially a 2-of-3 system, meaning the "Service Provider" and "Recovery Server" can collaborate to steal the user's funds.

You're technically right. But in real life I believe it's quite difficult that a "Service Provider" (e.g., a company operating in the field) and a "Recovery Server" (e.g., a traditional bank) would collude to steal users funds.

One thing to be aware of though is technology vs operating procedures. In our paper, we identify the "Recovery Server" as a trustworthy third-party entity.
However, from a technological standpoint, nothing precludes to have the "Recovery Server" handled by the user him/herself. In this case, the user is sure that s/he is in full control (having 2 pieces of information out of 3), and it still allows for emergency recovery (e.g., in case of inheritance) with the "Service Provider" if the "Recovery Server" is given to the heirs.