The money burning mechanism in the server

Sending money to external systems.

The system is a simple social network that pays out a fixed quantity of virtual currency to every verified users. Besides allowing users to send money to each other, the other supported operation is money burning.

When an user burns (destroys) a quantity of money they previously owned, the server (the centralized social network and currency system itself) gives them a cryptographically-signed receipt — a “proof of burn” — that proves that they have indeed destroyed that quantity of money. But why would anyone do that?

A proof of burn can be used transfer money from one monetary system to another, if the destination system trusts the source system. For example, you may create a website that accepts “deposits” of money burnt at the server. Once your website consumes a receipt given by an user, that money is “resurrected” (recreated) at the user’s account at your website in some form. For example, it can give the user credits that they can spend on services offered by your website, functioning as e.g. a rate-limiter (the original function of Hashcash, which eventually resulted in the Reusable-Proof-of-Work protocol and finally in Bitcoin).

When asking the server to burn money, you have the option to provide up to 600 bytes of binary “comment.” The comment field is copied into the burn receipt unmodified and is also covered by the server’s signature. The comment is provided by the specific destination system, and that’s the main mechanism that allows a destination system to know that a burn receipt is specifically meant for them (and not spent elsewhere in a competing system). The comment field also allows the destination system to bind the burnt amount to one of its accounts — for example, a public key that is allowed to move the money further within the destination system.

And yes! It is possible to export credits to a new “blockchain” crypto-currency that is built to trust the server’s master public key (the one used to sign the burn receipts). That crypto-currency would leave all money-creation to an external system — the social creation of money by Democratic Income — and could then run a Proof-of-Burn algorithm to generate new blocks, which doesn’t waste as much resources as a Proof-of-Work algorithm, and is not too difficult to implement and very easy to securely bootstrap.

Technical: the burn receipt format

For those who want to develop systems that consume the burn receipts: the following is “Version 0” of the receipt format. All numeric fields are signed.

  • 64 bytes: EdDSA signature (Ed25519)
  • 1 byte: Version (should be “0”)
  • 32 bytes: The server’s current master public key
  • 8 bytes: 64-bit integer Unique ID. Two different burn receipts signed by the same private key are guaranteed to have two different UIDs
  • 8 bytes: 64-bit integer. The amount burnt, in “cents” (1.0 DMS = 10,000 “cents”).
  • 4 bytes: 32-bit integer. The Timestamp (number of minutes since the UNIX epoch; UTC)
  • The remaning bytes in the burn receipt are the “comment” provided by the user

As discussed, the destination system should provide the “comment” string (a hexadecimal text string of bytes) for the user to fill out the burn money form at the server. It is certainly possible to build a system that accepts receipts without needing any comments in them; that’s up to the destination system’s design.

The destination system needs to keep track of burn receipts accepted for the same time window that it uses to accept receipt timestamps. E.g., if your destination system only consumes receipts generated at most two weeks ago, then it must keep receipts accepted in the past two weeks (probably a bit longer as a buffer) so it can detect attempts to cash in receipts twice.

The EdDSA library used to sign the messages is the EdDSA-Java library v0.2.0 by str4d. It uses Elliptic Curve Cryptography, the Ed25519 curve, 256-bit keys, 512-bit SHA as message hashing algorithm, and perhaps other parameter defaults encoded in the library. You should be able to verify the money burn signatures by using that library unmodified and without supplying any additional configuration to its signature verification API.

If you are in C/C++ land, you should probably give libsodium a go.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.