Safely storing newly created wallets programmatically?

[QuickAccount]

I'm working on a project that creates a new wallet for the user that is not controlled by them, what would be the safest option for storing newly created private keys programmatically?

Currently, this is what I implemented: Creates new wallet with user-input randomness coupled with server side randomness, encrypts the private key with a password that is stored offline, clears the non-encrypted private key from memory, then writes the encrypted private key to the database.



What can I improve or change?

[Charles-Tim]

A wallet that is not controlled by the user? You mean a custodial wallet? A wallet that I can never recommend anyone or advise anyone to use.

Or a web wallet like Blockchain.com in a way that the user will also be able to have full control? The private key are encrypted online in a database. I can not also recommend or advise anyone to use it.

I prefer wallets that users can be able to generate their keys offline just like Electrum, Sparrow and Bluewallet.

[QuickAccount]

It's a casino-type platform where players can play against eachother, if they were able to control their own keys they would be able to run off if they lost to others

[odolvlobo]

Implementing an on-chain casino is probably not going to work very well if every bet involves a transaction. Maybe you can implement it on the Lightning network instead.

Otherwise, you are probably better off holding player balances in a database and have deposits and withdrawals go through the casino's wallet.

[ABCbits]

What can I improve or change?

Since it's for business usage, i would make these suggestions.
1. Do some research on TEE (trusted execution environment). It's feature provided by CPU or SoC to manage sensitive data more securely, although some people distrust it due to various reason (e.g. consider Intel ME as a backdoor or security issue).
2. Unencrypted swapfile bring security concern, since sensitive data may be stored there temporarily.

Although i agree with @odolvlobo to simply have few casino's wallet and database which track user's balance along with it's changes, since your user currently doesn't have access to their private key anyway.

[QuickAccount]

Implementing an on-chain casino is probably not going to work very well if every bet involves a transaction. Maybe you can implement it on the Lightning network instead.

Otherwise, you are probably better off holding player balances in a database and have deposits and withdrawals go through the casino's wallet.

All bets are done server side with random.org, I've implemented user wallets so that transaction fees are lower

What can I improve or change?

Since it's for business usage, i would make these suggestions.
1. Do some research on TEE (trusted execution environment). It's feature provided by CPU or SoC to manage sensitive data more securely, although some people distrust it due to various reason (e.g. consider Intel ME as a backdoor or security issue).
2. Unencrypted swapfile bring security concern, since sensitive data may be stored there temporarily.

Although i agree with @odolvlobo to simply have few casino's wallet and database which track user's balance along with it's changes, since your user currently doesn't have access to their private key anyway.

I looked into this and this is exactly what I was looking for, you're right about the INTEL ME backdoor I worry about, but due to the processor I use I can mount additional firmware and hopefully make a solution that doesn't piggyback on preexisting TEE on the CPU. Will keep the thread updated if I have any more questions.

[Cricktor]

I've implemented user wallets so that transaction fees are lower

How do user wallets make transaction fees lower? I assume you would have a transaction from casino wallet to user wallet for payout which the casino pays? And for withdrawal from user wallet to user's own personal wallet the user may be able to choose transaction fee rate based on his needs (guided by reasonable fee rate suggestions according to current mempool state)?

[LoyceV]

All bets are done server side with random.org

That doesn't sound provably fair.

How do user wallets make transaction fees lower?

I think OP confuses the meaning of "wallet" and "account". Considering the kind of questions he asks, I don't think he should be building a casino.

[apogio]

Creates new wallet with user-input randomness coupled with server side randomness

Can you please elaborate on this? How does the user provide randomness? How does the server couple the randomness with user input?

encrypts the private key with a password that is stored offline

Is this a raw password? Do you keep the raw passwords anywhere?

If so, this needs some sort of amelioration.

You should apply a hash function on the raw password and then encrypt the key with the result of the hash.

So instead of doing:

Code:

raw_pass = 1234Pass
priv_key = 3bfc9f8ec64e3b1b0c34b12df9a95ee794287ba99b5b46f1880592e237486d9a
enc = encrypt(priv_key, raw_pass)

you should do:

Code:

raw_pass=1234Pass
priv_key = 3bfc9f8ec64e3b1b0c34b12df9a95ee794287ba99b5b46f1880592e237486d9a
sha_256(raw_pass) = fc922ba852f16657615f7eecd50451dae563184c54cc08021fb6c732e1ca0cf6
enc = encrypt(priv_key, sha_256(raw_pass))

[odolvlobo]

Currently, this is what I implemented: Creates new wallet with user-input randomness coupled with server side randomness, ...

Allowing the user to contribute entropy to the private key generation creates a weakness if they can gain information about what they contributed.

[apogio]

Allowing the user to contribute entropy to the private key generation creates a weakness if they can gain information about what they contributed.

That's exactly why I asked! Randomness should be system-provided and then what the user should be responsible for deciding is the amount of security they will provide upon this randomness using a strong encryption password.

[odolvlobo]

Allowing the user to contribute entropy to the private key generation creates a weakness if they can gain information about what they contributed.

That's exactly why I asked! Randomness should be system-provided and then what the user should be responsible for deciding is the amount of security they will provide upon this randomness using a strong encryption password.

You wrote before that you don't want to give the user control of the address, so private key generation must be completely out of their hands. I don't understand the point of giving the user the ability to determine the level of your security.

Maybe 2-of-3 multisig is the approach you are looking for. You have 2 keys so you have complete control, and the user has 1 key so they can spend with your approval.

[MusaMohamed]

I'm working on a project that creates a new wallet for the user that is not controlled by them, what would be the safest option for storing newly created private keys programmatically?

A wallet that its user does not control it, don't fool me, but maybe you did not express your idea correctly as you wanted.

It's your private key, it's your bitcoin and it's not your private key, it's not your bitcoin. Your wanted wallet is like custodial wallet, that does not give its user private key, and don't give any bitcoin to their user technically.

I don't want to make you sad, but it is not a good and safe wallet for Bitcoin users.

https://www.youtube.com/watch?v=AcrEEnDLm58
https://www.lopp.net/bitcoin-information/recommended-wallets.html

Wallet Basics:

Do not use wallets that don't give you recovery data; these wallets are likely controlling your keys.
Do not use paper wallets unless you're an advanced user who understands all the risks.
Do not store large amounts of value in single signature wallets.
Make sure your heirs know how to recover your wallets without you!

Your wallet is likely controlling keys and users are not controlling keys.

[apogio]

You wrote before that you don't want to give the user control of the address, so private key generation must be completely out of their hands. I don't understand the point of giving the user the ability to determine the level of your security.

Maybe 2-of-3 multisig is the approach you are looking for. You have 2 keys so you have complete control, and the user has 1 key so they can spend with your approval.

Sounds good, but how do crypto casinos work today? If I have your username and password and log in, can I withdraw your funds? I am almost certain I can, but I don't really use gambling sites anymore, that's why I ask.

[LoyceV]

Allowing the user to contribute entropy to the private key generation creates a weakness if they can gain information about what they contributed.

It sounds like OP is confusing the client seed for the casino part with the private key for the deposit address. The former makes sure the casino can't cherry-pick their server seed and thus cherry pick the random results. The latter makes no sense, users have nothing to do with the private key on deposit addresses (it's not their wallet).