How transactions (could) take place using Decorum

[anon40790172]

@Seneca shared his Amsterdam presentation a few days ago. It’s called: “ALT-COINS ON SAFE - Using obfuscated transaction trees”. Now I don’t know about you, but I really bugged my head on this one . That’s why I decided to troll @Seneca with PMs until I finally understood his idea and the reason why it prevents double spending. I’ll use this topic to explain it as best as I can in my own words using both Alice and Bob and maybe some others. Let’s keep this topic about the inner workings of this idea and how alt_coins (maybe like PDC) could flow over SAFE.

The idea
Divisible coin transactions over SAFE using MutableData as a transaction record.

Bob and his Wallet
Bob has a Decorum_wallet which is filled with his private key and public key. This is the exact same principle as Bitcoin for example. Bob got a message from Alice that there’s 0.001 project Decorum Coin (PDC) waiting for him at address: “1HAmFJ7vd3vZaa1YDTBPkSj7zpoKmWMjwD”

Now how does this stuff works?? Bob’s wallet will browse to this address and finds the following:

• A piece of MutableData which was PUT by Alice in which Alice signs 0.001 PDC over to Bob. It also contains a digital signature by Alice of the previous transaction. And it also contains another transaction of Alice sending 0.999 to herself again.

The transaction in the MD
So how do we know for sure that Alice has moved the 0.001 PDC to Bob alone and no one else? How can we be sure there’s no double spending??

First of all, this MutableData piece containing the transaction is no longer owned by Alice. Alice transferred the ownership of this MutableData to a “dummy”. To the SAFE Network this might look like:

• address: “1HAmFJ7vd3vZaa1YDTBPkSj7zpoKmWMjwD”
• owner: “DECORUMxxDUMMYxxDUMMY”
• tagtype: 12333 (decorum protocol)

And now things get weird: Alice isn’t the owner of this address, but as you can see it doesn’t belong to Bob either. How does Bob get his 0.001 PDC? Well, just think of the wallet again. Bob is the owner of his private and public key. And Alice is the owner of her private and public key. Alice assigned 0.001 PDC over to Bob’s public key in this piece of MutableData. She also assigned 0.999 PDC over to her own public key. If she would still own the MutableData she could change these values over and over again. So Alice moved the ownership of the “MD with the transaction in it” to a dummy. This means that no one in the SAFE network can ever change this data again, as no one has the private key to create a weird public key like: “DECORUMxxDUMMYxxDUMMY”.

It’s like carving the transaction in stone. And this is what the Decorum wallet will look for. All transactions are MutableData types that got PUT to the network by the owner of the coin. The owner forwards the MD to the dummy so no one can ever change that piece of data again.

Only Bob can move this 0.001 PDC
So how could Bob send over this 0.001 PDC to Catherine? How is it prevented that Bob can’t double spend this coin? Here’s the trick:

• Bob can only do 1 transaction with this 0.001 PDC.
• The address of the MutableData which Bob creates can only have 1 address.
• The address is the same as Bob’s signature of the “carved in stone” transaction done by Alice.

So when Bob’s wallet signs the transaction done by Alice, he will get a digital signature. He’ll use this signature as an address to go to his close nodes saying: I would like to PUT some MutableData on this address. He pays some Safecoin and becomes the owner of a piece of MutableData which has the same address as the signature of the transaction done by Alice.

Bob creates the transfer to Catherine by signing over his 0.001 PDC to her public key. Next he moves the ownership of this “MutableData with the transaction” to the dummy so no one can ever change it. He then sends a message to Catherine saying: “hey, there’s 0.001 PDC for you in this MD address”.

Looking up the tree
Catherine her Decorum wallet just got a message from Bob saying there’s 0.001 PDC waiting for her public key. Her wallet will browse to the MutableData address and checks the for the following:

• Is this piece of MutableData owned by dummy: “DECORUMxxDUMMYxxDUMMY”
• Is the address of this MutableData the same as the signature which Bob did on the previous transaction?
• Are there any coins assigned to my public key?

