Topic: Wallet Features That Are Missing but Essential (Read 314 times)

Not necessarily. You could use something like:


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

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.

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.

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.

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.

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

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.

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.

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).

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.

Because you can essentially achieve the same outcome already if you are technically minded, as we have discussed in this thread. A multi-sig set up with with the child holding one key and sending a PSBT to their parent for approval and broadcasting does the same thing, with the added bonus of being completely non-custodial, not requiring any third parties, being more secure, being more private, and you can increase the number of shares if you want to have other people involved or other back ups.

Any user who wants to run a system like this and is capable of doing so will simply do so as described above. To turn all this in to a centralized process, which will no doubt track your usage and collect your data to sell to third parties, is the kind of thing you would expect from the usual suspects. Perhaps I should have said Coinbase instead of Google, but the point still stands.

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

Why Google? I would like to think any wallet could do it with some back end work.

What I envision is you have 'X' number of devices when you create the wallet.
When you setup that spend wallet you give it all the phone #s of the other wallets and / or some other device id information for push.

The 'spend' wallet has code in it that requires a push alert or SMS code before signing.
When it goes to sign a transaction, it either sends out a mass text or contacts a server that does a push notification to all the other listed wallets.
All it needs to sign (or show the private keys / seed) is a yes response from one of the other devices.

You don't have to use their server to do the push if you are OK with SMS.
You don't have to use SMS if you just want to use their server, and in an ideal world it's open source so you could setup your own server.

Banks have done this for YEARS with CC processing. Citibank (at least I think it's Citi could be BoA) has corporate card settings where you can spend up to X without others getting notified. At Y dollars certain people get a text / email / alert. And at Z dollars the transaction will not be processes till someone hits the green button marked OK. XYZ are all editable by corporate accounting.

Why not the same here? Why get big brother involved?

-Dave

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.

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.

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

Sounds like something Google will come out with in due course.

I would not trust my parents to do it either. BUT, at a guess we are both 'older' and we would be the parents and our parents would be the grandparents.

Makes you wonder if there is a need for something like linked mobile wallets.
The other phones / tablets would need to be connected with the app running in the background all the time.
Person A tries to spend. Everyone else gets a popup that they tried to send a transaction approve Y / N

Zero privacy and subject to needing data / ability to send receive SMS but an interesting concept.
For the really paranoid parents / employers you could geo tag where the sender is.

As far as I know nothing like that exists, but might be an interesting thing to see if people would want it.

-Dave

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.

In my example, only two people were mentioned, but in reality, the number of people involved could be in the dozens, and there could be more than one required person making the request, and more than one person required to approve the request, and these people must come from distinct groups of people. Say for example, there is a team of 24 team members managed by three managers. The company might require that three employees request a transaction, and it must be approved by two managers. The employees could have a 3 of 24 secret that could be one of two secrets that are required to access a private key. Each of the three managers could have one secret that is part of a 2 of 3 secret that would e the other of the two secrets required to access the private key.

Having 24 team members would not be possible with multi-sig, and requiring a certain number of signatures from y distinct groups is also not possible with multi-sig.

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.

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 will change with taproot, but currently, multi-sig requires more block space.

If certain security measure are taken to ensure no one has physical access to the computer, and that anytime someone accesses the room where the computer is physically located that power is cut to the computer (wiping its RAM), an alternative might be to SSH, or otherwise remotely connect to the computer with the script that calculates the private key. This obviously comes with the pitfalls related to keeping your private keys on a non-airgapped computer. You might be able to reduce the risks somewhat by keeping the computer on a private network, and restricting which computers can connect to the private network.

Without allowing SSH/remote access to the airgapped computer, precautions could be taken to prevent a "smash and grab" theft, such as bolting the computer to the ground, remote camera monitoring of the room the computer is located in, and being required to be "buzzed" out of the room when you have signed the transaction, and probably others.

Not necessarily.

Let's say I want to set up an inheritance between my partner and 3 children. 4 shares in total, but I want some redundancy in the system in case something happens to one of them, so I want a 3-of-4 system. I create a 3-of-4 multisig, and for my 4 back ups I create the following:

Back up 1: Seed A, xpub B
Back up 2: Seed B, xpub C
Back up 3: Seed C, xpub D
Back up 4: Seed D, xpub A

I then hand out one back up to each of my family members. No family member has any idea how much bitcoin is stored in the multi-sig wallet, but any three shares contains enough information to fully recover the 3-of-4 multisig wallet.

o_e_l_e_o was just suggesting an alternative in case the kid doesn't have both parents. If one of them is deceased, divorced, imprisoned, etc. I mentioned that the mom could hold one key while the dad has possession of the other. But if the kid has only one parent, a grandparent, uncle, trusted friend, etc. could take the place of the missing parent. It would still be the parent/s who are depositing money into the account for their child to spend, so that part remains the same.

But in your scenario, if the grandparent held one of the private keys, he could prevent the parent from stealing coins that were meant for the grandchild. I understand what you were trying to say.   

The only advantage of Shamir secret sharing I had ever thought of is for inheritance purpose in which the hires will not know the exact amount of bitcoin in connection to the seed phrase. If multisig wallet is used which is better, but the bitcoin in connection to the seed phrase will definitely be known to the hires.

But Shamir secret sharing is not advisable, first because it is not part of BIPs, second because it is made up of characters like private keys (although, not private keys), just like what has been implemented before in BIP (master private key) that was converted to seed phrase which is easy for backup, I do not see any good reason to backup characters as they are hard to put down.

Oh yes, very valid point! Kid could receive money from grandparents and then a parent grabs it since they 'need it' or something like that.

I don't understand why people keep recommending Shamir if we can have multisig. It has so many downsides; just a few in the example from Quickseller:

* both entities must be at the same place & same time
* way more complex (need airgapped computer, load keys on it, etc.)
* way less secure (full private key will be on that machine in that moment - one can grab it and run etc.)
* much more knowledge required (verify the drive is wiped and all those steps)

It also prevents one parent "going rogue" and stealing all the kids' money. There are plenty of horror stories out there of parents spending their kids' birthday or Christmas gifts, savings, college funds, etc., on themselves. If there are not two parents in the picture, then perhaps a grandparent or family friend could hold the other key. Kid and parent can make a purchase, with kid and grandparent as a backup if something happens to the parent.

The problem with 2FA codes are their 30 second time limit. Any kind of network delay between the parent sending the code to the child and it will no longer be valid by the time the child copies it in. And I don't know about your parents, but I wouldn't trust mine to be able to copy and paste a code in to a message and send that message in anything under 30 seconds.

What benefit does this have over a 2-of-2 multisig?