<p>This is how regular wallets work - your public key is used to derive the address to which deposits are made.</p>
<p>However, you can't prevent someone else from depositing to an address once it is shared with them - for instance, you could print the address or put a QR code containing it on your gift card. Once someone receives it, they can look up that address on any blockchain explorer to see the balance.</p>
<p>However, if they can see the address, they can also make a separate deposit to it. There is no way to prevent this.</p>

CC BY-SA 4.0
2022-12-26T23:25:29.110Z
You could implement a new coin type / UTXO flag, and validation rules which restrict other UTXOs from being associated with an address for which such a UTXO already exists. Then after sending such a coin to an address, no more coins can be sent to that address until that coin is spent.
Jivan Pal
CC BY-SA 4.0
2022-12-28T19:52:52.457Z
@JivanPal: Bitcoin nodes today do not care whether a scriptPubKey was reused when validating a transaction. This would be a pretty big change in transaction validation, and require at least a few gigabytes of extra data to keep track of.
Murch
CC BY-SA 4.0
2022-12-30T01:07:59.803Z
@Murch That's not what I'm suggesting. As you rightfully point out, pruned nodes wouldn't be able to prune much at all under what you describe. I am merely saying that if an address has UTXOs (which are *unspent* by definition) of this hypothetical new type associated with it, then the hypothetical new protocol could deem associating subsequent UTXOs with that same address as invalid. Once those UTXOs are spent, the address is fair game again.
Jivan Pal
CC BY-SA 4.0
2022-12-30T01:52:34.523Z
Even if it is only applied to UTXOs that currently exist, these data structures do not exist currently and would take multiple GB to maintain.
Murch
CC BY-SA 4.0
2022-12-30T15:34:06.857Z
@Murch What makes you say that? What additional data structure do you think is required? One merely needs to have an index of the current UTXO set filtered by those of this new type, indexed by the address they are associated with. If *every* UTXO were of this new type, that would be 1.7 GB (85 million UTXOs × 160 bits per UTXO). In practice, only a small subset of UTXOs (easily less than 1 in a thousand) would be of this type, so you're looking at a matter of megabytes.
Jivan Pal
CC BY-SA 4.0
2022-12-30T16:20:38.320Z
20 bytes seems a bit optimistic compared to existing address formats, but other than that your estimates seem reasonable. I would expect little support for a soft fork to introduce only this feature, though.
Murch
CC BY-SA 4.0
2022-12-26T03:46:30.527Z
2022-12-26T03:46:30.527Z
Raghav Sood
<p>According to another user here I am mistaken about how public keys work. I want a customer to have a wallet to which they have a public address to view funds only and I have another public address to deposit to. How can I derive such a key that can view only but not deposit to the public address? I want to make a crypto gift card I can reload and my customers can verify funds.</p>

<private-key>
How can I get a bitcoin address which allows a customer to see funds of their wallet but not deposit? Deposit needs to be done by a 3rd party
Adriano Mancino
# How can I get a bitcoin address which allows a customer to see funds of their wallet but not deposit? Deposit needs to be done by a 3rd party

(Asked by: username_0 on 2022-12-26)

According to another user here I am mistaken about how public keys work. I want a customer to have a wallet to which they have a public address to view funds only and I have another public address to deposit to. How can I derive such a key that can view only but not deposit to the public address? I want to make a crypto gift card I can reload and my customers can verify funds.

**Tags:** private-key


---

## 1 answers

### Answer by username_1 on 2022-12-26. Score: 3

This is how regular wallets work - your public key is used to derive the address to which deposits are made.

However, you can't prevent someone else from depositing to an address once it is shared with them - for instance, you could print the address or put a QR code containing it on your gift card. Once someone receives it, they can look up that address on any blockchain explorer to see the balance.

However, if they can see the address, they can also make a separate deposit to it. There is no way to prevent this.

> **Comments:**
> **username_2**: You could implement a new coin type / UTXO flag, and validation rules which restrict other UTXOs from being associated with an address for which such a UTXO already exists. Then after sending such a coin to an address, no more coins can be sent to that address until that coin is spent.  
> **username_3**: @username_2: Bitcoin nodes today do not care whether a scriptPubKey was reused when validating a transaction. This would be a pretty big change in transaction validation, and require at least a few gigabytes of extra data to keep track of.  
> **username_2**: @username_3 That's not what I'm suggesting. As you rightfully point out, pruned nodes wouldn't be able to prune much at all under what you describe. I am merely saying that if an address has UTXOs (which are *unspent* by definition) of this hypothetical new type associated with it, then the hypothetical new protocol could deem associating subsequent UTXOs with that same address as invalid. Once those UTXOs are spent, the address is fair game again.  
> **username_3**: Even if it is only applied to UTXOs that currently exist, these data structures do not exist currently and would take multiple GB to maintain.  
> **username_2**: @username_3 What makes you say that? What additional data structure do you think is required? One merely needs to have an index of the current UTXO set filtered by those of this new type, indexed by the address they are associated with. If *every* UTXO were of this new type, that would be 1.7 GB (85 million UTXOs × 160 bits per UTXO). In practice, only a small subset of UTXOs (easily less than 1 in a thousand) would be of this type, so you're looking at a matter of megabytes.  
> **username_3**: 20 bytes seems a bit optimistic compared to existing address formats, but other than that your estimates seem reasonable. I would expect little support for a soft fork to introduce only this feature, though.  

---

