Information Sharing and Security
The GBUdb Cloud
When an IPs good or bad counter reaches an even power of 2 due to a new encounter then an "alert" is sent to the GBUdb cloud. The alert contains the composite data for that IP from the perspective of the node creating the alert. The SYNC server integrates this information into the "consensus" and returns a "reflection". The reflection is a composite record for that IP from the cloud's perspective. The reflection is then integrated into the local GBUdb node.
In order to maintain individuality and prevent poisoning, the "consensus" database is isolated from each GBUdb node mathematically. The maximum influence any single transaction can convey is magnitude of the "opinion" of each peer based on the forumula:
LocalCount = LocalCount + Log2(RemoteCount)
For example, if the good count of one peer is 7 (requiring 3 bits) then the amount that the other peer will accept as influence is 3. If the good count of one peer is 255 (requiring 8 bits) then the other peer will be influenced by a count of 8.
Since this equation works at each interaction then the influence of any single node on any other single node across the cloud is even less.
A <---> (SYNC/CLOUD) <---> B
Suppose node A attempts to influence node B by posting a good count of 1024. 1024 requires 11 bits so the cloud registers 11 where perhaps the original count was 0 (to keep things simple). When B syncs with the cloud the reflection will show a count of 11. The number 11 requires 4 bits and so the influence of A on B has been limited from 1024 to only 4.
The combination of SYNC event pacing and the above transfer formula has the effect of giving the general consensus of the GBUdb cloud precedence over any single (or small number) of nodes and ensures that the reflections received by each node are diluted enough to preserve individuality while being potent enough to encourage a perspective that is likely to be correct given the overall experience of the cloud.
The SYNC process
Every minute or so (dynamically adjusted by the SYNC server), each SNF node connects to one of our SYNC servers to share it's GBUdb data and report errors and statistics. The data that is sent and received is generally plain-text (so you can see what's happening) however strong encryption is applied to the authentication protocol.
In addition to this authentication scheme, the SNF SYNC servers also monitor the behavior of SNF nodes and automatically reject connections that are unknown or behave badly in any way.