Open Money - Security/Sync Concept (Inspired by desentralized peer-to-peer bit sync)

1. First time account setup request - required: Birth Certificate Data ( fullname, datetime of birth, place of birth, gender, mothers fullname, fathers fullname, age of parents, etc )

2. When the account is verified by the network via cron script, transactions can begin and a [unique crypto name/code/id] is added to the account based on the birth certificate data. (not sure yet about who will be in charge of verification, maybe the local police, open for suggestions and methods of how the system will validate this based on required data)

3. Transaction rows written to file with seperators or binarycode [unique crypto name/code/id] (file name based on data in file ex. $2a$08$xFSFVye5/8mI02zyzzGK7uQxQNYi70d3.WzquqokGQTGCUOnNxMDG )

4. The file name of the transaction file will change everytime there is new verified data synced by cron script.

4. When an x amount of rows are exceeded in the file, it\'s moved to a folder with current date for archive all done by cron script. Also current balance connected to accounts are written into the new file and then the process continues.

5. Transactions are verified when the cron script has synced to all nodes.

6. Every node will work as a bank and have a unique number from the node index file/database, this number is included in the account number of the user as a alias for the birth certificate number connecting to main and sub accounts to make it easier when transfering from and to accounts by users.

7. If there is an anomaly in the file that differs from the other nodes, this node will be excluded from the sync process and accounts on node will be frozen, until node admin finds the problem and request to download and overwrite the current file with the current node file from any working node and get back in sync.

8. The anomaly will also be logged by timedate in the file for future investigation.

9. Rules of how this system will work will always be able to change in a direct democracy between the nodes and it\'s users over time where the majority decides, because that will be the only way to change anything when this node network is to big for us to change anything from our current server access. (right now we have two nodes that we have server access to, in the future there will be millions)

---

Please comment/correct/tips me on this because this is something new in the making, and I had this idea last night (dream) and need feedback since it\'s all about making new systems for everyone by everyone.