IPFS Mining

From BiblePay Wiki
Jump to: navigation, search


      • WARNING *** THIS PAGE IS UNDER CONSTRUCTION AND IS MISSING CRUCIAL LATE BREAKING DETAILS - PAY NO ATTENTION TO THIS DOCUMENT



Scope: Detail the technical design of the BiblePay IPFS Mining Algorithm.

Reason:
IPFS Mining enables the space to offer document storage, allowing BiblePay to generate revenue by facilitating leased documents to users. This type of mining offers a more efficient alternative to our existing pure POBH (POW) heat mining activity, specifically because more CPU time will be spent in sharing documents in contrast to pure hashing.


Specification:
Each IPFS Miner will register their miners public IP with a wallet command (IE exec associate ipfsminer public_ip). It will be necessary to re-run this command each time the miners public IP changes.

Setup:

An IPFS miner will follow the first time setup guide. This will include exposing the correct firewall ports (IE Gateway and swarm ports), installing IPFS, and configuring IPFS to auto-start.
Sanctuaries:

In this design, we are careful to not modify BiblePay core in a way that the new Sanctuary Business Logic will break third party turnkey Sanctuary solutions.

The Sanctuaries will compile a QoS contract containing corresponding IP quality levels.

Specifically the following protocol will be used to test each running IPFS miner:

  1. Sanctuary requests a list of registered miners (request datalist ipfsminers).
  2. Sanctuary requests a list of leased IPFS hashes (request datalist ipfshashes).
  3. A dedicated thread checks the QoS per miner in the following way.
  4. A deterministic IPFS hash is chosen by the sanctuary in a way that is based on the current quorum rounds back-window block (this keeps the work by all sancs uniform and the contract uniform).

We then query the size of the document stored in the IPFS hash (stored in our txid). Using the actual IPFS hash and size, we construct a deterministic content-range minimum and maximum. For example, if the hash stores a file that is 201,000 bytes, the sanctuary may choose bytes 99,003-100,027 (1k).

  1. The sanctuary connects to the IPFS public IP of the actual miners Gateway port, and asks for a content-range request of 1024 bytes.
  2. The sanctuary stores this in scratchpad #1.
  3. The Sanctuary connects to another IPFS node, and downloads the same content-range request.

If the request was not successful, it tries another node (until max retries is passed). This result is stored in scratchpad #2.

  1. The Sanctuary compares Scratchpad #1 to Scratchpad #2. If these scratchpads match, the sanctuary votes a Success for this public IP. Otherwise it votes a Fail for this public IP.
  2. The process continues perpetually with some sleep in between (so as not to DDOS the network).
  3. After the process breaks, the sanctuary will compile a contract containing: Public IP/ IPFS quality levels.
  4. The Sanctuary will create a governance contract.
  5. Other sanctuaries will create a quorum (similar to PODC).
  6. The highest voted contract will emit a superblock of data.

Note: This superblock is not designed for Payments. It is designed to hold QoS levels for the entire network.

  1. The superblock is accepted by the miner who mines the superblock.
  2. The network stores the superblocks disseminated data in a format of QoS percentage by Public IP. This allows the local miner to see her/his own QoS level.


Mining Activity:
The mining thread in BiblePay-QT will have a dedicated process to request leased document hashes attached to transactions in a list. It will automatically issue commands through the IPFS local API to instruct IPFS to pin these documents. (Later, content-ranges will be queried by sancs against the local miner, so pinning is necessary to survive garbage collection).

Once the local IPFS repository (on the miners machine) is pinned, BiblePay will run a garbage collection process on the miners IPFS node- this will physically delete any documents that are no longer leased, or documents that are marked for deletion (conforming to GDPR guidelines).



Heat Payments are modified to: Look Up Yesterdays QoS level for the solving IP. Reward is QoS Level * Heat Payment Reward. The solution must have an IPFS Miner's signature (IE block cannot be forged by another miner).

With this system, BiblePay would then gain the disk space utilization available over hundreds of mining machines. Miners who have very small hard drives will be compensated less, because some of their IPFS hashes will be missing (resulting in lower QoS).


With this large network storage capacity, it will facilitate Christian video content uploads (IE a bulk converter for Christian YouTube content, for example).


Hashing: POBH is still used as our hashing algorithm. The difference being that the reward is multiplied * the QoS level of the public IP of the miner. If a node is not running IPFS and solves the block, the block reward will be very low (IE 1%).