(image)

Programming Hotmoka
A tutorial on Hotmoka and smart contracts in Takamaka

2.6 Anonymous payments

The fact that accounts in Hotmoka are not just identified by their public key, but also by their storage reference inside the state of a node, makes it a bit more difficult, but not impossible, to execute anonymous transactions. We do not advocate the use of anonymity here, but it is true that, sometimes, one wants to remain anonymous and still receive a payment.

Anonymity is often used for illegal actions such as ransomware and blackmailing. We are against such actions. This section simply shows that anonymity can be achieved in Hotmoka as well, although it is a bit harder than with other blockchains.

Suppose for instance that somebody, whom we call Anonymous, wants to receive from us a payment of \( \sentToAnonymous {} \) coins, but still wants to remain unknown. He can receive the payment in many ways:

  • 1. He could send us an anonymous email asking us to pay to a specific account, already existing in the state of the node. But this is not anonymous, since, in Hotmoka, an account is an object and there must have been a transaction that created that object, whose payer is likely to be Anonymous or somebody in his clique. That is, this allows one to infer something about the identity of Anonymous. Therefore, Anonymous would probably discard this possibility.

  • 2. He could send us an anonymous email asking us to create a new account with a given public key, whose associated private key he controls, and to charge it with \( \sentToAnonymous {} \) coins. After that, we are expected to send him an email where we notify him the storage reference where moka accounts create has allocated the account. But this means that we must know his email address, which is definitely against the idea of anonymity. Therefore, Anonymous discards this possibility as well.

  • 3. He could send us an anonymous email asking us to pay to a given public key, whose associated private key he controls. After we pay to that key, he autonomously and anonymously recovers the storage reference of the resulting account, without any interaction with us. This is definitely anonymous and that is the technique that Anonymous will choose.

Let us show how the third possibility works. Anonymous starts by creating a new private/public key, exactly as we did before: 

moka keys create --name=anonymous.pem --password

Enter value for --password (the password that will be needed later to use the key pair): kiwis
The new key pair has been written into "anonymous.pem":
* public key: 2EwYUQkQkeNNDBE6v5iuJUa8c4cfpkcCErY7Hg5ktDFh (ed25519, base58)
* public key: Em3os8qYqwRtCz8ZTz8GLYa9IIfAVU78OwvV9WS3ouw= (ed25519, base64)
* Tendermint-like address: C57114D47EDEFB572FE12D2490F4E08B8912D994

Note that there is no --uri part in the moka keys create command, since this operation runs completely off-line: no object gets created in the state of any Hotmoka node for now.

Anonymous pastes the new key into an anonymous email message and sends it to us: 

   Please pay 10000 coins to the key 2EwYUQkQkeNNDBE6v5iuJUa8c4cfpkcCErY7Hg5ktDFh.

Once we receive that email, we use (for instance) our previous account to send \( \sentToAnonymous {} \) coins to that key: 

moka accounts send 3fcbb8889b77be347c3bfe0019683d3fefe2f58712085208c58cfc4d91add793#0 10000 2EwYUQkQkeNNDBE6v5iuJUa8c4cfpkcCErY7Hg5ktDFh --password-of-sender --uri=ws://panarea.hotmoka.io:8001

Enter value for --password-of-sender (the password of the sender): chocolate
The payment went to account cdd23aed685f6cd6af118570b54fb7f21a216d5355d2e11b780c8eec5d66cfa0#0.
The owner of the destination key pair can bind it now to its address with:
  moka keys bind file_containing_the_destination_key_pair --password --uri uri_of_this_Hotmoka_node
or with:
  moka keys bind file_containing_the_destination_key_pair --password --reference cdd23aed685f6cd6af118570b54fb7f21a216d5355d2e11b780c8eec5d66cfa0#0


Gas consumption:
 * total: 85944
   * for CPU: 17280
   * for RAM: 12024
   * for storage: 56640
   * for penalty: 0
 * price per unit: 2 panas
 * total price: 171888 panas

And that’s all! No interaction is needed with Anonymous. He will check from time to time to see if we have paid, by running the command moka keys bind until it succeeds. First attempt: 

moka keys bind anonymous.pem --password --uri=ws://panarea.hotmoka.io:8001

Nobody has paid anonymously to the key anonymous.pem up to now.

Second attempt: 

moka keys bind anonymous.pem --password --uri=ws://panarea.hotmoka.io:8001

Nobody has paid anonymously to the key anonymous.pem up to now.

The command finally succeds at the third attempt (for instance): 

moka keys bind anonymous.pem --password --uri=ws://panarea.hotmoka.io:8001

Enter value for --password (the password of the key pair): kiwis
The key pair of cdd23aed685f6cd6af118570b54fb7f21a216d5355d2e11b780c8eec5d66cfa0#0 has been saved as "cdd23aed685f6cd6af118570b54fb7f21a216d5355d2e11b780c8eec5d66cfa0#0.pem".

Once moka keys bind succeeds, Anonymous can enjoy his brand new account, that he can control with the kiwis password.

So how does that work? The answer is that the moka accounts send command creates the account cdd23aed685f6cd6af118570b54fb7f21a216d5355d2e11b780c8eec5d66cfa0#0 with the public key of Anonymous inside it, so that Anonymous will be able to control that account. But there is more: that command also associates the public key of the account to the account itself, inside a hash map contained in the manifest of the node, called accounts ledger. The moka keys bind command simply consults the accounts ledger, to see if somebody has already bound an account to that public key.

If, inside the accounts ledger, there is an account A already associated to the public key chosen by Anonymous, then the moka accounts send command will not create a new account but will increase the balance of A and the moka keys bind command will consequently yield A. This is a security measure in order to avoid payment disruptions due to the association of dummy accounts to some keys or to repeated payments to the same key. In any case, the public key of A can only be that chosen by Anonymous, since the accounts ledger enforces that constraint when it gets populated with accounts: if somebody associates a key K to an account A, then the public key contained inside A must be K.

Anonymous payments are possible with Mokito as well. Namely, that client allows one to create a key and pay to a key. We do not show the details here, but the app interface should be simple enough to perform such operation.

Should one use anonymous payments, always? The answer is no, since anonymity comes with an extra gas cost: that for modifying the accounts ledger. If there is no explicit need for anonymity, it is cheaper to receive payments as described in points 1 and 2 above, probably without the need of anonymous emails.