Is there a way to only make BTC spendable to white listed addresses?

[thefreshprinceofbell]

I was thinking about how online banking works today.  They don't really have to worry about security because you can only wire to pre approved payees. 

If a company like Apple was to one day allow BTC to be held natively they wouldn't want transactions to be able to be sent anywhere.  One Webkit exploit combined with userland root access and hundred of millions users wallets are empties instantaneously.

But if the BTC are somehow held in a way that they can only be send to white listed addresses their is recourse for users.

Is there anyway this can be accomplished on the blockchain?

[Upgrade00]

If a company like Apple was to one day allow BTC to be held natively they wouldn't want transactions to be able to be sent anywhere.  One Webkit exploit combined with userland root access and hundred of millions users wallets are empties instantaneously.

Why would anyone want to store their funds on a company's server which would hold the private keys of their address

But if the BTC are somehow held in a way that they can only be send to white listed addresses their is recourse for users.

Afaik, this is not possible. The network can not reject an address if it is valid and meets all the necessary requirements. However, it is possible such an API could be built on a software system.

[thefreshprinceofbell]

Why would anyone want to store their funds on a company's server which would hold the private keys of their address

Huh? You would be holding your own keys natively on your phone, probably in the secure element.

[ranochigo]

But if the BTC are somehow held in a way that they can only be send to white listed addresses their is recourse for users.

Is there anyway this can be accomplished on the blockchain?

No. Restricting yourself to only be able to send the funds to certain addresses effectively locks your funds if the specified addresses are compromised or lost. Scripting standards also don't allow any functions that restricts the UTXO spending, or at least to my knowledge.

The security lies with the users themselves. It wouldn't matter if you were to lock your funds to certain addresses, hackers would just target those addresses instead. If you want to do this, then use a service that provides address whitelisting. For which, those services only locks the withdrawal on the surface and defeats normal client-side attacks but not server side attacks. When you're handing the control of your coins to any thirdparty, you'd have to be aware that they are controlling your funds.

[NotATether]

But if the BTC are somehow held in a way that they can only be send to white listed addresses their is recourse for users.

In case your question is not about blocking addresses from a wallet app that Apple might make, but about Apple blocking transactions on their own:

This is impossible for them to do unless Apple decides to run a mining pool which is extremely unlikely. And even then they'd need to somehow obtain over half of the network's hash power which will be very difficult considering the community doesn't want that to happen, because such power is dangerous can can be used to drop anybody's  transactions for no reason, including ones to addresses that they did not whitelist!


(this part applies even for the case of Apple making a wallet)

How will they even create such a whitelist anyway? A few months back during the bull rally I read a news article that over 25 million (or some other figure but I remember it being in millions) new addresses were created in just a matter of days. Now how is Apple possibly going to check all these addresses manually, since there does not exist a tool that identifies the person or org behind every address anyway. There isn't even any information in the blockchain about that.

No offense, but such an idea sounds wrong. Because in Bitcoin, every person becomes a payee/merchant or whatever other name people give them, just by generating addresses at will. So each person who uses Bitcoin has a bunch of addresses, and organizations mass-generate more addresses for their own use. So when you limit payments to whitelisted addresses, you're actually limiting the people who can receive it.

[Harlot]

I don't think there is such way nor I see any benefit on applying one in any wallet. Having a whitelist address for sending purposes isn't an improvement or added security than having a good pin, 2fa, and protecting the private keys of your wallet. Having a whitelist in your wallet will just make you limit your options on who you will send your Bitcoin to and even that doesn't guarantee the safety of your Bitcoin as  they might even try to compromise the addresses part in your wallet. Just always practice on having a good password and keep your pin and private keys on your own so you won't have to worry about these kinds of things.

[PrimeNumber7]

The only way you could possibly do this is if you were to pre-sign many transactions that spend your coin to each of your 'whitelisted' addresses, and subsequently, destroy all your private keys. You could then broadcast your transactions to any of the addresses when you are ready to spend your coin.

The problem with the above is that if you receive coin after you destroy your private keys, you would be unable to spend that coin. It also removes flexibility as to how large of a transaction fee you will pay because you will need to sign the transactions in advance.

This is an implementation I would recommend against.

[vjudeu]

It can be easier: if you want to make coins spendable only by selected addresses, then just send all funds to some 1-of-N multisig. If N is not larger than something like 15 or 20, then it is enough to make it by using some standard transaction. Maybe with taproot it will be possible to use larger N.

[Wind_FURY]

I was thinking about how online banking works today.  They don't really have to worry about security because you can only wire to pre approved payees. 

If a company like Apple was to one day allow BTC to be held natively they wouldn't want transactions to be able to be sent anywhere.  One Webkit exploit combined with userland root access and hundred of millions users wallets are empties instantaneously.

