Skip to Content

Scrit: The Vision For a Federated Chaumian Digital Cash

Posted on 10 mins read

Vision

Two things are fundamental in the 21st century, as they have been before: communication and commerce. Today, they are more intertwined than ever. We do most of our commerce on the internet or by using our smartphones. Physical cash is on the way out as you can see in China, replaced by means of payment that are more compatible with the digital age.

However most of these systems are a privacy nightmare. This fact was recognized in the late 1980s by people like David Chaum and the Cypherpunks. Early attempts to implement privacy preserving, even anonymous, digital means of payment failed due to being ahead of their time, government interference, or inept business decisions. Instead these early attempts were forgotten. In their place came account based systems, digital credit cards and blockchain based cryptocurrencies. What all these do not accomplish is the character of truly anonymous cash. Either they do nothing to protect the privacy of users or they are far too unreliable, unpredictable, and slow to ever be useful for day to day transactions.

This situation has to be remedied. Our world should instead have access to the following: a very cheap, instantaneous, easy to use, and untraceable means of digital payment.

I want to use my smartphone to pay for coffee in a restaurant as fast as with physical coin and bank notes, I want to give a beggar a few cents without him having to register with the tax authority, I want to pay for goods and services on the internet without leaving a paper trail. I want all that without having to follow the insane price fluctuations of a currency, without having to pay unpredictable and high fees, and without having to adapt to a new way of making payments that requires me to read hundreds of pages of documentation to understand it.

But lets not stop there. Our world is just not about humans paying humans, and it is also full of digital divide. A payment system of the future has to as easily support rich people in the West, as is does poor entrepreneurs in the heart of Africa. It has to recognize that in a networked world it is not just humans paying humans, but mostly humans paying humans through machines and machines paying machines. This means that the implementation of a such payment system must happen in the open, and must support cheap hardware in environments where network access might be spotty at best.

The complexities of current systems simply do not make them a feasible option to accomplish this goal. They are too complex to implement, too costly to run and not resilient enough to deal with third world realities.

What does it mean that we pay machines and machines pay machines? A world in which our web browser can pay a news site does require less ads and less click bait. A world in which my smartphone can pay a hotel room directly, it’s door lock, makes AirBnB less necessary. My car should be able to pay for an electric charge without me having to open an account with a provider and creating a record of all my travels. An entrepreneur should be able to enter the retail market by simply renting a slot in a vending machine without sharing sales data with a conglomerate. And why do we need a smartphone at all that is mostly used to track our every move, and which battery seems to constantly be empty?

Should we not be able to make our payments with a cheap USB stick like device. Cheap enough to be easily issued and replaced, and available to even those living in desperate conditions.

Let me mention one more problem: Current assumptions made by cryptocurrencies are that all people on the planet should use the same currency and payment system. I disagree. The economic realities and differences in being able to reach the internet makes it much more plausible to use multiple currencies that are interoperable but remain useful to their local communities in case of global network disruptions, censorship, or diverging economic development. What remains is the question: Can such a system be built? For me it is necessary to accomplish this and the answer is “Yes!”. The answer is called Scrit: secure, confidential, reliable, instantaneous transactions.

Before going into the technological aspects, let me define what I mean with secure, confidential, reliable and instantaneous.

Secure: Funds can only be transferred by those that know a private secret, enforced by cryptography. No third party without knowledge of that secret can transfer funds or pretend that a transfer has occurred.

Confidential: Only payer and payee know that a transaction took place, and what it was for. No third party can see, know, or show who sent money to whom, or how much. This goes beyond just small anonymity sets of a few dozen participants but instead covers all transactions made during a multi week time span. This property also means that no participant needs to be permissioned to take part in the system, and no payments can be censored.

Reliable: A payment system must operate even if large parts of its components are in-operational due to internal or external events. This should go so far that payments can be made even if only one side of the transaction has network access at all, or in an extreme case if network access is unavailable at the place of transaction.

Instantaneous: Payment systems have become a nuisance if guaranteed settlement cannot be achieved within seconds. Our system settles in a time that depends almost completely on network communication latency. In human words, transactions settle under two seconds and availability of funds is guaranteed and transactions are no-repudiable.

Meet: Digital Bearer Certificates

The technology to accomplish this has been known to cypherpunks since the early days of the movement. However, it requires a small modification to make it resilient against technological, security, and government risks (more on this later). The technology is called Digital Bearer Certificates (DBCs).

