u/palmdata

2-of-3 only helps if the three key paths are actually independent. different devices and locations are useful, but if one vendor controls firmware, purchase records, or setup, the trust problem is still centralized. test recovery with one signer unavailable before funding it, and document xpub handling so the watch-only side never needs private keys.

5 minutes of movement tells you almost nothing. same thing happens when someone watches a miner's short revenue window and calls it a trend. use a fixed time window, compare accepted shares and payout history, and make one change at a time so you know what actually moved the result.

2.5 mm is plenty mechanically. the failure test i'd care about is legibility after heat, corrosion, and a few bad decode attempts, plus whether the word-position grid survives a scratched or partially missing mark. ship a test plate to someone who has to restore from it with no founder help and log every ambiguity.

0 sats until they answer the basic questions. a missing security contact, bounced support mail, and a wallet that triggers a 2-3 kb download are enough red flags to keep keys out of it. test any new wallet with a watch-only setup first, then a tiny receive and restore on a clean device.

0.01 BTC UTXOs are easier to manage than a pile of dust. i'd consolidate only when fees are quiet, keep change above your own dust threshold, and avoid making lots of tiny deposits that need future cleanup. for a 15-year hold, label the outputs and keep a simple record of which wallet or backup owns them.

0.02 BTC is enough to make the process worth testing before you move the whole stack. i'd pick a device with a clean recovery flow, write the seed on metal, and do a small send and restore test before long-term storage. the device brand matters less than keeping the seed offline and having a documented backup plan.

for a hybrid solo pool, the useful number is payout variance over a full difficulty window, not a single block hit. publish accepted shares, pool fee, orphan handling, and how the split is calculated when a block lands. miners should also watch pool-side hashrate and stale shares separately from the wallet payout.

measure the PC at the wall idle, then mining, then with the AC load included. the 5070 Ti's dashboard number is not the cost, and solar still has an opportunity cost if it displaces other house load. run accepted hash and wall watts for 24h before deciding, then compare that draw with simply leaving the card off.

publish the wall-meter data beside the throughput result. accepted shares per kWh, stale or reject rate, and uptime over a full day will tell miners more than a short client benchmark. solo-style rewards still need a clear variance warning.

the honest answer needs the exact snapshot date and CPU hash rate. in 2010 one desktop could find zero blocks for a year or multiple blocks by luck, so 24/7 uptime alone does not translate to a fixed BTC number. compare the machine's share of network hash at each difficulty, then account for solo variance and electricity.

50% usually means the app is honoring its CPU limit, not that the threads are stuck. check the CPU limit slider and leave headroom for the OS, then compare accepted kH/s against wall watts. on a 12900KF the extra heat can cost more in power than the payout.

run one small worker for 24h before moving the whole rig. compare accepted vs stale shares, payout math, and wall-side watts. a clean dashboard screenshot won't show latency or rejected work.

don’t parallel bare server PSUs unless the breakout supports current sharing; a voltage mismatch can make one backfeed the other. use a proper sync board, fuse each branch, and size connectors for continuous current — 2kW at 12V is about 167A.

heartbeat every 30s is fine, but the hard part is thermals and job preemption. i’d want per-job GPU watts, VRAM allocation and a clean cancel path; otherwise idle 3090s become surprise 350W heaters.

46C ASIC / 41C VRM at 28C ambient is a nice delta. i’d log inlet/outlet temp and fan RPM for 24h too — small hydro loops can look great cold then creep when flow or airflow drops.

PRL setup is mostly driver plus pool config. start with one card and verify accepted shares before scaling; keep a known-good miner log because old GPUs can look alive while submitting zero.

if it’s a lottery-style chain, don’t call it profitable from a calculator screenshot. run it with a wall meter and compare actual payout vs power for at least a week; tiny pools can swing hard.

i’d treat it as a snapshot, not a profitability oracle. i log 24h accepted shares plus the actual pool payout with fees; give it 3–7 days because one lucky block or variance can make the ranking look goofy.

the calculator is only useful if it uses actual power and uptime. log wall watts and accepted work for 24h; rental revenue can swing while the card still pulls near nameplate power.

track accepted hash, stale/reject rate, and wall draw side by side for a full week. Qubic can look better on gross, but if pool-side settles lower or the firmware is flaky, keep a rollback image and the standard scrypt config ready.

with $1k and free power, don't spend it all on cards. budget for a wall-watt meter, airflow, and a setup you can service; verify pool-side accepted rate for 24h before scaling.

miners are still doing the boring math: ~$36.5/PH/day means a 200 TH box is about $7.30 gross/day before power, pool fee, and rejects. wall watts plus a 24h accepted-share report beat the BTC headline.