If this is all correct, Catherine her wallet will look one step back and also browse to the MutableData with the transaction Alice did. Catherine her wallet is browsing up the tree and sees all the transactions done with this PDC coin. The wallet will only approve transactions in MutableData types that are owned by the dummy. It will also check all the digital signatures.

Notice that you can’t go the other way around, so you can’t start with the first transaction and “guess” where all the MutableData items with the transactions are. Only the person that signs a coin over to someone else knows what the signature (and therefore the next address in the tree) is. Only when it’s shared with the next owner, someone else will verify this MutableData address to see if it’s correct.

The difference with other proposed coins on SAFE is that this protocol doesn’t work with person A owning a coin at address Y. This is more like: person A signed a coin over to person B and all details are in this piece of MutableData which is owned by a dummy, and therefore owned by no one.

A big pro is that this idea by @Seneca could be implemented and tested the moment that MutableData and the “transfer of ownership” are live. Maidsafe told us already that we are quite close to this one. Another big pro is that these coins are divisible just like Bitcoin is. No problem to sign over 0.00000000013 PDC to someone else.

I hopefully explained it in a way that more people can understand it. It was confusing to me in the beginning as I was quite used to a person owning a coin because he owned an address.

[DavidMc0]

I greatly appreciate this explanation - thanks @anon40790172.

Transactions will be fast, cheap and secure. Access will be easy (even to non-techies). Wallet apps will be relatively simple to produce. Exchanges between coin types should be relatively easy to develop. Possibilities will be endless!

Very excited to see this implemented on Safe… it’ll take the crypto currency world by storm

[neo]

Thanks @anon40790172, you have done a service to all of us who at this time did not grasp @Seneca’s method.

My only question is a general one and that is what impact on the network storage with this style of “reverse transaction chain”. Seems like a reverse linked list implementation if I grasp the concept. That is what impact will it have when people are sending around “0.00000000013 PDC” to friends and so on. Sounds like a lot of MDs out there after a while

[Seneca]

Nice explanation @anon40790172!

@neo

My only question is a general one and that is what impact on the network storage with this style of “reverse transaction chain”. Seems like a reverse linked list implementation if I grasp the concept. That is what impact will it have when people are sending around “0.00000000013 PDC” to friends and so on. Sounds like a lot of MDs out there after a while

That’s right, but remember that a transaction like this has a PUT cost, so extremely small transactions like that aren’t really cost effective to make. The transaction cost would be much higher than the transacted value.

[Al_Kafir]

Forgive my ignorance of these tech issues, but I was just thinking about the Safecoin divisibility issue. I took from that discussion that just creating smaller denominations of Safecoin wasn’t practical because of the strain put on the Network by all the extra transactions. I’m just wondering how this doesn’t apply here. Is it to do with the difference in data types or something?

[neo]

@Seneca

That’s right, but remember that a transaction like this has a PUT cost, so extremely small transactions like that aren’t really cost effective to make.

Yes that was my understanding. I guess I was thinking big in that PDC is worth many 100’s of dollars and people are sending small amounts.

@Al_Kafir

Forgive my ignorance of these tech issues, but I was just thinking about the Safecoin divisibility issue. I took from that discussion that just creating smaller denominations of Safecoin wasn’t practical because of the strain put on the Network by all the extra transactions.

My suggestion on divisibility is not to do that because of the amount of MDs needed for all those denominations.

Seems @Seneca;s solution is more of a chain of transactions rather than storing PDC “coins” (or other alts) as a piece of data, but rather the transactions is stored as a piece of data. Bitcoin store the balances and transactions in blocks on a big blockchain. @Seneca is storing many mostly independent chains of transactions (not one huge one)

[Seneca]

@Al_Kafir

I’m just wondering how this doesn’t apply here.

There’s still a cost to divisibility, but it’s a different model as @neo just explained. It’s very hard to quantify such a cost, especially since it also depends on the popular future use cases of a coin. The cost in this case is more constant than in some other proposals, because there’s no difference in cost between splitting a coin into 2x 0.5 and splitting into 0.9999 and 0.0001.

@neo

I guess I was thinking big in that PDC is worth many 100’s of dollars and people are sending small amounts.

That would be the day wouldn’t it?

