Wallet Features That Are Missing but Essential

[Quickseller]

I would echo Dave's concerns about "protecting" children's money. If your child is growing up, as a parent, you need to "let" them fail so they will learn.

Maybe, maybe not. Maybe I would be ok with my kid losing their monthly allowance of 0.0025 BTC so it teaches them a lesson about a security, but I don't want them to lose their college fund of 2.5 BTC.

A college fund is for well, college. As such, the child should not have access to his or her college fund until he or she is old enough to attend college. At that point, he or she will hopefully learned how to sufficiently protect his or her money.

So I guess a 2-of-2 multi-sig would be better than my simple example, but shamir shared secret is superior to more complex scenarios that might be more realistic in the corporate world.

I disagree. A 2-of-2 multi-sig is obviously better in the example discussed above, but in more complex scenarios I fail to see any corporate entity setting up a 3-of-24 SSS and a 2-of-3 SSS, and combining them in to a 2-of-2 multisig as you have described. You need either everyone working in the same office, or you need to take significant additional and costly security precautions and yet still expose yourself to significant additional risks. It is far more complex to set up and far more cumbersome to use. More likely is that employees would simply send a written request to the managers (maybe even signed with their PGP keys for authenticity purposes), who would then approve the request and sign a transaction from their managerial x-of-y multisig.

At a bank, in order to access cash, you must have one person from one set of employees, and another from another set of employees to open a vault/safe (some employees are assigned a small amount of cash they are personally responsible for so they can handle smaller transactions).

Employee turnover is another risk to multi-sig. Anytime an employee leaves the company (especially if they are fired), the company would need to move their bitcoin to a new multi-sig address to reduce the risk their bitcoin will be stolen by a combination of rouge ex-employees.

This applies equally to SSS. A quorum number of ex-employees could combine their secrets to recover the wallet.

With SSS the setup could be as follows:
A 3-of-24 SSS unlocks 1 of a 2-of-2 SSS secret[1]
The 2-of-2 SSS secret named "[1]" above is used to unlock a second 2-of-2 SSS secret[2] that is the private key(or xprvkey).
The second secret needed to unlock [1] is stored on the computer kept in a secure location in which it is difficult for employees to access.
The second secret needed to unlock [2] can be derived from a 2-of-3 SSS used by a different group of people (such as the managers)
In the event an employee leaves the company, a new 2-of-3 SSS[3] is created with one being the output of a new 3-of-24 SSS, one being stored on the above described computer, and one being destroyed.
After [3] is created, the secret for [1] is destroyed on the above described computer.
Alternatively, [3] could be a 3-of-3 SSS in which two of the 3 secrets are stored on the above described computer, and one is derived from the new 3-of-24 SSS for the employees.

As long as the old secrets stored on the above described computer are destroyed, it would be impossible for former employees to use their secrets to get any meaningful information.

[o_e_l_e_o]

A college fund is for well, college. As such, the child should not have access to his or her college fund until he or she is old enough to attend college.

Replace college fund with savings account or something similar then. You might want them to be able to spend their money on something useful they have saved up for like a new computer, but you don't want them to be able to blow it all on beer for the weekend. My point is although you might not have a use case for it, someone else will.

At a bank, in order to access cash, you must have one person from one set of employees, and another from another set of employees to open a vault/safe (some employees are assigned a small amount of cash they are personally responsible for so they can handle smaller transactions).

Which can all be achieved more securely with multi-sig than it can with SSS.

With SSS the setup could be as follows:
A 3-of-24 SSS unlocks 1 of a 2-of-2 SSS secret[1]
The 2-of-2 SSS secret named "[1]" above is used to unlock a second 2-of-2 SSS secret[2] that is the private key(or xprvkey).
The second secret needed to unlock [1] is stored on the computer kept in a secure location in which it is difficult for employees to access.
The second secret needed to unlock [2] can be derived from a 2-of-3 SSS used by a different group of people (such as the managers)
In the event an employee leaves the company, a new 2-of-3 SSS[3] is created with one being the output of a new 3-of-24 SSS, one being stored on the above described computer, and one being destroyed.
After [3] is created, the secret for [1] is destroyed on the above described computer.
Alternatively, [3] could be a 3-of-3 SSS in which two of the 3 secrets are stored on the above described computer, and one is derived from the new 3-of-24 SSS for the employees.

