Decoin - Implementing a cryptocurrency as a SAFE app

[Anders]

EDIT: Simplified the algorithm.

This thread is about examining the possibility of developing a cryptocurrency as a SAFE app. The idea is to have a decentralized coin called decoin managed by a single app.

Decoins are mined by hashing a code of a fixed length of 8 bytes. A Rule 30 hash function is used to produce 256 bit hashes. EDIT: The difficulty is set to 2 leading zero bytes. Each coin has the value 1 decoin (D1). [spoiler] The minimum difficulty is set to a number of leading zero bytes of the 32 byte hash, for example 2 leading zero bytes:

Difficulty level 1: 00nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

Each higher difficulty level has an extra leading zero byte:

Difficulty level 2: 000nnnnnnnnnnnnnnnnnnnnnnnnnnnnn
Difficulty level 3: 0000nnnnnnnnnnnnnnnnnnnnnnnnnnnn

And so on up to difficulty level 6.

The value of each hash depends on the difficulty level as follows:

Level 1: 1 decoin.
Level 2: 10 decoins.
Level 3: 100 decoins.
Level 4: 1,000 decoins.
Level 5: 10,000 decoins.
Level 6: 100,000 decoins.

Mining level 1 coins is easy and can be done with a standard desktop or laptop computer. The higher levels get exponentially more difficult to mine. However in lucky cases higher level coins can be mined with very little computing power.[/spoiler]

The coins are stored on the SAFE network as Structured Data containing the code and signed by the issuer.

When the miner (app) finds a code that produces a hash satisfying the difficulty a check is done to see if that coin already has been mined and registered. If not, then the mining app signs and stores the coin on the SAFE network.

Transactions are done by transferring the ownership of the Structured Data from the sender to the receiver.

Double spending is prevented by having the data for each coin stored with its unique code.

[Anders]

In this podcast they talk about how Structured Data can be cryptographically signed and identified with the owner’s public key, and also that the ownership can be transferred to another user (from about 26 minutes): SAFE Crossroads Podcast #28

That sounds exactly what is needed for Decoin. Verification of a coin is then easy and fast, by checking the ownership and checking that the hash of the code matches one of the difficulty levels.

The code (see my previous post) is limited to a fixed number of bytes. This sets a limit to how many coins can be mined in total. And it prevents exponential technological progress from making it possible to mine faster and faster. The limited code size makes the amount of new coins available to mine approach zero over time.

[fergish]

This is cool.

Also check out SAFE Crossroads #30.

Harmen talks about something very similar. He has the code all worked out, I believe, except perhaps API adjustments. Might be worth a collaboration.

[Tim87]

I’ll go meta for this

I’m more interested in a way to create all kinds of different currencies on demand. Each of these currencies would have a limited user base: some would be used in a school, a university, a company, some would be tied to a location, some to a community, and one or two may even end up as generic global currencies, but that’s atypical. The point is, each of these currencies would closely adapt to the economic needs of their user base, even more so than the current system of fiat currencies.

Everyone could accept a different set of currencies, and smart wallet apps would handle the bargaining behind the scene: they would agree on a common denominator that’s acceptable for both parties or, if necessary, they would reach out to an exchange (or, better: friends) to find more options.

I think it’s definitely a fun idea to play with

[Anders]

Coins with higher difficulty level (2-6) can be split, and coins with lower difficulty level (1-5) can be joined. When a coin is split it is converted into 10 coins of lower denomination. And a join is when 10 coins of lower denomination are combined into one coin of higher denomination.

For example let’s say that Alice has received one D100 coin (one coin with the denomination 100 decoins). Her wallet only contains this one coin. And she wants to send 43 decoins to Bob. Then the app splits the coin into ten D10 coins, and splits one of those coins into ten D1 coins. And the transaction contains four D10 coins and three D1 coins.