In its easiest form a DBC is a serial number authenticated by a digital signature. Such a DBC is issued by a mint and transferred to the user. The user can then transfer this DBC by electronic means to another user, and thus transfer the value it may represent. Since digital data thrives on being copied the uniqueness of a DBC needs to established. For this the receiving user sends the DBC back to the mint which records the serial number as being invalid and responds with a new DBC, containing a new serial number. This prevents the same DBC from being spent more than once while also allowing anybody to verify its authenticity. This process is extremely simple and efficient: It requires only the creation of two signatures, the validation of three signatures and recording and verification of a serial number in a database. Thousands of these transactions can be accomplished in a single second on modern consumer hardware.

Simple DBC transaction

Simple DBC transaction

However, this process does not prevent any tracing yet. For this we need special digital signatures algorithms that prevent the mint from knowing what it signs. These are called blind unlinkable digital signatures. A blind digital signature allows the user to conceal the serial number, send that concealed number to the mint and the mint can sign it without ever knowing it. The user can then reveal the original serial number while retaining a valid digital signature by the mint. In this scheme the mint cannot learn the contents of the signed serial number or recognize the resulting signature and connect it to the signing event.

Blind DBC operation

Blind DBC operation

Using this method users can make transactions of DBCs without leaving any trace for the mint or a third party to follow. To make this system usable two more properties have to accomplished: Ownership verification of DBCs, and the representation of different values.

To achieve the first, the serial number is extended by instructions to the mint on how to verify that a user is authorized to make a transaction. The easiest method for this is to simply encode a public key into the DBC that is then required to sign any transaction sent to the mint. The mint can verify such a transaction signature since the contents of the DBC are visible to him.

Since the mint cannot verify the contents of a DBC during his signing of a DBC any additional properties have to be encoded into the signature itself. This is easiest accomplished by the mint using a different signing key to communicate different properties. For example: The mint can use key A to sign DBCs of 2 USD value, and key B to sign DBCs of 5 USD value. Any participant in the system can now verify the authenticity and additional properties by simply matching the signing key to the signature.

Federated Chaumian Digital Cash

DBC systems as described above suffer from two fatal risks.

The first is that the mint is a single point of failure. Any disturbance of the mint, be it technical, operational, or caused by the government, disrupts the ability to access funds or make transactions.

The second risk is fraud by the mint. It can create new DBCs out of thin air without anybody noticing.

These two risks have prevented DBC systems from being widely deployed and so far have been (to my knowledge) unmitigated.

Our proposal is to distribute mint operations widely, over hundreds or possibly thousands of mints that have to reach consensus for all operations. This is easier than it sounds.

Instead of having a serial number signed by only one mint we propose the same serial number being independently signed by many mints. Thus a DBC becomes a serial number and a set of signatures (instead of just one).

During normal operations a user would present the DBC only with that same mint’s signature to a mint. The mint would verify the signature and uniqueness of the serial number and issue a new DBC, as defined by the user. Executing this operation in parallel with many mints prevents any single mint, or small group of mints, to create valid DBCs on their own accord. They would be missing the corresponding signatures of other mints.

To transfer value from one user to another, the sender would send both the serial number and the complete set of mint signatures. The receiver would then verify each signature and reissue the DBC independently with every mint that contributed a signature.

Scrit Transaction

Scrit Transaction

To create new money a quorum of mints (over 50%) must come together to create signatures on an agreed on serial number. No single mint can accomplish this independently since the private keys are only known to the mints themselves and DBCs signed only by one mint are not valid in the system.

If for any reason a mint cannot be reached during a transaction he can still sign a new DBC by receiving the DBC including all the signatures of the other mints. Essentially a large enough set (>50%) of signatures of other mints becomes as valid as a single mint’s own signature.

If the quorum of mints is chosen to be higher than 50% and lower than 100%, the system allows for the absence of single mints while also preserving that no small group of mints can act fraudulently. This prevents the single point of failure and issuer fraud.

It is important to mention that apart from agreeing on money creation and authenticating mint public keys, no communication has to take part between the mints. All synchronization relies solely on user interaction with the mints.

More can be said about using this technology to create a secure, confidential, reliable, and instantaneous payment system, but those details are better discussed in a more technical whitepaper.

It should be clear by now that Scrit has the potential to fulfill the necessary properties of a future oriented digital anonymous payment system. And we are thrilled to work on making it a reality.

The future we want needs it.

You can follow our work on GitHub.

Scrit will be 100% free and unencumbered software released into the public domain. To support our work please donate Bitcoin to:

36hMdVaZWUHbsnXfPsJtXe7ZRcU6jciAFt

Bitcoin donation address

If you are interested in the original slides for the HCPP19 talk on Scrit, see here.