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?

A better use case might be an employee having a budget, but needs some kind of approval from his boss to spend any money.

Realistically, the best solution would be a watch only wallet in a way somewhat similar to how n0nce described above. Although this scenario would mean that the boss, or approving authority would have complete control over the private keys.

If you want to guarantee that the "approver" cannot spend on their own, an alternative might be to implement shamir shared secret. The workflow might be as follows:
*The employee proposes a transaction
*The approver reviews and approves the transaction
*The transaction is loaded onto an offline computer
*The employee and approver review the transaction to confirm it is the same as the one being proposed/approved
*The employee and approver loads their secret onto the offline computer, which passes both secrets through a script that takes the following as inputs:
~secret 1
~secret 2
~transaction to be signed
*The script outputs the signed transaction, and the signed transaction is transmitted back to the employee who broadcasts the transaction to the bitcoin network
*The employee and approver both personally confirm that the RAM is cleared/wiped from the offline computer, removing their respective secrets from said computer

Electrum 2fa will work with the 2fa part being on the parents phone. Note 2fa not sperate multisig.
There are some custodial wallets that will allow for this, they need a Google Authenticator to send which does not need to be on the same phone.

They wont know how much their kid is spending, but they have to ask to spend it. And they will immediately see the transaction.

--------------
I might get flack for this but I think although the idea is good, the reason they want it is bad.
You are teaching the kid who wants the candy (or whatever) that there is a 2nd layer of security with BTC that in the real world is not there.

If you give your kid $20 allowance a week in cash and they loose that $20 bill it's gone, and they learned to protect their money.
Now you are just showing them that mom and dad are going to protect their BTC. That's not the way the world works.
Just my view, feel free to think I'm an ass about it.

-Dave

Yeah; sure, but I guess same could be true if the child asks the parent for a 2FA code via SMS and in reality the child's phone is compromised and it's someone else. The parent also sees destination and amount on their phone before signing, so if it's something beyond the occasional $5 candy purchase, they will should get suspicious.

I really like this option; actually prefer it over the one I suggested myself, because here both parents can sign, for example if sometimes one is at work, sometimes the other and stuff like that. Do note that 2-out-of-3 can be done with 1, 2 or even 3 hardware wallets as well.

Some hardware wallets (like Keystone) are working like this and you can only view seed words when you generate them or when you manually import them, after that they stay locked on device and you can't show or export them.
Note that for some other hardware wallets (Coldcard and others) you can simply click view and see seed words on the screen.

I wouldn't use 2FA in any wallet for sending coins and especially if it is connected with phone number.

Best option is to create some kind of multisig wallet, so that users of both wallets would have their own strong password, and nobody could send any coins unless both of them sign transactions.
Both of them could see the balance and you could even including more people in your multisig but it would increase complexity and transaction fees.

With what I have read about OP, I think he never known much about multisig wallet, he needs nothing more than a multisig wallet. Why did he needs a wallet that will not be able to reveal seed phrase ever again after wallet creation? Just because he wants to be secure and safe, but having 2-of-3 multisig suggested by Pmalek is enough with this in which also the 2fa he is requesting for is not needed.

If 1 key is compromised and the other two are not compromised, then the multisig setup is still safe even if two keys are compromised with nothing compromised about the third key, while it is best to make another multisig wallet and send all the funds to the wallet if any hack is noticed. While also best to be security conscious and making sure the parties involved are maintaining a safety standard.

Try and learn more about multisig wallet, it is all you need. Know that you can even use it on hardware wallets like Trezor and Ledger Nano which keeps your seed phrase offline. Also if the transaction fee is discouraging you, know that taproot activation is in less than 2 weeks from now, this will make multisig transaction fee the same as single public key wallet fee, let us expect reputed wallet to upgrade to it so we can enjoy low fee even with 15-of-of-15 transaction.

It's not what you wanted, but why not a 2 out of 3 multisignature wallet where the child has access to one key and the parent (admin) controls two other keys? You could even divide the keys further so that the mommy and daddy control one key each. If the child wanted to spend from the wallet, he/she needs a signature (permission) from mommy or daddy.  

There is no point in removing this feature from wallets.
Your wallet (assuming it is not watch-only) needs to be able to produce new keypairs anytime it needs to. In order to do that, the wallet requires the "master key" which is the "extended private key" usually starting with xprv. This master key is derived from your "recovery words" so not storing those words provides no security but storing them provides a useful option for users who may lose their physical backup and want to write down their words again.

The flaw in this idea is the communication part. Now the "admin" has to have a way to trust the PSBT file they receive. For example if it is done over the internet then anybody can create a PSBT and ask for payment pretending to be the user.

I don't know of such a wallet, and I understand your use case. However, that can be accomplished already in a slightly different way.

The non-privileged user can have watch-only access by running a watch-only wallet. This user can see the balance and generate addresses to receive BTC on, but cannot spend, since such a wallet holds no private keys at all. For spending, the user creates a PSBT, which it then has to send to someone who does hold the private key and signs the transaction for them.

For the scenario of parent / child, it may be easiest that the parent uses a hardware wallet like ColdCard or Passport, since these are made for such an airgapped application out-of-the box basically. The kid would take the PSBT which the watch-only wallet gives as a file or QR code, sends it to the parent, the parent scans / imports it into the hardware wallet and sends back the signed PSBT or submits it to the blockchain themselves.

This sending back and forth the PSBT is essentially what you were looking for with 2FA codes. Same amount and rounds of communication, but other data. It is physically not possible to solve it with (admittedly, shorter, easier to share) 2FA codes, since this would mean the 2FA is just securing the application's access to the seed words, but they are still in the hands of the child. My recommendation, using watch-only wallet for the child and sending back & forth PSBT's instead of 2FA codes, is cryptographically secure and implemented already.

For day-to-day usage, Passport will be easier than ColdCard, since it has a camera. The kid will be able to take a screenshot of the QR code that the watch-only wallet (e.g. in BlueWallet) displays; send it to the parent. Then the parent scans that QR code directly with the Passport, scans the Passport's signed QR code with their own phone and sends it out to the Bitcoin network.

Hello,

I have been looking for a crypto wallet that only shows you the recovery words once during the creation of the wallet. After that I want the wallet to NOT be able to show me the recovery words. Almost every wallet has a section where it says view recovery words and you put a pin/passcode or whatever and it reveals your 12/24 word recovery.
Is there a wallet that supports this? And if there is, is there a wallet that requires 2FA (google auth) to send crypto out? I know some wallets have 2FA but it's useless if you could just bypass that by clicking on the view recovery words lol.


Goal:

Basically, I am trying to have a wallet that has 2 users with 1 of the users being the admin essentially. User 1 (admin) creates the wallet and stores the recovery words offline or whatever. User 2 has access to the wallet but can only send crypto out with 2FA obtained from User 1. A pin won't work because then withdrawals can be done whenever User 2 wants, the withdrawal basically has to be agreed by both but User1 with more power per see.


Use Cases:

If a parent wants to monitor kids spending (considering crypto is used as dollars would be in this scenario) then the kid takes out his phone checks his app to see if he has enough money for the candy he wants then pays with his crypto but to send it she needs to call mommy or daddy to get the OTP (google auth) code to be able to send. A pin/passcode lock would enable the child to buy candy whenever she wants and if the wallet app reveals your recovery words the child will just recover her words in another wallet.


Anybody seen a wallet/app that supports any feature described above?