Document Partner APIs

[warrenmining]

MS uses multiple third-party Software/APIs to run critical tasks. Some of these tasks include: monitoring machine performance and sending commands to the machines (Foreman), storing machine performance data and querying that data (Foreman + Google BQ), customer ticketing for machine issues (Jira Service Management), asset management (Insight on JSM), converting hashrate to bitcoin mining revenue and reading revenue metrics (Luxor Pool), custody bitcoin for a client before transfer (Anchorage), reading bitcoin mining revenue and transfer data per client (Anchorage). This task aims to document locations and integration into the MS stack.

[warrenmining]

All material can be found and edited here

[warrenmining]

Foreman

Foreman is a Miner Control System. Foreman connects to all of our machines on a site-by-site basis. One Foreman connection (one site) is called a "pickaxe." A Foreman pickaxe is a container application running on an on-site server (Dell r710) at our facilities. All machines must have a network connection to mine bitcoin. The server is also connected to the network, and the pickaxe can read machine data and send commands from there.

Foreman guides on setting up a pickaxe and adding miners to the pickaxe can be found at these links.

Documentation for the Foreman API, where all read/write commands can be also be made, can be found here: https://docs.foreman.mn/

[warrenmining]

Luxor

Luxor is a Bitcoin mining pool.

A brief explanation of bitcoin mining pools: All bitcoin miners perform the SHA-256 algorithm. If a miner correctly calculates (brute-force guesses) the correct hash to create a new block on the Bitcoin blockchain, that miner will receive the block reward of the previous block. The block reward is currently 6.25 BTC, and it will halve in 2024, 2028, etc. Since there are so many bitcoin miners trying to guess the correct hash, it would statistically take years for a single bitcoin miner (Machine) to receive the block reward. Instead of mining directly towards the bitcoin blockchain, miners will aggregate themselves in Pools. If a miner in a mining pool guesses the hash correctly, all miners will split the block reward. We receive a steady bitcoin revenue per miner in the Luxor mining pool. We are essentially selling our ability to mine bitcoin to Luxor for bitcoin at a constant rate per unit time based on how hard it is to mine bitcoin.

Luxor API The hierarchical structure of Luxor is Account > Subaccount(s) > Miner(s). An account is a unique email address with its UI interface and API keys. Subaccounts are individual "buckets" that store bitcoin and have their wallet configurations, meaning wallet addresses, amount thresholds (ex. 0.5 BTC), and time thresholds (ex 24 hours) are configured at the subaccount level. Subaccounts are given a string id (ex. miningstore). There is a Luxor-defined parameter of a maximum of 50 subaccounts per account.

Miners are the physical Machine located on-site. The digital representation of a miner is called a "worker." Workers can be given a worker id and work for a specific subaccount. There is no limit to the number of workers which can "work" or "mine" for a single subaccount. How does a mining pool know which miner is working for which subaccount. Well, miners use what is called a "workername." A worker name is the unique id which a machine is programmed on-site to broadcast to the mining pool with their data. This workername is "[subaccount].[worker id]." An example workername would be miningstore.miner1.

[warrenmining]

Luxor API documentation is found here: https://docs.luxor.tech/docs/schema/getting-started

[Josh-The-Miner]

Can you share which endpoints we hit in each API? Also, if there are any oddities about any of those endpoints, please note those. Hopefully the docs are 100% accurate, but I am not holding my breath on that.

[warrenmining]

are

We do not currently utilize the Foreman api. We currently utilize the Luxor and Anchorage APIs in MMP Automation. I recommend we separate a more in-depth analysis on endpoints we hit for a different issue#, that information is only stored in the code and, for me, it's easier to explain what we're doing with the API itself and have the endpoints be implied. We want them to be explicit, but it would take too much time to collect with the current state of our code and devops processes. It's all duct taped.

I still need to provide explanations about Anchorage and Jira softwares.

[warrenmining]

Anchorage

Anchorage is a third-party custodian of bitcoin. They are essentially a Bitcoin Bank. The MMP product was set up (2020) to utilize this third-party custodian for client vaults to hold bitcoin to then be paid-out to Aurum in Fees or to the client as Mining Profit. Anchorage also covers our butts for KYC and anti-terrorist anti-money-laundering laws. Because the BTC passes through Anchorage's hands, they are on the hook, it removes liability from us. There are other companies which can assist with KYC and anti-bad-guy laws, such as Chainalysis.

Anchorage is our SoT for determining monthly client revenue in the MMP product, and any transfers of BTC for profits/fees are done through Anchorage's API or UI.

Anchorage API documentation requires login access, we are working to create a copy of their documentation to share in our org.

[warrenmining]

Jira Service Management and OpsGenie

JSM and OG are software tools utilized by Mining Operations. JSM is used to manage Issue-Ticketing, where the incoming pool is monitored by Technicians. JSM also houses our Asset Management in the add-on Insight. OG has Mining Ops schedules for Technicians, which can be utilized for On-Call alerting.

APIs for these Atlassian products and other Atlassian products have not been utilized yet.

[warrenmining]

DocuSign

MiningStore has utilized DocuSign for legal. Their api(s) have not yet been implemented in our operations.