But if the BTC are somehow held in a way that they can only be send to white listed addresses their is recourse for users.

No, Apple would have to hold your Bitcoins under their custody to gain the ability to censor you, like PayPal. But if you truly wanted to use Bitcoin, why would you use it through a centralized entity that removes its main value proposition?

Is there anyway this can be accomplished on the blockchain?

No.

[NotATether]

It can be easier: if you want to make coins spendable only by selected addresses, then just send all funds to some 1-of-N multisig. If N is not larger than something like 15 or 20, then it is enough to make it by using some standard transaction.

OP is asking how to make coins spendable only TO selected addresses not by them.

Multisig will not enable you to blacklist addresses from being sent to.

Maybe with taproot it will be possible to use larger N.

No, Taproot doesn't change the number of co-signers possible, it obfuscates their public keys. And P2SH multisig is still limited to 15 co-signers (all with compressed public keys) for space reasons, Taproot doesn't change that.


Here's another way to whitelist addresses for those who have the resources; Start an exchange, and prevent the users of your exchange from sending bitcoins to certain addresses. That is what Coinbase did during the Twitter hack to block the scammers' address. Of course this censorship method only works on wallets inside your exchange, and not outside it.

[bob123]

I was thinking about how online banking works today.  They don't really have to worry about security because you can only wire to pre approved payees. 

What?

In Europe, online banking does not work like that.
No one has to "approve" the recipient of a transaction.

A SEPA transfer works by entering the recipient and the amount. That's it.
Just like a BTC transaction with the difference that you not only enter a recipient-identifier, but also the name of the recipient and that your bank is in control of your money instead of only you.

It doesn't make much sense to me to whitelist recipients.

[vjudeu]

OP is asking how to make coins spendable only TO selected addresses not by them.

I just thought that if coins are spendable only to selected addresses, it is roughly the same as sending that coins to some multisig involving these addresses. But you are right here, it is something different and it has to be handled in some other way.

The only way you could possibly do this is if you were to pre-sign many transactions that spend your coin to each of your 'whitelisted' addresses, and subsequently, destroy all your private keys. You could then broadcast your transactions to any of the addresses when you are ready to spend your coin.

Here's another way to whitelist addresses for those who have the resources; Start an exchange, and prevent the users of your exchange from sending bitcoins to certain addresses.

So, let's combine these two ideas into one: instead of creating some kind of centralized exchange, there is probably someone that want to prepare the list of allowed recipients for you. If that's the case, then all that is needed is putting all coins in some 2-of-2 multisig address and then it is possible to create N off-chain transactions, sending all coins to each recipient from the whitelist. It is then something like "limited Lightning Network" where your HUB can decide who can receive your coins, just by limiting your closing transactions and refusing to sign it if the recipient is not in the whitelist. And then, it is possible to add recipients to the whitelist as long as you and that HUB can sign some additional transaction. If removing recipients should be also possible, then creating 2-of-2 multisig for each output where coins are owned by your HUB and your recipient should do the thing. Then, it is the same as "limited LN" where your HUB allows you to move the coins as long as your recipient will have some channel with the same HUB.

[NotATether]

...

I don't think we have to go off-chain. It may be possible to accomplish something like this right now by using a regular P2SH addess but instead of the normal OP_HASH160 <pubkey> OP_EQUAL we could build a public script like:

Code:

OP_IF
    OP_HASH160
     <pubkey1>
      OP_EQUAL
OP_ELSE
    OP_IF
        OP_HASH160
        <pubkey2>
        OP_EQUAL
    OP_ELSE
       ...
    OP_ENDIF
OP_ENDIF

I don't think there's an OP_ELSEIF opcode is there?


And then the signature script looks exactly like the one for multisig: OP_0 <sig1> <sig2> ... <normal redeem script>

I get that this is a non-standard P2SH and that this stuff should be in the redeem script but I couldn't figure out how else to make it work.

[garlonicon]

No, Taproot doesn't change the number of co-signers possible, it obfuscates their public keys. And P2SH multisig is still limited to 15 co-signers (all with compressed public keys) for space reasons, Taproot doesn't change that.

But taproot activation is connected with Schnorr signatures. And then, combining N signatures into one would be possible, potentially increasing co-signers "ad infinitum" (in practice up to 2^256 or some other huge number, according to ECDSA properties) if I understand it correctly.

I don't think there's an OP_ELSEIF opcode is there?

There is no single opcode for "else if" operation.

Code:

OP_IF
    OP_HASH160
     <pubkey1>
      OP_EQUAL
OP_ELSE
    OP_IF
        OP_HASH160
        <pubkey2>
        OP_EQUAL
    OP_ELSE
       ...
    OP_ENDIF
OP_ENDIF

Maybe with taproot it could be written as a standard transaction, where non-executed branches will be skipped and replaced with some hashes.