I guess in that case the value transfer warrants the network cost. I agree that we should try to keep network strain to a minimum in everything we develop, but at the same time it’ll be the responsibility of the SAFE algorithms to regulate the cost of network usage to keep it healthy. The demand for MutableData will likely be vast regardless of this particular idea. It’s just so shiny!

[anon40790172]

@neo

Bitcoin store the balances and transactions in blocks on a big blockchain. @Seneca is storing many mostly independent chains of transactions (not one huge one)

This is it. Decorum transactions ARE just PUTs of MutabelData to the network. Maybe even 100 KB. small.

Here’s regular storage on AWS:

Let’s say it’s 2 cents per 1000 MB. of data. On SAFE we’ll be much cheaper, so let’s say we’ll store Immutable Data for 1 cent per 1000 MB. Now what price would be fair for 100 KB of MutableData? We’ll use it on SAFE for chats, replies, forum etc. So what would I be prepared to pay the network for this reply to you?? I guess we want the whole planet to join SAFE (even third world countries) so a fair price for 1 PUT of MutabelData should be 0.1 cent. That’s 1 tenth of a cent. I guess most people would be ok with that. So in that case prices for storage on SAFE would be:

1 PUT ImmutableData = $0.00001 in Safecoin
1 PUT MutabelData = 100 PUTs of ImmutableData in Safecoin ($0.001)

Prices will differ of course, but let’s assume this is a fair price.

• A decorum transaction would cost 0.1 dollarcent that way. So making a transaction of 1 cent would give you a 10% transaction fee, which is not that smart.

• Making a 10 cent transaction would cost only a 1% transaction fee (0.1 dollarcent for 10 cents in total).

• Making a 1 dollar transaction would cost you only 0.1% transaction fee (0.1 dollarcent for 100 cents in total) .

So it wouldn’t make sense to do small transactions.

[DavidMc0]

@Seneca

That would be the day wouldn’t it?

I’m not sure how likely 100s of dollars per PDC is, but Steem currently has a market cap of $40m.

If Clikes reached that market cap with 100m coins in circulation, that’s be $0.4 each - 24x today’s PDC price (edited to correct terrible maths!)

On a less pumpy note, will Decorum offer functionality to enable custom token creation on the Safe network using this method?

[Seneca]

@DavidMc0

On a less pumpy note, will Decorum offer functionality to enable custom token creation on the Safe network using this method?

Not sure if that’ll be part of the core Decorum software, but that will be possible for sure. Once we have the first implementation of this concept it’d be trivial to provide it.

[digipl]

I know that the possibilities are infinitesimal but, Is not safer if the "dummy” public key was different every time?
Something as simple as xor (name) would suffice.

[tfa]

I like the way child addresses are defined by using signature on previous data because it makes them unpredictable, thus avoiding squatters on them.

I have some remarks though:

• The root transaction is not defined. I don’t see how anybody can be prevented to create one. Is it simply by publicly publishing the address of root structure of the altcoin, and then the app has just to follow and check the chain until this transaction?

• The receiver signature is missing to indicate acceptance of transfer by the receiver (to avoid involving users that don’t want the deal).

• There is an ambiguity about owner field: At one place, it is a dummy public key (needed to prevent mutation) and at another place, it is the current owner (also needed to check the signature of previous data).

• Signatures are not checked by rooting layer but by app which is less secure.

This last critic is directed to MaidSafe which removed signatures field when they reimplemented SDs with MDs.
I think that SDs would be better suited for this use case than MDs.

[digipl]

@tfa

There is an ambiguity about owner field: At one place, it is a dummy public key (needed to prevent mutation) and at another place, it is the current owner (also needed to check the signature of previous data).

There are two signatures states. When you are the last transfer of your chain the signature is the current owner and, when you made a child transfer, you must change the signature to a dummy owner.

@tfa

The receiver signature is missing to indicate acceptance of transfer by the receiver (to avoid involving users that don’t want the deal).

Well, that’s the same of current blockchain. If you have the public key of somebody you can send a transfer.

@tfa

