FAQ's#

Braiins Farm Proxy should run with any major pool. It was tested on publicly available mining pools: Braiins Pool, AntPool, Poolin, Binance, ViaBTC, BTC.com, Luxor, SBI Crypto Pool, F2Pool.

In case of detecting invalid/rejected hashrate from downstream or upstream, please contact Braiins support. To help our team diagnose and solve any issues you might have, please provide information from the Grafana "Debug Dashboard" to our support team.

There is always going to be some invalid hashrate on both upstream and downstream. This comes down to downstream connectivity, internet quality, latency, stale submits, or stale jobs caused by a currently mined bitcoin block. The "natural" level of invalid hashrate ratio varies from miner to miner but as a rule of thumb anything above 1% should be considered too high. If you are using satellite internet you may experience a much higher invalid ratio because of higher latency and sensitivity to the weather.

Downstream, there is a single connection from one miner to the proxy. This means that there are as many connections as the number of miners. Each miner is hashing and submitting hashes which fulfill their own individual difficulty. Each miner is therefore producing one Poisson process. The whole downstream is then created as the aggregation of all the Poisson processes across all the individual miners. Since the Poisson process has high variance (variance is equal to the mean) it is quite volatile. When you aggregate lots of Poisson processes together, the volatility greatly decreases. The picture below shows that downstream standard hashrate is therefore quite a flat line.

On the other hand, upstream is created with just a couple of connections, which means it is created by a couple of Poisson processes. Aggregation collects the submits of the miners but only propagates up to the pool the submits which meet much higher upstream difficulty. Therefore the picture below shows a more volatile upstream hashrate. The picture shows 2,320 downstream connections and 46 upstream connections. Important thing is that in a longer time frame (approx 3 hours or more) the average downstream hashrate equals the average upstream hashrate (or in other words cumulative downstream shares equal to cumulative upstream shares). It is a zero sum game, no hash is lost.

There is a trade-off between hashrate aggregation and monitoring of individual miners on the target pool's dashboard. This is only relevant for cases that use the attribute identity_pass_through = true in the TOML config file (within [target] definition). A higher level of aggregation means that individual miners are sending submits more slowly due to high upstream difficulty (a proxy with a high aggregation factor gets a job with a high difficulty from the target pool). In such cases, individual miners can appear on the pool's dashboard as inactive. This is not a limitation of the Braiins Farm Proxy. The miner is still hashing, it is only the matter of being displayed as (non) active on the pool. No hashrate is lost as mining with Braiins Farm Proxy is a zero sum game meaning that downstream hashrate is equal to the upstream hashrate over the long-run. Pool rewards on Braiins Pool are not affected either. If monitoring individual miners is important for you and you are currently using the Braiins Pool dashboard for this purpose, Braiins offers another solution - see Farm Monitor.

#Minimal Config

[[server]]
name = "S1"
port = 3333

[[target]]
name = "Braiins Pool"
url = "stratum+tcp://stratum.braiins.com:3333"
user_identity = "userName.workerName"

[[routing]]
from = ["S1"]

[[routing.goal]]
name = "Primary Goal"

[[routing.goal.level]]
targets = ["Braiins Pool"]

#Recommended Config

[[server]]
name = "S1"
# Port to listen on
port = 3333
# Bonus related to dev-fee
braiinspool_bos_bonus = "bosBonusUserName"

[[target]]
# Name of this target
name = "Braiins Pool Primary"
# Pool URL
url = "stratum+tcp://stratum.braiins.com:3333"
# Mining identity that FP should perform initial authorization with.
# Format: TAG[.WORKER_NAME]
user_identity = "userName.workerName"

[[target]]
# Name of this target
name = "Braiins Pool Backup"
# Pool URL (different port)
url = "stratum+tcp://stratum.braiins.com:443"
# Mining identity that FP should perform initial authorization with.
# Format: TAG[.WORKER_NAME]
user_identity = "userName.workerName"

[[routing]]
# Routing Domain name
name = "RD"
# List of servers that will be exclusive used within this Routing Domain
from = ["S1"]

