7. Data Model
7. Data Model
Detailed Description of the 1CoinH Technology
Start procedure
First understand that every person collects data on his phone that is necessary for him to prove that the coins he received are legitimate. These are the Self-Sovereign Identity cards and the blockchains of all people that he received coins from. The ID-Card is also what the user starts with. Before the user can start receiving his coins, he first needs to create an ID-Card that he can share with the other users he does transactions with. The filename of the ID-Card holds the hash of the ID-Card so it can easily be traced on the phone and nobody will be able to change the ID-Card without changing the hash of it. This way users can check of the ID’s are valid.
Blockchain
On each phone will be a large amount of blockchains collected (of all persons the user received coins from and paid coins to). Instead having a complicated puzzle solved, the stability of the 1CoinH system depends on the comparison of the parts of the blockchains that should be mutual. If the software that checks this (that we named “the Sentinel”) founds irregularities, the receiver of the coins can simply dismiss the coins, and when others do similarly, these disputed coins will eventually depreciate to zero. This is the reason for collecting all these ID-cards and blockchains. The ID-Cards are named with the 64-character hash plus .png, The blockchains are also named with the 64-character hash but add .txt to it.
Initial String
- The initial string starts with the name of the person, followed by a separator “|”, and the birthday, followed by a separator “|”, the birth-hour of the person, then the timestamp of the mutation of this file, also followed by a separator “|”,
- The ID-Code of the person (=also the filename), followed by a line-separator “<”,
Transaction String
- You see a “S” or “R” followed by the ID-Code of the person you do a transaction with. “S” means that this transaction-partner is Sending the coins. With “R” it means that this transaction-partner is Receiving the coins, again followed by a separator “|”. The ID-Code is the 64-Character Hash or is just the number of appearance in the blockchain, if this ID-Code was already used in the blockchain. This is to keep the blockchain small. When people update their ID-Card, the new ID-Card hash will be added here as well.
- The timestamp. The time is UCT (Coordinated Universal Time). In the blockchain it however looks like this: “2202:5959999” where the part before “:” is the “transaction-hour”, which is the number of hours that have passed since January 1st, 2022 at 00:00. After the “:” sign you see MMSSmmm (where MM=minutes, SS=seconds and mmm=milliseconds), followed by a separator “|”.
- Next is the hash of the Security Image followed by the “|” separator.
- Then you see the payment amount that is pegged to the transaction-hour + separator “|”.
- Then you see a list of max 5 originators + “|” + and their payments, all separated with “|”.
- Next is the Hash of the entire blockchain until this point and is added to the blockchain + separator “<”
The transaction string repeats/grows with every new transaction.
Dealing With The Others
The next issue is what to copy from others? What is the necessary transaction data from others for the “Sentinel” (see next chapter) to check which coins are trustworthy? To illustrate this, let’s look at an obvious “crime”. A person could create a fake account and transfer coins from that fake account to his own account. This means that you should reject any coins that come from a person that you don’t personally know. This is also a paradox. Because if everybody does this, than all coins become trustworthy and you could start accepting coins that are accepted by others. But for now we should just focus on the people we have done direct transactions with. This means we can accept the self-created coins of people we do direct transactions with or we accept the coins of a person we do a transaction with, that are self-created by people we did previous direct transactions with. Later we can possibly expand “the Sentinel” and the collection of (parts of) blockchains of others to coins that are collected by people we trust very well. In the beginning it is better to stick to people that are very close to create a more solid trust in the system.
An Example
- Person A has a blockchain with persons B – C – D – E
- Person F has a blockchain with persons G – H – B – I – J
Now when person A wants to sell something to person F, he can accept the self-created coins of person F, but he can also accept the coins that are originated by person B. The problem is however that person F can just made up the transaction with B. So person A could check with B if the blockchain that F presents is coherent with the blockchain of B. a could do that before the transaction with F, but could also do it later (with the risk he will found out he has been deceived by F). The problem F has, is that if he is swindling A, this will very likely come to light which will make it very difficult to use his self-created coins in the group of A, since A will be feeling very negative about F. By the way, the same can happen when F hides previous spending of his self-created coins.
In this example it is clear that when A does a transaction with F where A accepts self-created coins of F plus some coins that are created by B, A needs to collect the personal blockchains of F and B. When the blockchain of B is properly overlapping with the older blockchain of B that is collected by A when he did an earlier transaction with B, A can just replace the blockchain of B with the newest version.
The procedure to do the transaction goes like this: First the person that pays sends his own blockchain to the receiver of the coins. The receiver checks is there are third people that sent their self-created coins to F that also sent them to receiver. Based on that the receiver decides which coins he will accept. He informs sender about which coins he will accept. The Receiver also adds a ‘security hash’ of a picture of a contract or other document or picture that proves that the transaction actually occurred and shares that document with the sender. The sender subsequently sends the blockchains of the mutual third parties to receiver plus the new hash of his blockchain including the security hash. Receiver then checks the history of these blockchains and if he sees no issues, accepts the coins. The receiver adds the transaction to his blockchain, add the new hash and sends the updated blockchain to the sender that also updates his blockchain with the reduced coins. He hashes it as well and sends it to the receiver to finalize the transaction.
If there are irregularities then the receiver will obviously not accept the corrupted coins or abandon the entire transaction. It is up to the receiver if he will contact the third parties if the fraud has to do with their coins. It is also likely there will be more centralized organizations like the police or administration centers that will be asked to take a closer look at the fraud and help warning the community about the details of what has surfaced. To avoid the blockchain files to be overwritten by blockchains of the same person with another date, the date and time of the last transaction will be before the hash of each blockchain mutation.
Still Have Questions?
The 1CoinH / Ethical Money system is nothing like we have ever seen before. We can imagine you have plenty of questions left.
Please don’t hesitate to ask us. It also helps us to understand what we haven’t explained well enough.