Which is a ridiculously complicated scenario, even more so when you start needing to replace some secrets. As I said above, this overly complicated scenario is far more error prone and far more likely to lead to information being leaked or accidentally exposed, even before you consider the many inherent weaknesses in SSS when compared to multi-sig.

[Quickseller]

At a bank, in order to access cash, you must have one person from one set of employees, and another from another set of employees to open a vault/safe (some employees are assigned a small amount of cash they are personally responsible for so they can handle smaller transactions).

Which can all be achieved more securely with multi-sig than it can with SSS.

Multi-sig treats all signing keys equally. So the only way to implement forcing two different groups of people needing to sign is via a 2-of-2 multi-sig with all members of each group sharing the same key.

With SSS the setup could be as follows:
A 3-of-24 SSS unlocks 1 of a 2-of-2 SSS secret[1]
The 2-of-2 SSS secret named "[1]" above is used to unlock a second 2-of-2 SSS secret[2] that is the private key(or xprvkey).
The second secret needed to unlock [1] is stored on the computer kept in a secure location in which it is difficult for employees to access.
The second secret needed to unlock [2] can be derived from a 2-of-3 SSS used by a different group of people (such as the managers)
In the event an employee leaves the company, a new 2-of-3 SSS[3] is created with one being the output of a new 3-of-24 SSS, one being stored on the above described computer, and one being destroyed.
After [3] is created, the secret for [1] is destroyed on the above described computer.
Alternatively, [3] could be a 3-of-3 SSS in which two of the 3 secrets are stored on the above described computer, and one is derived from the new 3-of-24 SSS for the employees.

Which is a ridiculously complicated scenario, even more so when you start needing to replace some secrets. As I said above, this overly complicated scenario is far more error prone and far more likely to lead to information being leaked or accidentally exposed, even before you consider the many inherent weaknesses in SSS when compared to multi-sig.

Most of the above can be automated, including the replacing of the secrets. It also allows for logging of who is signing off on transactions, which is not possible using a 2-of-2 multisig when keys are shared.

[o_e_l_e_o]

Multi-sig treats all signing keys equally.

Not necessarily. You could use something like:

Code:

<manager pubkey> OP_CHECKSIGVERIFY OP_1 <employee pubkey 1> <employee pubkey 2> <employee pubkey 3> OP_3 OP_CHECKMULTISIG

This will essentially create a 2-of-4 multsig, but it requires the manager to be one of those two.

It also allows for logging of who is signing off on transactions, which is not possible using a 2-of-2 multisig when keys are shared.

Can you elaborate? In your example, any 3 of the 24 SSS shares will recover the same secret. You don't know if A+B+C combined to recover the secret or if it was D+E+F.

[Quickseller]

Multi-sig treats all signing keys equally.

Not necessarily. You could use something like:

Code:

<manager pubkey> OP_CHECKSIGVERIFY OP_1 <employee pubkey 1> <employee pubkey 2> <employee pubkey 3> OP_3 OP_CHECKMULTISIG

This will essentially create a 2-of-4 multsig, but it requires the manager to be one of those two.

If you do that, you must have a single manager and cannot have one of multiple managers sign off on a transaction.

You are also limited to one mandatory person and a second group of people. With SSS, you can have an arbitrary number of groups of people required to access the ultimate secret.

It also allows for logging of who is signing off on transactions, which is not possible using a 2-of-2 multisig when keys are shared.

Can you elaborate? In your example, any 3 of the 24 SSS shares will recover the same secret. You don't know if A+B+C combined to recover the secret or if it was D+E+F.