[[routing.goal]]
# Name of this goal
name = "Primary Goal"

[[routing.goal.level]]
# Primary target
targets = ["Braiins Pool Primary"]

[[routing.goal.level]]
# Backup target (different port)
targets = ["Braiins Pool Backup"]

#Two Servers, Two Routings 70 - 30, Identity of miners goes through

[[server]]
name = "S1"
port = 3333

[[server]]
name = "S2"
port = 3334

[[target]]
name = "Braiins Pool Primary A"
url = "stratum+tcp://stratum.braiins.com:3333"
user_identity = "userNameA.workerName"
identity_pass_through = true

[[target]]
name = "Braiins Pool Backup A"
url = "stratum+tcp://stratum.braiins.com:443"
user_identity = "userNameA.workerName"
identity_pass_through = true

[[target]]
name = "Braiins Pool Primary B"
url = "stratum+tcp://stratum.braiins.com:3333"
user_identity = "userNameB.workerName"
identity_pass_through = true

[[target]]
name = "Braiins Pool Backup B"
url = "stratum+tcp://stratum.braiins.com:443"
user_identity = "userNameB.workerName"
identity_pass_through = true

[[routing]]
from = ["S1","S2"]

[[routing.goal]]
hr_weight = 70
name = "Goal-1"

[[routing.goal.level]]
targets = ["Braiins Pool Primary A"]

[[routing.goal.level]]
targets = ["Braiins Pool Backup A"]

[[routing.goal]]
hr_weight = 30
name = "Goal-2"

[[routing.goal.level]]
targets = ["Braiins Pool Primary B"]

[[routing.goal.level]]
targets = ["Braiins Pool Backup B"]

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
docker volume rm $(docker volume ls -q)

Be careful, this removes a lot. If you have another docker containers running on the machine you shouldn't perform this.

For the monitoring of the proxy server, Node Exporter comes to be handy. It is a docker container containing hw and process data. Those data can be visualized in Grafana as a new dashboard.

There are a lot of stats, below are listed the most important one:

• CPU stats (Quick a Basic)
• Memory (Meminfo)
• Hardware Misc (Power supply)
• Network traffic (traffic errors)

docker logs farm-proxy --tail 1000

This is for the last 1000 lines.

docker logs farm-proxy --since 3h

This is for the last 3 hours.

docker logs farm-proxy --since "2022-04-15T01:40:00"

This is since a specific timestamp.

docker logs --follow farm-proxy

Real-time log display.

Sniff the packets and insert it into files with rotating (10 files, file per 300 MB):

nohup tcpdump -i any -W 10 -C 300 -w log_test.pcap &

tcpdump -i any -W 10 -C 300 -w log_test.pcap

If there are too many switches in the target endpoints and it creates invalid shares.

By default in proxy, there is set that according to the score (which is evaluating quality of the connection - the higher the worse) that if there is another endpoint with score lower by at least 500 than the connection switches to the endpoint with lower score.

In case of worse quality of the network or internet connection it may produce too many switches.

Add these lines at the beginning of the config.toml (FP configuration) file:

[internals]
[internals.quality_metrics]
score_threshold = 2000

There is another parameter which could be changed to higher to make the reconnections low (default is 2500), you can add these right after the codes above.

[internals.quality_metrics.thresholds]
max_latency_diff = 5000.0

Tested miners were Antminers S9, X17, X19, Whatsminers M2x/M3x and Avalon miners with stock firmware and Braiins OS.

There is a trade-off between hashrate aggregation and monitoring of individual miners on target pool's dashboard.

This is relevant only for the case that there is used attribute identity_pass_through = true in the TOML config file (within [target] definition).

Higher level of aggregation means that individual miners are sending submits slower due to high upstream difficulty (proxy with the high aggregation factor gets a job with a high difficulty from the target pool).

In such cases individual miners can appear on the pool's dashboard as inactive. It is not a limitation of the Braiins Farm Proxy but its logical feature.