Decoin - Implementing a cryptocurrency as a SAFE app

[digipl]

Not now and, I hope, never will. The Immutable data is not signed, always encrypted (by self-encryption), and public or private is the datamap is public or private.
You can always chaining the hash of datamaps, immutable data or even MD to avoid fake history.

[tfa]

Structured data (not immutable data) had these features. They are being replaced with mutable data, but signatures are lost in this process. I hope that MaidSafe will add a variant that will restore them (last variant in this post in the dev forum).

[Tim87]

@Anders

A distributed ledger is useful for ensuring a trustless system for transactions […] the entire history of transactions for each coin can be tracked.

Not really, no. When you go into a store, they don’t care who you got your money from, only that it’s real and that they get it from you. Basically, you need to be able to verify just these two things:

• the payer gave you the coin (previous owner is the payer, current owner is you)
• the coin is real (i.e. it isn’t counterfeit)

Neither of these require a ledger, and there’s obviously no reason that the entire history of a coin should be tracked.

[Anders]

@Tim87

Not really, no. When you go into a store, they don’t care who you got your money from, only that it’s real and that they get it from you. Basically, you need to be able to verify just these two things:

the payer gave you the coin (previous owner is the payer, current owner is you)
the coin is real (i.e. it isn’t counterfeit)

Neither of these require a ledger, and there’s obviously no reason that the entire history of a coin should be tracked.

Without the entire history of the transactions there can be disputes about whether certain payments have been made or not. A trustless system with a full history ledger prevents such conflicts.

[Anders]

@digipl

Not now and, I hope, never will. The Immutable data is not signed, always encrypted (by self-encryption), and public or private is the datamap is public or private.You can always chaining the hash of datamaps, immutable data or even MD to avoid fake history.

I don’t see how that can prevent fake histories. Let’s say that Alice sends one decoin to Bob who creates a fake decoin record containing Charlie’s public key as the sender instead of Alice’s. And then Bob says to Alice: “You haven’t paid me.” Of course Alice has paid Bob, but there is no way she can prove that without the records having been signed by the real owners throughout the transaction history of the coin.

[Tim87]

@Anders

Without the entire history of the transactions there can be disputes about whether certain payments have been made or not. A trustless system with a full history ledger prevents such conflicts.

The ledger is not necessary for the coin to function; it’s an add-on feature to address disputes. Why make it mandatory? It introduces complexity for no reason.

When I get a beer, I just toss a few coins, and that’s all there is to it. When I’m buying a car, I make sure the transaction gets well-documented. Those are two different scenarios with different needs.

With bitcoin, the ledger is a fundamental part of how the system works, so it’s not a choice whether something gets into it or not… There’s absolutely no need to introduce a mandator ledger for your coin though.

To avoid possible confusion: I’m arguing against a mandatory ledger, not against having a ledger in general.

[Anders]

@Tim87

The ledger is not necessary for the coin to function; it’s an add-on feature to address disputes. Why make it mandatory? It introduces complexity for no reason.

When I get a beer, I just toss a few coins, and that’s all there is to it. When I’m buying a car, I make sure the transaction gets well-documented. Those are two different scenarios with different needs.

With bitcoin, the ledger is a fundamental part of how the system works, so it’s not a choice whether something gets into it or not… There’s absolutely no need to introduce a mandator ledger for your coin though.

To avoid possible confusion: I’m arguing against a mandatory ledger, not against having a ledger in general.

Since decoins are so easy to mine they may be less useful for payments because the value of each coin will be so low, and instead be more useful for other applications such as colored coins.

[Anders]

For the ledger I proposed to work the wallet has to check the entire transaction history of each coin. Because otherwise the sender can set a false previousRecordID. That kind of extensive validation is clearly too inefficient for ordinary payments. It might be useful for smart contracts and things like that, but I’d better stick to a minimum viable product solution and reduce the complexity as @Tim87 suggested. Therefore my current plan is to skip the ledger.

[Anders]

@tfa

Structured data (not immutable data) had these features. They are being replaced with mutable data, but signatures are lost in this process. I hope that MaidSafe will add a variant that will restore them (last variant in this post in the dev forum).

Ok, so StructuredData has been replaced by MutableData. I read in the RFC: “A MutableData owner can transfer ownership by issuing a special request:”

Whew. That makes it possible to have the decoins as MutableData.

[Anders]

The Decoin app will be a reference implementation. It will define the Decoin specification. Other apps such as Decoin wallets and miners can be developed based on that specification by other developers. The decoins are completely decentralized. And this also removes the need for me to provide APIs.

One drawback with Decoin is that the total amount of coins mined at any point in time can only be estimated and not known exactly because the coins are separate MutableData objects without any centralized reference structure.

Another drawback is that decoins can be stored on the SAFE network by anybody just randomly selecting codes without mining. On average only 1 in 65536 guesses will produce a valid decoin and to know which coins are valid they still need to be calculated just as when mined, so it’s meaningless to randomly store guessed coins for profit but it can be used as a method of attacking Decoin. The code of 8 bytes means that there are 2^64 possible code combinations which makes the incentive for such attacks low (enormous amounts of MutableData objects need to be stored to attack Decoin).

[Anders]

The drawback of lack of global reference structure in Decoin may also be a benefit because it makes the coin completely decentralized. And the number of decoins mined at any given moment can be estimated with a simple formula:

m = T(c_t/h_t) / (c₀/h₀)

m = number of coins left to mine
T = total number of coins available
h_t = hashing rate at the time of measurement
c_t = coins mined per hour at the time of measurement
h₀ = hashing rate for measurement of initial mining
c₀ = coins mined per hour for initial mining

Initial mining means mining from scratch, such as choosing a new and unused MutableData type for the mining to measure c₀.

The estimate can be made more precise by taking into account actual operations such as reads and writes done on the SAFE network for the measurements of c₀ and c_t.

And this is a trustless estimate in the sense that anybody can do the measurement. Several independent measurements can be done at a given moment in time and the median of those measurements will give a good estimate.

[Anders]

A decoin only has one owner, except during transactions. In a transaction the sender adds the receiver as owner and then sends a message to the receiver. The receiver removes the sender as an owner. This makes it possible for receivers of transactions to easily distinguish between valid transactions and double spend attempts when receiving transaction messages.

EDIT: The handling of coin ownership transfer is of course something done automatically by the app and not something users have to do manually. It also makes it possible to make transactions of several coins atomic (with possible rollback) by sending the transaction message after the receiver having been added to all coins in the transaction.

[Anders]

Is it possible on the SAFE app level to sign MutableData objects with the app’s credentials? Then the app itself can act as an automatic exchange that burns and converts coins. This makes different denominations (coin values) easy to implement.

And if that’s possible, then what about security? Can someone hack the app and access the app’s credentials?

[digipl]

The Apps are not allowed to do an ownership transfer.

Transfer of ownership

Ownership transfers are a special case. The apps are not allowed to do this operation. They will need to ask the Authenticator to do this. Maid-Managers shall enforce that change_mdata_owner only comes from the owner. Data-Managers shall enforce that current owner of the data matches the incoming Maid-Manager group.