Use MOON coin to emulate a Certificate Authority

The purpose of this post is to release a business strategy / organization to public domain such that no one can patent it in the future. If this idea has already been conceived and/or patented, please consider the good to the world of releasing it. Most certainly all the bits and pieces for this already exist on this forum. This is simply my digestion of it all. Please do feel free to take credit for being the 1st to think of any of this.

This proposal is to re-purpose a cheap copy of Bitcoin, MOON coin for example, to act as a Certificate Authority for forming trusted client/host connections.

****************************************************************************

Node A wants to talk to Node B, privately. Since they can’t see each other, how does Node A even know it is really talking to “the” Node B?

Task: Emulate a Certificate Authority in a distributed network.

Step I -- Determine identity -- that Node B is who it says it is.

Suppose that Node A and Node B are already established members of a larger network of computers. They have other nodes with which they have securely transferred public keys. Let’s say Node A has secured communications with Nodes D,E,F,G,H … X,Y,Z. And Node B is also a trusted member, and can securely communicate individually with Nodes D thru Z ... even if only by a few degrees of separation.

Node A can randomly pick 4 other nodes D,E,F,G and assemble a data packet where it encrypts a random number with D’s pubKey … say 149. Then Node A can encrypt another random number with E’s pubKey … say 832 … and so on for Node F and Node G. Finally, Node A can pack all that together, add another random number (141) and encrypt the whole packet with Node B’s pubKey and then broadcast the packet to Node B.

In order to accomplish this, Node A does need access to a reliable copy of a DataBase file that contains everyone’s Node address (ex: E,F,G) and a corresponding pubKey. It would be important that Node A knows that the DB file was not tampered with … what better way to do that than to secure the information within an existing coin network … say MOON coin … since they are cheap.

On to Node B

Once Node B receives the packet, it decrypts the packet as only it can with its private key. It sees 141, but all the rest of the packet it sees as a blob of encrypted gooe. To prove to that it can read the 141, it posts a MOON coin transaction for 141 MOON (or whatever is least amount -- must also account for fees). Node A can block explore MOON coin transactions to see if the right MOON address posted the correct amount.

Step 2 -- Prove you are who you say you are … and that other people trust you

Now, Node B must also prove that it is a trusted member of the network. Never is the information broadcast about who the other four nodes are. The packet must now get broadcast through the network securely. So, B, if it is a trusted member of the network, must have a secure connection with several other nodes already … Say X is one of them. Node B will use a key pair it already has established with X to encrypt the packet … and X won’t pay any attention to such a packet unless it comes from an established trusted source.

Node X

Once Node X receives the packet, it first decrypts the whole thing with the private key that it uses specifically to communicate with B. Then it tries to decrypt the interior sections of the packet with its private key that goes with its posted pubKey. Nothing works, so Node X knows that packet was not intended for it, so it forwards it off to its trusted connections. (of course there needs to be code to limit how many times this happens). Say, Node D is one of X’s buds. Node X encrypts the whole packet with a ‘semi-private’ pubKey it only shares with D and forwards it along.

Node D

Once Node D receives the packet, it first decrypts the whole thing with the private key that it uses specifically with X. Then it finds that it can also decrypt the number 149 (from above). So then, Node D posts a transaction for 149 MOON coins.

Process repeats until all intended nodes get a look at the packet from a trusted source and post MOON coin transactions (between 2 MOON accounts that each node controls incidentally).

Node A

After it checks that all 5 transactions have posted to the MOON blockchain, it knows that it is indeed talking to Node B, and that Node B is a trusted member of the Network. Node B could perform a similar check on Node A and then they can negotiate the swapping of keys as needed through their common trusted connections, and form a new, private, and trusted connection between nodes A and B.

Vulnerabilities anyone?

...besides 51% attack on the MOON blockchain

Could this be a revenue model for alt-coins … to double as Certificate Authorities for distributed networks?

If not MOON, then it should be easy to recycle some cheap copy of Bitcoin for the task of maintaining this list - design it not to save every transaction, just a running list of the latest transactions ... nodes could frequently update their pubKeys and post them as transaction labels in the blockchain.