The app automatically converts coins to keep the number of coins at a low number for efficiency reasons. Imagine as a hypothetical example that a New World Order bankster wants to send a million decoins to Donald Trump as an attempt to bribe Trump, then it would take a very long time to do a transaction if one million Structured Data objects had to transferred. Instead the bankster’s app sends ten D100,000 coins in the transaction, which means that only ten Structured Data objects have to be transferred.

[Tim87]

How would this system account for increase in computing power? Something like what Bitcoin does, using a floating difficulty to adjust it to the hash rate.

How about using relative difficulties instead of fixed numbers? Also, let’s move away from decimal, because it’s unnecessarily cumbersome to work with in this context.

Let’s make difficulty a global parameter, and coins follow a series of the negative powers of 2, starting with 0: 1, 1/2, 1/4, 1/8, … The effective difficulty should follow the same series, so the difficulty for the coin with a value of 1/2 would be half of that of 1, 1/16 half of that of 1/8, etc.

Now we just have to figure out how the difficulty should be set, which is something Bitcoin has a pretty effective mechanism, but idk from the top of my head how we could do it here.

[Anders]

@Tim87

How would this system account for increase in computing power?

The code is set to a fixed number of bytes, for example 6 bytes. To make it easier to illustrate, let’s take a code length of just one byte.

With one byte only 256 combinations are possible. And when the values are hashed, then only a few of them will meet any difficulty target. So very few coins in total can be mined with a very short code like that. With a fixed code length of 6 bytes there are many more possible combinations, and taking the hash function as being a random oracle, there will be 2^(6*8) / 2^16 possible coins meeting target level 1 (two leading zero bytes in the hash) = around 4.3 billion coins.

As more and more coins are mined fewer new coins become available to mine, no matter how much computing power is used. The code length may need to be larger than 6 bytes to allow coins to be able to be mined for a longer period of time.

[bochaco]

@Anders

For example let’s say that Alice has received one D100 coin (one coin with the denomination 100 decoins). Her wallet only contains this one coin. And she wants to send 43 decoins to Bob. Then the app splits the coin into ten D10 coins, and splits one of those coins into ten D1 coins.

Would Alice’s wallet need to then mine the D10 and D1 coins before being able to make such a conversion? …well…in that case it wouldn’t need to make the conversion but just use the mined coins I’m confused about how the split scenario works

[Anders]

@bochaco

Would Alice’s wallet need to then mine the D10 and D1 coins before being able to make such a conversion?

The split and join functionality is complicated. The idea is that the old coins are “burned”, meaning made unusable, and new coins are issued without mining. I read that Structured Data has the possibility to remove all ownership of the data. That would work as a way to burn the coins I guess.

The difficult part is how to keep track of all history of the splits and joins. Unless I can find an efficient way of doing that it might cause the validation of coins to be too inefficient in the long run.

[Tim87]

Wouldn’t a way to automatically exchange coins between users solve this problem easier? There could be a global exchange for swapping multiple coins of smaller denominations to single coins of bigger ones. Again: anything like this would work infinitely better with coins that are worth powers of 2.

[Anders]

@Tim87

Wouldn’t a way to automatically exchange coins between users solve this problem easier? There could be a global exchange for swapping multiple coins of smaller denominations to single coins of bigger ones. Again: anything like this would work infinitely better with coins that are worth powers of 2.

Yes, but I thought an automatic exchange needed some kind of centralized ownership. Decoin is meant to be completely decentralized.

And I thought about powers of 2 too, but the history tracking of splits and joins would still be complicated.

[Anders]

The different coin denominations and the split/join function can be something for another future coin. The development of Decoin will be faster with a minimum viable product implementation, such as:

A fixed length code of 8 bytes is used as the coin ID. And the hash of the code has to be less than a fixed difficulty level of two leading zero bytes of the 32 byte hash.

Each coin (all coins have the value 1 decoin) is stored as a Structured Data object. And transactions are done by transferring the ownership of the Structured Data, one object per coin. The receiver is notified via a message after all coins in a transaction have been transferred.

