Bitcoin Forum

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?

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 (https://bitcoinelectrum.com/creating-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 (https://en.bitcoin.it/wiki/Partially_signed_bitcoin_transaction), 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 (https://bitcointalk.org/index.php?topic=5033058.0) or Passport (https://bitcointalk.org/index.php?topic=5265233.0), 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.

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.

Technically nobody should ever have access to your device otherwise you have more serious things to worry about.
Additionally 2FA that only lets you enter the wallet and access the keys is not going to help either. If the wallet is encrypted it is already secure and if you want additional security you can use multi-signature schemes where more than one signer is needed to spend coins and keep each signer on a different device.
For example one wallet on your phone has 1 key and the other wallet on your PC has the another key making a 2of2 multi sig.

You can build this script and this type of wallet easily using Electrum.

User creates the transaction and signs it with their own key then sends it to the "admin" so that they can sign and broadcast it if they wanted to allow the coins to get to that destination.

This script could change to add more ability to the "admin" and let them spend coins without the user's permission by adding a condition:

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.

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.  

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.

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.

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.

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

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 (https://bitcointalk.org/index.php?topic=5369424.msg58357191#msg58357191) 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

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. :P

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

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)

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.

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.   

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.

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.

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

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.

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

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

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.

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.

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.

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.

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.

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.

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. 

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.

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.

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.

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.

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.

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.

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.