Distributed hubs that provide supporting services to your Blockcore based blockchain.

The Blockcore Hub is a distributed system that integrates with Blockcore Blockchain technologies.

The Blockcore Hub can be used to build distributed apps and systems, that store data and metadata off-chain, but utilize the blockchain for data integrity, data validation and signing.

The functional requirement for developing the Blockcore Hub, is to have a distributed network for exchanging data securely, but that keeps data off the main blockchain.

Example on usage is a payment scenario, where a user scans a payment request by another individual, or a merchant, and the payment app can retrieve data (metadata, including company logo or profile photo) about the merchant/individual from the Blockcore Platform. This data can be used to add trust and identification on the validitity of a payment request.

Without this data and validation, there are many possible attack-vectors in a payment scenario, for example the QR-code for payment can be manipulated on the receiver device, and the payer has zero ability to verify that the payment address.

Other examples is identities and metadata attached to identities. Metadata must be open for edited and withdrawable by the individual who owns the identity.

The Blockcore Hub relies heavily on the Blockcore Identity Framework.

BIP 32

m / purpose' / coin_type' / account' / change / address_index

The purpose field: BIP 43

"We encourage different schemes to apply for assigning a separate BIP number and use the same number for purpose field, so addresses won't be generated from overlapping BIP32 spaces."

Registered coins: BIP 44

• Identities does not require any metadata and can simply me recognized as public key (address derived from public key).
• Users can have any number of identities, that are derived from a custom path in their existing HD-wallet.
• Should HD paths be similar across Blockcore-base blockchains and result in different visible addresses, but have the same private and public key values, or should they be entirely different with different paths?
• Should purpose be used?
• m/44'/60'/0'/0

DIF: https://identity.foundation/
DID: https://w3c-ccg.github.io/did-spec/

The Blockcore Hub relies on the Blockcore Networking Framework to perform true peer-to-peer networking without relying on firewall port opening, and has high-performance and encrypted data-transfer between participants in the network. TODO: Research into WebRTC and the possibility of supporting WebRTC in the full node.

When a Point-of-Sale terminal or any user of the Blockcore-compatible wallets presents a payment request, they can decide if the payment request should be anonymous or share identity (public key) and encryption key (optional).

To avoid putting technical information into the Label and Message values, which most modern wallets will be able to read and display to a user, we must rely on a custom parameter for the identity. This means a payment will be performed and displayed normally on any third party wallet, but the Blockcore-compatible wallets can potentially display additional metadata about the merchant/receiver.

NBitcoin.Payment.BitcoinUrlBuilder uri = new NBitcoin.Payment.BitcoinUrlBuilder();
uri.UnknowParameters.Add("identity", "Ccqvt3HZBd9M8r3RyuR89Wbt4j");
uri.UnknowParameters.Add("identity-key", "XXX"); // Optional
uri.Amount = new NBitcoin.Money((long)20000);
uri.Label = "Average Joe Coffee Shop";
uri.Message = "Cup of coffee";
uri.Address = NBitcoin.BitcoinAddress.Create("bc1q3dmr8mtycf3ummrh84mye85ueu87ussllkc0v3", NBitcoin.Network.Main);
var url = uri.ToString();
// url = bitcoin:bc1q3dmr8mtycf3ummrh84mye85ueu87ussllkc0v3?amount=0.0002&label=Average%20Joe%20Coffee%20Shop&message=Cup%20of%20coffee&identity=Ccqvt3HZBd9M8r3RyuR89Wbt4j&identity-key=XXX

This address can be encoded into an QR code for quick scanning, and is based on the BIP 21 specification.

• Should the identity be given in clear-text, or should it be unique per payment and require decryption (address+identity=key)?
• The identity-key is an encryption key that opens up private meta-data of the receiver. This is optional.
• When a user performs a payment, should they persist the identity and identity-key on their private vault on the Blockcore Hub? Unless they do, they either have to store the metadata at the point of payment performed, or they will be unable to restore (during a wallet restore) a full transaction history in the future.
• Storing the full history makes it hard for others to withdraw metadata, so really only the identity (and perhaps identity-key) should be stored in the hub. This means in the future, a merchant/individual can withdraw all metadata and when a wallet is restored, the history information will disappear (not be available).
• Receiving the encoded payment request URI should additionally support NFC (Near-Field-Communication). NFC support enables PoS (Point-of-Sale) setup where no screen is needed.
• Data retrieved from the hub, can be integrity-validated to ensure it is untamprered.

When a user utilized the services provided by the participants in the distributed nodes network, they will be performing payment to all members of the network. These payments are automatic, and users will need to have wallets with balance to perform (automatic) payment for services utilized.

• Users running hub nodes should receive payment for utilizing storage.
• What distribution model makes sense for the hub nodes?

The hub should enable encrypted and fully anonymous secure communities. Enabling anyone, friends, neighbourhoods, merchants or anyone to communicate secure and anonymous. The same identity used for payments, can also be used for communities.

A community owner should be able to decide if to utilize the hub nodes for persistent storage of encrypted community content, or if the hub nodes should only be used for message relay.

The community will largely be built as a client-side implementation, with persistent storage in the web browser.