In my scenario, a company computer most be used to access the secret. Using a computer that is not the specific computer designed by the computer to calculate the secret will result in useless information. This allows the company to log any transactions that are signed, including which employees are approving the transaction.

This is not cryptographically provable, however the same can be said about other business records generated by companies. 

[pooya87]

If you do that, you must have a single manager and cannot have one of multiple managers sign off on a transaction.
You are also limited to one mandatory person and a second group of people.

You are only limited by your imagination and understanding of how bitcoin smart contracts work. You can create almost any scenario you can think of very easily. For example if you wanted to add multiple managers to the above script you simply turn the CheckSigVerify to CheckMultiSigVerify OP.

you can have an arbitrary number of groups of people required to access the ultimate secret.

At some point things stop making sense. For example how many "groups of people" should have access to your money?! In most cases it is not more than 2, anything more complex may need much simpler solutions with better security such as splitting the money between smaller delegates.

[o_e_l_e_o]

If you do that, you must have a single manager and cannot have one of multiple managers sign off on a transaction.

You are also limited to one mandatory person and a second group of people. With SSS, you can have an arbitrary number of groups of people required to access the ultimate secret.

So you change OP_CHECKSIGVERIFY to another OP_CHECKMULTISIG as pooya has said, and then you can have one of three managers and two of three employees needed. Maybe you use OP_IF combined with another OP_CHECKMULTISIG to make it so two managers together can bypass the employee requirement, or OP_IF with OP_CHECKSIGVERIFY to make it so one director on their own can bypass all the managers and employees. Or maybe you use three OP_CHECKMULTISIGs to create three 1-of-3 set ups together, so you need one employee from three different groups.

In my scenario, a company computer most be used to access the secret. Using a computer that is not the specific computer designed by the computer to calculate the secret will result in useless information. This allows the company to log any transactions that are signed, including which employees are approving the transaction.

So you set up the multi-sig as above to absolutely require one signature which is stored only on a company computer, and set it up so the company computer will not accept PSBTs but will only accept unsigned transactions and employees connecting their hardware wallets to sign with their relevant keys.

Anything that is possible with SSS is possible with multi-sig, and multi-sig is a much safer way of doing things.

[Pmalek]

hmmmmmm I've seen blue wallet have a similar option that doesnt reveal the "correct" recovery phrases on purpouse

What do you mean on purpose? So if I had a Blue wallet, and I wanted to check my seed (for whatever reason), the software would show some random words (aka a fake seed) and not my actual seed? Why would it do that? Could I still bypass it and have the client display my real mnemonic as well by entering another password or removing that feature in the settings?

It actually doesn't sound that bad when you think about. You enable a feature that displays a wrong seed. If someone were to get hold of your wallet file + password, he wouldn't be able to spend from the wallet or display its seed without a secondary spending password. Some exchanges use a trading or withdrawal PIN that is independent of your password.

[Quickseller]

CheckMultiSigVerify OP

So you change OP_CHECKSIGVERIFY to another OP_CHECKMULTISIG as pooya has said,

You're right. I had not considered that.

Although you are still limited as to how many potential signers there are in a script (this is my understanding), and there is still the issue of having to change keys whenever an employee leaves, and changing keys with multi-sig means that a transaction is required, including the cost of said transaction.

Also, the employees need to be in a location specified by the employer in order to sign a transaction when using SSS with my setup. If a group of employees are fired for misconduct, as long as you can keep them outside of the room containing the computer used to sign transactions (and otherwise limit their access to said computer), your private keys are safe.

In my scenario, a company computer most be used to access the secret. Using a computer that is not the specific computer designed by the computer to calculate the secret will result in useless information. This allows the company to log any transactions that are signed, including which employees are approving the transaction.

So you set up the multi-sig as above to absolutely require one signature which is stored only on a company computer, and set it up so the company computer will not accept PSBTs but will only accept unsigned transactions and employees connecting their hardware wallets to sign with their relevant keys.

If you are using multi-sig without sharing keys, the company could just look at the blockchain, specifically the signature of the transaction to see who signed the transaction.