The wallet implementation is a single file containing the user’s coin IDs.

[TylerAbeoJordan]

Is this going to be an experimental coin to test functionality (possibly ongoing) or is this an attempt to create a new listed super coin? It seems it would be difficult to do both, so I’m curious where you are going with this.

[Anders]

@TylerAbeoJordan

Is this going to be an experimental coin to test functionality (possibly ongoing) or is this an attempt to create a new listed super coin? It seems it would be difficult to do both, so I’m curious where you are going with this.

At the moment I’m thinking of developing a simple SAFE web app, and make the code license free. Maybe I will start developing Decoin after the SAFE Beta release. Will decoin become a real cryptocurrency? I doubt that, but who knows. No premining except for testing purposes.

[Tim87]

@Anders

I thought an automatic exchange needed some kind of centralized ownership

It would be a distributed order book (something like a bulletin board) without a central authority; I’m sure we’ll have many such things on SAFE, it sounds like a pretty generic use case for different things. People could post and query requests, but the actual transactions would still happen between the parties, not through an intermediary.

@Anders

And I thought about powers of 2 too, but the history tracking of splits and joins would still be complicated.

No splitting/joining, just exchange of coins. Didn’t you say coinst would be data blocks on the network? Then that’s the simplest solution.

[Anders]

@Tim87

It would be a distributed order book (something like a bulletin board) without a central authority;

Ok, interesting. In the minimal viable product implementation of Decoin I will only have D1 coins to make it easy to develop. But my Decoin concept is copyright-free, so someone else can make another similar coin with a distributed order book.

[Anders]

I forgot to include Decoin wallet addresses in the minimal viable product description in a previous post. The users only have one Decoin wallet each based on their public keys. There can be many addresses to the same wallet. A Decoin wallet address is calculated like this:

SHA256d(user’s public key concatenated with a nonce)

The nonce is to allow multiple addresses for each user and to prevent others from squatting user wallets and making them unusable.

The Decoin wallet addresses are presented with a hash symbol (#) followed by a Base58 coded version of the wallet address. A Decoin address will look like this:

#jU4GtknB4Co4bhcPb3FHPxsGgtkbSf8Q16

So a user can have several Decoin wallet addresses, but all coins belong to the user’s public key. The coins are unrelated to the wallets except that the users’ public keys are the same for the coins and for the wallets. The wallets make it possible to get the public key via the wallet addresses and serve as addresses for sending and receiving messages.

[Anders]

EDIT: Added root record.

A distributed ledger is useful for ensuring a trustless system for transactions.

“A ledger[1] is the principal book or computer file for recording and totaling economic transactions measured in terms of a monetary unit of account by account type, with debits and credits in separate columns and a beginning monetary balance and ending monetary balance for each account.” – Ledger - Wikipedia

In Decoin the ledger is stored as records of Immutable Data, one object for each transaction. A Decoin record contains the following fields:

recordID
previousRecordID
coinID
senderPublicKey
receiverPublicKey

The recordID for non-root records is calculated with:

recordID = SHA256d(previousRecordID || coinID || senderPublicKey || receiverPublicKey)

The recordID for the root record is:

recordID = coinID

The root record is created for newly mined coins. In the root record the senderPublicKey is empty and the receiverPublicKey is the miner’s public key. This prevents multiple starts of transaction history chains for the coins (there can only be one root record ID for each coin).

The Structured Data Decoin object contains a field for the most recent recordID related to the coinID. In this way the entire history of transactions for each coin can be tracked.

[Anders]

I designed a Decoin logo:

[Anders]

I certainly hope that the final version of Immutable Data will allow the following:

1. To be public.
2. To be cryptographically signed.
3. It is possible for anyone to verify that the data has been signed and what the public key is of the signer.

Otherwise fake histories of transactions can be created and the record ID in the StructuredData for the coins can be set to those fake histories.