Bitcoin Address with only one possible Transfer Destination?

[zappylappy]

Is it possible and if so how, to create a bitcoin address that can only spend to one single predetermined address?

For example: I create a new address 1D2xxxxxx and transfer bitcoin to this address. Now I am only allowed to transfer the bitcoin to the adress 1Ji2xxxxxx.

[1714695114]

1714695114

[1714695114]

1714695114

[1714695114]

1714695114

[BlackHatCoiner]

Now I am only allowed to transfer the bitcoin to the adress 1Ji2xxxxxx.

But if you're only allowed to transfer them to that address, why don't you do it on the first place? Even if you want to confirm for someone that he/she will receive money, you're literally sending them to him/her since you can't spend its funds on a different address.

I don't believe that there's a BIP that included your so-called "unique address spending", because it wouldn't improve Bitcoin at all.

[bob123]

There is effectively no way which does exactly what you are looking for.

But, the good news is that it most likely is not necessary at all.
The majority of things you can think of implementing, someone else has already though of. And therefore the probability that a good solution exists, is relatively high.

What exactly are you looking to do? What are you trying to implement, what kind of mechanism?
I can't think of use cases for what you have described, which can't effectively done with other (available) mechanisms.

[pooya87]

In Bitcoin protocol the only things that are checked in outputs are the amounts (to be <= input total) and count (to be >0). We don't even check if the output script is valid. What you want requires a new OP code that would change this behavior and checks the outputs. But since there is no point in this, as it was mentioned it won't happen.

What you need could probably be achieved by locktime or a multisig or more complicated scripts.
For example you want to pay 1Ji2xxxxxx but want to only let them spend the coin after x time. For this you simply use a OP_CheckLocktimeVerify script.
Or if you want to make sure they fulfill something first, like an atomic swap, etc. you could create a complicated script with OP_IF, OP_Check(Multi)Sig and OP_CheckLocktimeVerify and some hash OPs.

[o_e_l_e_o]

Another (albeit very risky) way you could do this is by signing a transaction and then destroying the private key to that address.

You could send coins to Address A, and then create and sign a transaction which sends all those coins to Address B, but not broadcast that transaction. Back that transaction up, and then destroy the wallet/private key to Address A. Those funds on Address A can now no longer be sent anywhere but Address B, at a time when you choose to broadcast the transaction.

There are a couple of major drawbacks with this. The signed transaction only covers coins already on Address A when you sign it. Any future coins sent to Address A will effectively be burnt and lost forever. There is also the risk that you sign a transaction with too low a fee and then cannot get it confirmed when you need it.

Note, I don't actually recommend doing this. In the words of Satoshi, "You should never delete a wallet".

[zappylappy]

