What is the best way to differentiate users' balances in a shared wallet?

first time posting around here. I have been thinking about an application that would highly depend on the use of bitcoin for the best user experience. A shared wallet for all users currently seems like the best option since we're talking about users making multiple micro transactions here (not actual transactions in the bitcoin network), with a database always keeping track of who is entitled to what amount of BTC inside the platform. Users would initially have to send BTC to a shared address, thus "funding" their account. But what would be the ideal way to confirm that a user has sent, say, 1 BTC to the shared address and then associating their account with this specific value in my database? I have been thinking about some solutions but would love to hear from all of you. Thanks in advance!

Rodrigo Veiga

Posted 2019-03-10T22:06:28.153

Reputation: 3

Answers

Creating individualized addresses for each user is the best course of action, it is what the vast majority of services do. Using a BIP 32/44/49/84 HD wallet, you can derive individualized deposit addresses for each user, in a way that is easy to manage through your backend.

Making a single deposit address not only makes it difficult to differentiate between user deposits, it is also bad for the privacy of your users, and your service. Why allow every user that learns your deposit address to know how many coins your service has received over time?

If you are storing user funds you should also be diligent with your backend coin management (ie, you should use proper cold storage methods, to reduce the risk of user funds being stolen). This means you’ll need a system of hot/cold wallets to manage not only deposits, but withdrawals as well. So just using one monolithic address will not be sufficient in this sense either, and this is perhaps even further reason to not build a system with just one deposit address.

If you really need to create just one deposit address, then you could have users sign a message using the private key of the address(es) they sent BTC into the wallet from. This would prove ownership of the deposit ina cryptographically secure way. However, the vast majority of user-friendly wallets do not provide a message-signing functionality, so it would significantly hurt UX and usability of your platform to require this. My guess is that many BTC users will likely not have any idea how to sign a message like this in the first place.

chytrik

Posted 2019-03-10T22:06:28.153

Reputation: 10 276

Nitpick: BIP39 is the mnemonic encoding, derivation is done by BIP32/44/49/84 – Raghav Sood – 2019-03-10T23:45:41.170

@RaghavSood ahh whoops! Lazy mistake, I’ve edited my answer – chytrik – 2019-03-11T11:03:02.807

A workaround on that one would be to follow a method most centralized exchanges have been following. You create a unique BTC public address for each user and maintain their private keys (you could use a HD wallet for generating these addresses.) At regular intervals (say once a day or even more frequent based on the volume of users you have) you transfer the UTXOs from the user to a master account.

With the help of this method you have solved both problems. First, you can track the BTC that is sent by the user (since it would be sent to his unique address). Second, in your internal database, you can just credit the user's account by the appropriate number of BTC once it is sent and then debit/credit it as transactions are received. You need not physically do these transactions on the Bitcoin blockchain, just in your internal database. At the time when the user wants to withdraw the funds, your software can just sign that transaction and allow the user to withdraw the amount that he is owed.

Although, I have mentioned a workaround, it is due to the nature of the question that you asked. This method is not recommended. Controlling funds in a centralized way destroys the very basic fabric for which bitcoin was founded. The current best ways for doing micro payments without sacrificing the necessary decentralizing is through sidechains, using solutions like Lightning Network. You can read more about it here (description is not the basis of the question).

Ugam Kamat

Posted 2019-03-10T22:06:28.153

Reputation: 5 180

Your workaround is pretty similar to what I've been looking at recently. But this would essentially mean two transactions for every deposit, right? Doesn't seem very efficient, especially when bitcoin tx fees are booming.

And definitely, utilising Lightning Network would be ideal for my application. But I would rather wait for it to mature a bit to get my hands dirty with it; in the meanwhile, I would like to acquire more solid bitcoin core programming experience. – Rodrigo Veiga – 2019-03-10T23:15:42.810

Yes, true you would need two transactions. But when you are transferring BTC associated with user's address to the main address, you could use a lower fee as that transaction would not be time sensitive. – Ugam Kamat – 2019-03-10T23:28:26.920

What do you mean it wouldn't be time sensitive? – Rodrigo Veiga – 2019-03-11T01:09:11.380

The second transaction step where you will be consolidating the BTC associated with disparate addresses, is not that time sensitive as the first one. – Ugam Kamat – 2019-03-11T01:11:42.440