After Tornado Cash - Implement rejection of transfers/spam on a per wallet basis?

[GuybrushX]

After watching a talk of Crypto Finance at the Crypto Assets Conference in Frankfurt I remembered my below reply to another issue:

Originally posted by @GuybrushX in #46 (comment)

My idea about "transactional transfers" came to my mind again for another IMHO very good reason:
-> Spam protection!

I can think about at least two big events where this happened or still happens all the time:
-> After Tornado Cash was blacklisted people sent "dirty tokens" to well known clean addresses of other people and they got into trouble because of that without any chance to reject it
-> on ETH and BNB chains it is very common to receive scam tokens to get recipient's attention

I don't have a real solution because it probably needs some deeper discussion but here are a few thoughts:

• Implement "transactional transfers" like I've mentioned in the other issue
• Implement different kind of wallets:
  -> Receiving only (any kind of earnings, rewards, receiving payments...)
  -> Sending only (for payments only)
  -> Allow/Block wallets -> only allow a a custom list of wallets who can interact with/transfer to your wallet - similar like setting up firewall rules (drop all, except contacts for example)
  -> The "Allow/Block lists could also be enabled by default and in theory this could avoid all kind of hacks where funds are stolen and transferred to other wallets

I'm not sure if it makes sense at all or if this breaks some kind of blockchain ethics or it's not really permissionless anymore. Maybe it also generates too much overhead and affects TPS too much?

[MParlikar]

In CEP-78, it is impossible to 'airdrop' token into accounts. An account must explicitly sign a transaction to accept the token. If the pattern in CEP-78 is followed judiciously, this CEP is a moot point. A named_key can be stored in the account by signing a transaction containing session code where the recipient accepts the transfer of the asset into their account. Because this is possible on Casper, users can prove definitely that they do indeed accept an asset - because the named_key is stored in their account.