Hub should have the ability to store and shared metadata related to sidechains that runs on the blockchain. This is useful to have additional information available, that can securely verified and updated by owners of sidechains.

Hub should be able to store contracts, both in form of analog documents and semi-smart contracts.

Hub should support subscriptions, with the ability for auto-withdrawal from multi-sig wallets that are manually or automatically populated from regular wallets.

Hub must support the ability to store Point-of-Sale databases for merchants. Merchants must pay for this service, but it will enable merchants to have a fully distributed network of PoS-devices that retrieve the latest database from the hub nodes.

The hub should be able to keep inter-chain links connected to the identities on the hub. This means connecting the ownership or public key on one blockchain with the identities that exists on the hub.

This can be used to verify ownership of cars on a "car-blockchain" (https://vinchain.io/, https://www.carvertical.com/en/), or insurance policy on an "insurance-blockchain". Could also be used to connect sidechains on a Blockcore-based blockchain, with identity that exists on the hubs.

This type of information can be deployed on the Blockcore Hub Portal, where a user can see all their connected assets across multiple blockchains.

As oppose to Scenario 2, where the gateway relays messages and does not expose the IP until the node accepts the request, the gateway could expose all information needed for any hub to connect to any hub.

This would allow hubs to connect with other hubs of their choice, without the gateway having any knowledge of who is connected to who.

One issue with this solution, is the obvious issue of distributed denial of service attacks. With all the IPs easily available from the gateway, then someone could initiate attack on the IPs provided.

This can be mitigated by having a trusted gateway, that is pre-configured either with a known encryption key, or with a list of public keys that is allowed to connect. Then only those hubs will receive information about IP address of other hubs.

After the hub receives HubInfo, and it will continue to do so while connected to gateway, it can attempt to connect directly to a hub. Based on configuration, the hub might auto-accept the incoming request, or wait for a manual approval of the hub administrator.

Notes of how handshaking might work.

1. Gateway startup and hosts endpoint that allows hubs to connect and shared HubInfo instances.
2. Hubs share HubInfo, which includes the public key of the hub. The public key is derived from the auto-generated recovery phrase that is stored encrypted on disk using a key stored with data protection API.
3. Hubs receive all HubInfo updates and keeps a list of online hubs. Archieve hubs/monitoring hubs/surveilance hubs might continuously store HubInfo for all possible future - that is important to remember. If you connect to untrusted gateway and hubs, you might be monitored. While all traffic is encrypted, your IP will still be exposed when connected to third party gateway/hubs. You can configure only to connect with trusted gateway and hubs.
4. A Hub sends an handhake message to a specific Hub. This message is encrypted with the public key of the Hub. The message includes the origin IP, the public key of the connecting hub, and the whole message is signed with the private key.
5. The receiver hub can decide if it will accept the connection. This can happen automatically based on configuration ("approved public keys" or "approved IPs").
6. When a manual acceptance is done, it is the receiver of the invite that does the actual initiation of peer to peer connection.

Thoughts:

• Perhaps the HubInfo that gateway sends to connected hubs should not include the IP address, to protect the individual peers. Instead only expose the public keys (and perhaps additional metadata a hub want to share). Then when a hub want to connect, the gateway will forward the message, if the hub accepts, then the IP will be returned.

• Initial connection with gateway should be based on some sort of trust, perhaps based on a public list of gateways (which should include public key + IP + signature that validates the IP).

Public Key | IP | Signature

{
    "gateways": [
        {
            "pubKey": "3213123"
            "IP": "127.0.0.1"
            "Port": 6610
        }
    ]
}

This could be exposed in a public API, potentially hosted on the Blockcore Platform, that returns a list of all public gateways. At startup, a hub could then query this API to get the most recent IP address of their trusted gateways. The public key should be put in a configuration file.

{
    "Hub": {
        "Gateways": 
        [ 
            { "name": "MyFriend1", pubKey: "3213123", lastKnownIP: "127.0.0.1" },
            { "name": "MyFriend2", pubKey: "7423421" },
        ]
    }
}

Gateways are obvious targets of infiltration, and there are multiple scenarios for that:

• If the IP address of the gateway is taken over by someone else, they can attempt to spoof the previous gateway. This will fail due to handshake protocol between hub and gateway, where the private key will be missing.

• If the infiltration is complete, meaning the server has been fully taken over and private key is available, then there is no way that hubs can distinguish it from the previously trusted gateway.

The only way to discover exploited gateways, is for a manual verification with the owner. This has to be done in-person, with a video conference or voice call. And even then you might not be entirely sure if the gateway host is verifying under duress or not.

One solution to mitigate this issue, is to rotate gateway on interval. This will make the attack surface much larger, especially if the nodes are physically different places hosted by different individuals/operators.

As long as you attempt to initiate a connection to an exploited gateway, your IP will be logged. Therefore expect that if you run a hub, your IP will be known by third parties at one time or another. If you run a public API hub, you are obviously very public.

Thanks to Benjamin Watkins for providing a workable proof-of-concept for P2P communication in C#.

Blockore Hub by Blockore, licensed as MIT Parts by Benjamin Watkins, licensed as MIT