The goal is to apply the concept of Defense in depth, so in case the security controls for address 1D2xxxxxx fail, I want to be sure that bitcoin can only be sent to address 1Ji2xxxxxx. The idea is implemented, in Squares Subzero (https://developer.squareup.com/blog/open-sourcing-subzero/).

"One specific customization we implemented is the ability to enforce that cold wallets can only send funds to a Square-owned hot wallet. Such layering provides defense in depth; forcing an attacker to compromise multiple systems in order to extract funds. It is also possible to build additional layers, where each layer can tradeoff convenience with the amount of funds being stored (onion model)."

[ranochigo]

The goal is to apply the concept of Defense in depth, so in case the security controls for address 1D2xxxxxx fail, I want to be sure that bitcoin can only be sent to address 1Ji2xxxxxx. The idea is implemented, in Squares Subzero (https://developer.squareup.com/blog/open-sourcing-subzero/).

"One specific customization we implemented is the ability to enforce that cold wallets can only send funds to a Square-owned hot wallet. Such layering provides defense in depth; forcing an attacker to compromise multiple systems in order to extract funds. It is also possible to build additional layers, where each layer can tradeoff convenience with the amount of funds being stored (onion model)."

The scheme that they described is implemented on the hardware itself; the hardware is designed such that it only signs transactions that spends to specific addresses. It is totally possible to do something like this, just that as long as you are able to extract the private keys, you will still be able to make a valid transaction and spend it.

Something like this is easily bypassed, as mentioned with the private keys/seeds. We're more concerned about making it impossible to spend funds to other address, which would be marginally more useful though probably not necessary. I don't see the need for something like this as it'll just complicate the entire process even more, if the addresses that the hardware was coded to send to were also compromised.

[NotATether]

~snip

"One specific customization we implemented is the ability to enforce that cold wallets can only send funds to a Square-owned hot wallet. Such layering provides defense in depth; forcing an attacker to compromise multiple systems in order to extract funds. It is also possible to build additional layers, where each layer can tradeoff convenience with the amount of funds being stored (onion model)."

For a security requirement like this, you must use custom wallet software, such as a modified Bitcoin Core, as Electrum is distributed as Python code (except for the .exe) which can be patched to remove such modifications, with a patch that prohibits making a transfer to outgoing addresses except for ones that are allowed.

Then you must apply proper clearing such that nobody including yourself is allowed to, or able to, install other kinds of wallet software on the airgapped systems except for that patched wallet software.

This is the only reliable way to block addresses from being sent to.

[bob123]

The goal is to apply the concept of Defense in depth, so in case the security controls for address 1D2xxxxxx fail, I want to be sure that bitcoin can only be sent to address 1Ji2xxxxxx. The idea is implemented, in Squares Subzero (https://developer.squareup.com/blog/open-sourcing-subzero/).

"One specific customization we implemented is the ability to enforce that cold wallets can only send funds to a Square-owned hot wallet. Such layering provides defense in depth; forcing an attacker to compromise multiple systems in order to extract funds. It is also possible to build additional layers, where each layer can tradeoff convenience with the amount of funds being stored (onion model)."

Actually, IMO this is a completely stupid approach.

In this case, it is completely sufficient for an adversary to only compromise that hot wallet.
There is literally no reason to compromise the cold wallet if the only recipient is that hot wallet. And since hot wallets - by definition - are less secure than cold wallets, the security of the whole setup is the security of that hot wallet (weakest link).


This approach is definitely not recommendable.
If you want multiple layers of security, choose a secret sharing scheme, or additional encryption etc... It completely depends on your setup. But the mentioned approach would actually decrease the security of your whole setup to the security of a hot wallet.

[Theb]

The goal is to apply the concept of Defense in depth, so in case the security controls for address 1D2xxxxxx fail, I want to be sure that bitcoin can only be sent to address 1Ji2xxxxxx.

Since there is no specific way on setting up your wallet to send only to 1 address I think a much more effective alternative is just storing your Bitcoin on a cold storage and when I say cold storage something that is not connected to the internet may it be a hardware wallet or Electrum on an off line pc. In this way you won't have to worry about any attack as long as you keep your private keys and seed phrases secure. Also I don't see any real advantage on this one as you are only limiting your wallet to send on a specific address which is like limiting a feature of a wallet, for instance what if it is an emergency and you have to send Bitcoin on another address? You will just make your life more inconvenient with what you will be doing.

[pooya87]

If you want multiple layers of security, choose a secret sharing scheme, or additional encryption etc... It completely depends on your setup. But the mentioned approach would actually decrease the security of your whole setup to the security of a hot wallet.

Or simply use multi signature where each key is created and held separately instead of one key being in one compromisable place. That way even if the attacker gained access to one key they still have to find the other(s) in order to be able to spend the funds. This can be implemented as hot or cold storage.

[Pmalek]

Or simply use multi signature where each key is created and held separately instead of one key being in one compromisable place.

A partially off-topic question here about Schnorr signatures since you mentioned multisignature keys. If you and I shared a multisig address before Schnorr signatures were officially implemented, could its features (signature aggregation, transaction size reductions) be used with our old multisignature address? Or would we have to create a new one after the BIP gets adopted?   

[pooya87]

Or simply use multi signature where each key is created and held separately instead of one key being in one compromisable place.

A partially off-topic question here about Schnorr signatures since you mentioned multisignature keys. If you and I shared a multisig address before Schnorr signatures were officially implemented, could its features (signature aggregation, transaction size reductions) be used with our old multisignature address? Or would we have to create a new one after the BIP gets adopted?   

NO because Schnorr will most probably be implemented as a soft-fork not a hard fork and since the output script of a "legacy" multisig scheme (usually P2SH) is different than the output script of the new Schnorr signature one (P2WSH with witness version = 1) the coins have to first move to a new address.
It is the same as P2PKH addresses and P2WPKH addresses, they both do the same thing essentially but you can't spend a P2PKH output the same way as you spend a P2WPKH output.