Designing a privacy preserving rCBDC

There has been a lot of global debate about privacy in the context of retail CBDCs, particularly in the context of them being a replacement for cash. The perception is that the introduction of a retail CBDC would enable broad surveillance powers for the government as well as the ability to programmatically control what people do with their money.  Indeed, this is possible however it is also possible to design a rCBDC in a way that doesn't reduce people's privacy or the ability to conclude transactions in an anonymous way.

In 1983, cryptographer David Chaum invented the “blind signature”: a method of digitally signing a message that is “blinded” to the signatory.  This relatively old technique can be applied, in the context of rCBDCs, to deliver a privacy experience that resembles cash in many ways. 

A blinded signature is where Alice, for example, creates a message M and sends that Bob with the bank’s signature but doesn’t want Bob to know the contents. Alice takes her message and multiplies it by a blinding factor and then sends the blinded message to the bank. The bank generates a signature for the blinded message and sends back to Alice.  Alice then removes the blinded bank signature to Bob who can then use the bank’s public key to verify that they signed it – without the bank having seen the contents of her message.

Now, this can be applied to design a rCBDC that offers cash-like privacy characteristics. In this case, Alice would create, on her mobile device, a number of rCBDC tokens (in different denominations similar to cash) and blinds them before sending to their commercial bank. The commercial bank would authenticate the request, perhaps calculate fees, and debit Alice’s account for the total amount.  They then pass the still-blinded message to the Central Bank who debits the commercial bank account, digitally signs the blinded rCBDC coins, and sends back to the Commercial Bank.  As they are blinded, the Central Bank doesn’t know who they were issued to but they record a serial number of the issued coins in a database based on their signature of them. The commercial back then sends the blinded signed coins back to Alice who unblinds them whilst retaining the central bank signature (which demonstrates their authenticity). 

When Alice wants to spend the rCBDC with Bob, she presents the coins to him via a secure peer to peer exchange or similar. Bob’s application or device then sends the tokens electronically to his acquiring bank for validation who then sends them to the Central Bank. The Central Bank checks the signature and looks up in a database (to ensure no double spend). If all in order, they credit the acquiring Commercial Bank account, mark the coins as spent, and notify the bank who would subsequently credit Bob’s merchant account. 

This is analogous, in many ways, to how cash works with ATM machines. Although the rCBDC was signed when Alice withdrew it, when she then presents it for use in a payment transaction, there is no way for the particular tokens to be linked to Alice’s withdraw because they were blinded when the Central Bank signed them.

As the end user (Alice) is engaging with the rCBDC through their commercial bank, there is still the ability to ensure KYC and AML steps are performed by this bank; and the bank would have an aggregate view of how much rCBDC has been issued to a user but not necessarily what they have used the currency for.

At the point of acquisition, if there was a requirement to differentiate between small value and large value transactions to mitigate increasing AML risks, it would also be possible. For example, requiring that the transaction is linked to Alice's identity in the case of a large value transaction prior to passing the rCBDC coins to the Central Bank for verification.