The idea was to store the encrypted number of tokens,and when user was sending his private key, smart-contract would decrypt the data and perform an action of sending tokens to someone else. The catch is, user doesn't have his own ethereum address, so I need another private key generated for this and everything will be performed by one account from back-end. Also this will be one-time action - once private key sent and tokens released there will be no need for this private key anymore, so it's ok for it to be exposed to public chain.

I've found the only solution is to encrypt off-chain, keep it in smart-contract and for someone to read it there and decrypt again off-chain, but I need to perform an action after this so it doesn't fit here.

1 Answer
1

store the encrypted number of tokens, and when user was sending his private key ... smart-contract would ... sending tokens to someone else.

I'm going to set "private key" aside and call it simply "secret" to reflect that this is a password and not a wallet private key.

You'll have a contract that contains virtual "Drop Boxes" each of which contains a balance of funds owed and a destination address. These drop boxes would be organized in a mapping using "puzzles" to index. The puzzles would be hashes of unchangeable properties of the drop box contents (e.g. the destination) and a secret word.

The user's UI would compute a hash of, e.g., hash(destination, secret word). The user, or server would create a drop box identified by the hash, and write the box contents to the contract - amount, destination, expiry, etc.

That's the "challenge" stage. The "response" stage has the user present the secret. If the secret maps to a known drop box then the contract forwards funds to the destination specified in the drop box details.

Once used, "secrets" are burned. Take care to reject deposits using hashes with secrets are already solved. There is a race condition/front-running risk. It's important that the drop box contains unambiguous information about where to send the funds and only there. This, because the "secrets" are revealed in the tx.pool and everyone can see them even before the solution transactions are mined.