The root transaction is not defined. I don’t see how anybody can be prevented to create one. Is it simply by publicly publishing the address of root structure of the altcoin, and then the app has just to follow and check the chain until this transaction?

You need to calculate a name that hash(name)=name(original root transaction). Almost impossible.

[anon40790172]

@tfa

The root transaction is not defined. I don’t see how anybody can be prevented to create one. Is it simply by publicly publishing the address of root structure of the altcoin, and then the app has just to follow and check the chain until this transaction?

@Seneca told me he has an idea for that which wasn’t shown in the presentation to keep thing a bit simpler. But I would suspect a part in the decorum protocol to handle this. Could be several MutabelData types with links to the root addresses of all the coins or something like that. I would love to see a “burn” of some PDC as well to make start a coin etc. Should cost a bit of money IMO to start a new coin.

@tfa

The receiver signature is missing to indicate acceptance of transfer by the receiver (to avoid involving users that don’t want the deal).

No need for IMO. Just with blockchains, you get something and you’re good. Otherwise these coin would be locked in the system. If I send you a coin, and you only take it after 4 years the transaction is locked inside a piece of MutabelData. I can not send the coin to someone else at that time.

@tfa

There is an ambiguity about owner field: At one place, it is a dummy public key (needed to prevent mutation) and at another place, it is the current owner (also needed to check the signature of previous data).

I don’t get this one, the current owner of a coin is owner of the MutableData for only a “second” as the ownership is moved to the dummy after that.

[19eddyjohn75]

I wonder how publickeys will work with different wallets/coins? In @bochaco’s wallet it was clear that you can use whatever name you want as a publickey/privatekey, thankscoin went to whoever created the pubkey first. But what happens when you got 3 different SAFE Network wallet that can all receive the same coin, with 3 different users who got the same pubkeys? Who will receive the coin when you send it to the pubkey? It seems whoever created the pubkey first, but I’m not sure.

Or is the approach to enable using whatever you want as a publickey/privatekey not the way to go?

Thanks btw @anon40790172 for the explanation, great idea @Seneca

[digipl]

The Bochaco’s wallet is a nice test, but in the real network all your publickeys must be derived by your unique Public IDs. Of course two user never can have the same publickey/privatekey.

[Seneca]

@tfa

I don’t see how anybody can be prevented to create one. Is it simply by publicly publishing the address of root structure of the altcoin, and then the app has just to follow and check the chain until this transaction?

Yes, everyone will be able to create a new root transaction, but that’s a new coin type then. The exception being if the coin is minable as per my original Clike proposal, in which case the new root transaction has to contain a valid proof of work and has to abide to other rules that the wallet enforces.

@19eddyjohn75

But what happens when you got 3 different SAFE Network wallet that can all receive the same coin, with 3 different users who got the same pubkeys?

This shouldn’t be practically possible, ownership of a public key means possession of the corresponding private key. If you don’t share your private key with anyone, none else can receive and spend your coins. Key management will ideally be managed entirely by the software, with the user interacting only with names. Those names will either be the official DNS names, or a reference to them (alias) through a petname system.

[Seneca]

@Seneca

The exception being if the coin is minable as per my original Clike proposal, in which case the new root transaction has to contain a valid proof of work and has to abide to other rules that the wallet enforces.

I’m currently looking into ways of making the proof of work for a newly “mined” coin part of the network name. In the original proposal it’s possible to buy the MD for a new coin from the network before you found the proof of work, essentially enabling squatting and creating a market for “non-mined” coins. It’d be nice if that can be prevented.

[DavidMc0]

Would it be feasible for other crypto currencies to ‘port’ their blockchains into this structure?

For example, if all Bitcoin addresses with a balance were assigned addresses on a structure as described, I guess you could have ‘Safe BTC’, which gives all Bitcoin holders a version of Bitcoin that can scale, and transact cheaply.

Not sure how much that would cost in terms of puts, but if it could be automated, some alt coins may port to Safe, just as some are moving over to the Ether blockchain from BTC due to various issues.

[Seneca]

You could port the UTXO set of a blockchain to a system like this, but things like P2SH would be broken, so you won’t for example convince the Bitcoin community to switch.