За какое время можно намайнить 1 биткоин: расчёт для ASIC, пула и соло

Запрос «за какое время можно намайнить 1 биткоин» звучит так, будто у майнинга есть таймер: включили устройство, подождали определённое число дней и получили ровно 1 BTC. У Bitcoin такой механики нет. Время зависит от хешрейта оборудования, текущей сложности сети, режима работы — пул или соло, доступности устройства, правил выплат и того, как меняются параметры сети. Поэтому корректный ответ — не одна дата, а расчёт ожидаемого результата с обязательной оговоркой о вероятности.

На 1 сентября 2026 года сеть Bitcoin работает в эпохе субсидии 3,125 BTC за блок. Один из актуальных блоков на высоте 964 983 имел сложность около 125,807 трлн и базовую субсидию 3,125 BTC; комиссии добавлялись отдельно. Эти числа дают удобную точку для учебного расчёта. Но они не превращают расчёт в обещание: сложность пересматривается, реальный темп блоков отклоняется от среднего, а следующий халвинг снова уменьшит субсидию.

Самая частая ошибка новичка — сравнивать свою установку не с сетью, а с размером награды. ASIC на 200 TH/s выглядит очень мощно: двести триллионов попыток хеширования в секунду. Но сеть в целом работает на уровне сотен экзахешей в секунду. Один экзахеш — это миллион терахешей. На таком масштабе одиночный аппарат получает чрезвычайно маленькую долю общей вычислительной мощности.

В пуле ситуация выглядит иначе. Вы не ждёте собственного блока, а передаёте пулу shares — доказательства выполненной работы меньшей сложности. Пул распределяет заработок между участниками по своей схеме. Это сглаживает случайность и превращает редкий крупный результат в маленькие регулярные начисления. Однако математика ожидаемой доли сети остаётся той же: пул не делает ваш хешрейт сильнее.

Ниже отдельно разобраны три вопроса: сколько времени в среднем нужно, чтобы доля вашего хешрейта принесла эквивалент 1 BTC через пул; сколько в среднем ждать собственного блока при соло-майнинге; сколько электроэнергии и времени понадобится при разных мощностях. Такой подход полезнее любого ответа «N дней», потому что позволяет пересчитать результат для своего ASIC и новых параметров сети.

Если нужен общий финансовый расчёт майнинга — доход, электричество и окупаемость — используйте отдельный калькулятор майнинга и методику расчёта доходности. Здесь задача уже: понять именно время до 1 BTC и не перепутать статистическое ожидание с гарантированным сроком.

Что на самом деле означает «намайнить 1 биткоин»

1 BTC можно получить как сумму маленьких выплат

В пуле фраза «намайнить 1 BTC» обычно означает накопить суммарно 1 BTC выплатами. Сегодня можно получить несколько тысяч сатоши, завтра — чуть больше или меньше, а через длительный период сумма начислений приблизится к единице. Такой результат не требует, чтобы именно ваш аппарат нашёл блок. Важно, чтобы его работа учитывалась пулом и доля вознаграждения начислялась согласно принятой схеме.

Это отличается от бытовой картинки «ASIC нашёл один биткоин». Bitcoin не создаёт блоки по одному BTC. Блок в текущей эпохе содержит базовую субсидию 3,125 BTC плюс комиссии транзакций. Если соло-майнер находит допустимый блок, он получает весь доступный ему coinbase-доход блока, а не ровно 1 BTC.

В соло результат дискретный

Соло-майнинг похож не на зарплату за каждый час, а на редкое событие с известной вероятностью. Устройство непрерывно перебирает значения, но большая часть работы не создаёт денежного результата. До момента удачной находки баланс может оставаться нулевым. Затем один блок способен принести сразу несколько BTC.

Если математическое ожидание нахождения блока равно, условно, 80 годам, это не означает, что блок обязательно появится на восьмидесятом году. Он может быть найден завтра, а может не появиться за всю жизнь оборудования. Вероятностная модель описывает распределение событий, а не расписание.

Ожидаемый доход и гарантированный срок — разные вещи

Для пула удобно говорить об ожидаемом количестве BTC в сутки. Если ваша доля сетевого хешрейта равна q, то при идеализированном среднем 144 блока в сутки и субсидии 3,125 BTC базовая ожидаемая доля субсидии до комиссий пула составляет q × 144 × 3,125 BTC. Реальная выплата зависит от фактического числа блоков, схемы PPS/FPPS/PPLNS, stale shares и комиссии.

Для соло тот же ожидаемый доход существует в статистическом смысле, но выплачивается крайне неравномерно. Поэтому сравнивать «пул даёт по чуть-чуть, а соло даёт больше» некорректно: при одинаковом хешрейте меняется главным образом распределение риска.

Почему ответ должен включать дату расчёта

Сложность Bitcoin не является константой. Сеть корректирует её, чтобы средний интервал между блоками оставался около десяти минут. Когда суммарный хешрейт растёт, сложность со временем подстраивается вверх; когда падает — может снизиться. Поэтому расчёт, сделанный при сложности 125,8 трлн, нельзя бездумно переносить на будущие годы.

Кроме того, субсидия уменьшается после халвингов. Даже если аппарат, тариф и uptime не меняются, ожидаемое количество новых BTC на единицу хешрейта в долгом горизонте меняется. Поэтому статья использует снимок сети на 1 сентября 2026 года и затем показывает, как пересчитать всё заново.

Сатоши удобнее целого BTC

Для бытового контроля майнинга лучше мыслить сатоши. Один BTC равен 100 000 000 сатоши. Если установка ожидаемо приносит около 10 000 сатоши в сутки до конкретных комиссий и отклонений, путь к 1 BTC — это накопление ста миллионов сатоши. Масштаб сразу становится понятнее.

Сатоши удобны и для сверки выплат: пул может перечислять небольшие суммы по порогу. Важно отличать начисленный баланс в личном кабинете пула от подтверждённой on-chain выплаты. Фактическую выплату можно проверить через TxID транзакции.

Формула: как посчитать ожидаемое время до 1 BTC

Шаг 1. Переведите хешрейт в одни единицы

Хешрейт оборудования обычно указывают в TH/s или PH/s. 1 TH/s — один триллион хешей в секунду. 1 PH/s — тысяча TH/s. Сетевой хешрейт удобнее выражать в EH/s: 1 EH/s равен миллиону TH/s. Ошибка в приставке даёт разницу в тысячу или миллион раз, поэтому расчёт начинается с приведения единиц.

Например, 200 TH/s — это 0,0002 EH/s. На фоне сети около сотен EH/s такая установка занимает долю порядка нескольких десятимиллионных. Запись в процентах неудобна, поэтому в формулах лучше использовать дробь: хешрейт майнера делится на оценку хешрейта сети.

Шаг 2. Получите долю сетевой мощности

Если обозначить ваш хешрейт как Hm, а оценку хешрейта сети как Hn, доля q = Hm / Hn. В идеализированной модели именно эта доля определяет, какая часть блоков в очень длинном периоде статистически соответствует вашей работе. Для пула она переводится в ожидаемую долю выплат; для соло — в вероятность оказаться автором конкретного следующего блока.

Само понятие хешрейта подробно разобрано в материале о хешрейте Bitcoin. Для текущей задачи достаточно помнить: локальный хешрейт показывает скорость установки, сетевой — оценку совокупной работы сети.

Шаг 3. Оцените базовый выпуск BTC за сутки

При целевом среднем интервале около десяти минут за сутки получается примерно 144 блока. В эпохе субсидии 3,125 BTC это даёт ориентир 450 новых BTC субсидии в сутки: 144 × 3,125. Это не фиксированная календарная эмиссия: за конкретные 24 часа блоков может оказаться больше или меньше, а комиссии не являются новой эмиссией.

Тогда ожидаемая доля субсидии майнера за сутки в простейшей модели: q × 450 BTC. Чтобы получить ориентир времени до накопления 1 BTC, единицу делят на ожидаемый BTC/day. Получившееся количество дней относится к условию, что сетевые параметры, мощность и субсидия всё это время не меняются.

Шаг 4. Для соло считайте время до блока отдельно

Ожидаемое число хешей, необходимое для нахождения блока при заданной сложности D, можно приблизительно выразить как D × 2^32. Если устройство делает Hm хешей в секунду, ожидаемое время до блока равно D × 2^32 / Hm секунд. Формула полезна тем, что не требует отдельного сайта с сетевым хешрейтом: достаточно difficulty и локальной производительности.

После получения секунд переводите их в дни или годы, но не называйте результат дедлайном. Это среднее случайного процесса. Вероятность получить хотя бы один блок за период t можно приблизительно выразить как 1 − exp(−t/T), где T — ожидаемое время до блока.

Шаг 5. Не смешивайте субсидию и комиссии

Базовая награда блока состоит из субсидии и комиссий включённых транзакций. Субсидия создаёт новые BTC, комиссии перераспределяют уже существующие. Для оценки чистой экономики пула комиссии важны, но они непредсказуемы и не должны закладываться как постоянный фиксированный бонус на годы.

Некоторые схемы пула пытаются учитывать среднюю долю transaction fees в выплатах, другие делают это иначе. Поэтому базовый расчёт времени до 1 BTC лучше начинать только с субсидии, а комиссии добавлять отдельным сценарием. Так модель остаётся воспроизводимой.

Почему калькулятор может показать другое число

Онлайн-калькуляторы могут брать другой сетевой хешрейт, difficulty, среднее число блоков, комиссию пула, фактическую эффективность оборудования или прогноз роста сложности. Даже два корректных сервиса способны показать разные результаты, если их исходные допущения различаются.

Проверяйте не только итоговое «дней до 1 BTC», но и исходные поля: difficulty, network hashrate, subsidy, local hashrate, uptime, pool fee и fee-компонент. Если сервис не показывает допущения, его итог труднее проверить.

Снимок Bitcoin на 1 сентября 2026 года и что из него следует

Высота блока и субсидия

На момент контрольной проверки 1 сентября 2026 года обозреватель mempool.space показывал блоки около высоты 964 983. В coinbase одного из этих блоков базовая субсидия составляла 3,125 BTC, а общая сумма вместе с комиссиями была немного выше. Для нашей модели важно именно 3,125 BTC: это предсказуемая часть награды текущей эпохи.

Механика уменьшения субсидии подробно разобрана в статье о халвинге Bitcoin. Следующая эпоха снова уменьшит базовую награду вдвое, поэтому длинный расчёт на сегодняшней субсидии нельзя считать календарным прогнозом.

Текущая сложность: около 125,8 трлн

У актуальных блоков difficulty была около 125 807 076 547 197,5. Это примерно 125,8 трлн относительно минимальной сложности. Число не означает «столько хешей нужно сделать один раз»; это коэффициент, из которого выводится целевой уровень proof-of-work и статистическое количество попыток.

Если нужно понять, почему difficulty меняется и чем отличается от хешрейта, используйте отдельный разбор сложности сети Bitcoin. Для времени до блока ключевой смысл простой: при неизменном вашем хешрейте более высокая сложность увеличивает ожидаемый срок.

Как из difficulty получить эквивалентный сетевой хешрейт

При целевом среднем интервале 600 секунд можно получить приближённый эквивалент сетевого хешрейта: D × 2^32 / 600. Для difficulty около 125,807 трлн получается примерно 900,6 EH/s. Это не мгновенный live hash rate, а долгосрочный эквивалент, согласованный с текущей сложностью и десятиминутной целью.

Именно эту величину удобно использовать для иллюстративной таблицы. Если difficulty изменится, расчёт обновляется. Если вместо неё берётся сетевой хешрейт с графика, лучше использовать усреднённое значение и фиксировать окно.

Что означает сеть порядка 900 EH/s для одного ASIC

900 EH/s — это примерно 900 миллионов TH/s. Аппарат на 200 TH/s составляет около 0,000000222 такой сети, или примерно 0,0000222%. Локальные 200 TH/s звучат огромным числом, но на фоне всей сети это очень маленькая доля.

При идеализированных 450 BTC новой субсидии в сутки доля 200 TH/s даёт математическое ожидание около 0,0001 BTC в сутки — примерно 10 тысяч сатоши. Чтобы сумма достигла 1 BTC при полностью замороженных условиях, понадобилось бы порядка 10 тысяч дней, около 27 лет.

Почему это не прогноз до 2053 года

За 27 лет пройдут несколько халвингов, поменяются поколения ASIC, стоимость энергии, сетевой хешрейт и структура майнинга. Даже оборудование не рассчитано на бесконечную эксплуатацию без ремонта. Поэтому 27 лет отвечает только на вопрос о текущем математическом отношении мощности к выпуску BTC.

Практический смысл числа — показать масштаб. Если цель — накопить целый BTC только майнингом, нужно оценивать будущий объём оборудования, реинвестирование, стоимость энергии и изменение дохода на TH/s. Это полезнее ложной точности до конкретной даты.

Расчёты для 100, 200, 250, 300 и 500 TH/s

Таблица базового ожидания при замороженных условиях

Ниже — учебный расчёт на базе difficulty около 125,807 трлн, эквивалентного сетевого хешрейта около 900,6 EH/s и субсидии 3,125 BTC. Комиссии пула, transaction fees, простои и будущие изменения не учитываются. Таблица показывает физический масштаб, а не обещанную доходность.

Разница между сроком накопления 1 BTC в пуле и сроком до собственного блока объясняется размером блока. В пуле вы накапливаете долю субсидий многих блоков. В соло одна успешная находка текущей эпохи приносит сразу 3,125 BTC плюс комиссии, поэтому ожидаемый срок до первого события примерно в 3,125 раза длиннее.

Пример: один ASIC на 200 TH/s

Доля 200 TH/s от эквивалентных 900,6 EH/s составляет около 2,22 × 10⁻⁷. Умножаем на 450 BTC суточной субсидии и получаем около 0,0000999 BTC в сутки — приблизительно 9 994 сатоши. В идеализированной модели 100 000 000 сатоши / 9 994 ≈ 10 006 суток.

Если через несколько лет сетевой хешрейт вырастет, доля устройства уменьшится. После следующего халвинга ежедневная субсидия сети уменьшится. Если аппарат теряет uptime или появляются rejected shares, фактическая доля выплат ниже. Поэтому 27,4 года — текущая нормировка, а не реальный срок эксплуатации.

Пример: 500 TH/s

500 TH/s дают примерно 0,0002498 BTC субсидии в сутки, около 24 984 сатоши. Формально 1 BTC набирается за примерно 4 002 дня, около 11 лет, если весь мир замер. Это показывает линейность: увеличили хешрейт в 2,5 раза относительно 200 TH/s — время уменьшилось примерно в 2,5 раза.

Линейность полезна для сценариев, но расходы растут не обязательно строго линейно. Разные модели ASIC имеют разную энергоэффективность, а большая установка добавляет вентиляцию, трансформацию и обслуживание.

Пример: ферма 1 PH/s

1 PH/s — тысяча TH/s. При текущем снимке сети базовый ориентир — около 0,0004997 BTC в сутки, примерно 49 969 сатоши. До суммарного 1 BTC получается около 2 001 дня, то есть 5,5 года.

При соло 1 PH/s ожидаемое время до блока по difficulty составляет около 6 254 дней, порядка 17 лет. Вероятность хотя бы одного блока за год при постоянных параметрах — примерно 5,7%, поэтому год без блока остаётся обычным исходом.

Вероятность соло-блока за год

Таблица показывает, почему соло нельзя оценивать по среднему сроку без вероятности. Даже при 10 PH/s шанс найти хотя бы один блок за год в этой замороженной модели остаётся меньше половины. Зато удачный блок приносит крупный результат. Соло — выбор профиля дисперсии, а не способ обмануть математику.

Что происходит, если увеличить мощность в десять раз

При неизменных параметрах время обратно пропорционально хешрейту. 200 TH/s дают около 27,4 года по ожидаемой пуловой субсидии до 1 BTC; 2 PH/s дали бы около 2,74 года; 20 PH/s — около 100 дней. Но такой масштаб быстро переводит вопрос из категории времени в категорию капитальных и операционных расходов.

Наращивание хешрейта означает оборудование, питание, коммутацию, охлаждение, помещение, обслуживание и риск простоя. После арифметики BTC/day всегда нужен второй расчёт — стоимость полученного BTC.

Пул или соло: где быстрее получить результат

Пул не ускоряет вашу долю работы, но уменьшает дисперсию

Если два майнера имеют одинаковые 200 TH/s, один работает соло, другой в достаточно крупном пуле, их ожидаемая доля общего proof-of-work близка. Пул не создаёт дополнительные хеши. Его преимущество — агрегация: тысячи участников вместе находят блоки чаще, а затем делят доход согласно учтённой работе.

Как устроены shares, почему бывают stale/rejected и чем различаются PPS, FPPS и PPLNS, разобрано в статье о майнинг-пулах. Для текущего вопроса главное: регулярность выплаты зависит от схемы, а ожидаемая физическая доля сети — от эффективного хешрейта.

Почему «пул выплатил быстрее» не означает, что BTC создались быстрее

Пул может начислить сатоши уже через короткое время после подключения, потому что распределяет доход от блоков, найденных всей совокупностью участников. Ваш отдельный ASIC при этом мог не найти ни одного полного сетевого блока. С точки зрения пользователя результат появился быстрее, но в действительности пул коллективно сгладил случайность.

Поэтому вопрос «за сколько пул намайнит 1 BTC для меня» можно считать через среднюю долю выплат, а вопрос «когда мой ASIC найдёт блок» — через вероятность. Это два разных календаря для одной и той же вычислительной работы.

PPS и FPPS: покупка предсказуемости

В схемах типа PPS оператор платит за принятые shares по модели ожидаемой стоимости, а риск того, сколько блоков реально найдёт пул за короткий период, частично берёт на себя. FPPS обычно добавляет модельное распределение части transaction fees. В обмен оператор закладывает комиссию и собственную систему расчёта.

Для владельца оборудования такие схемы удобны, если цель — прогнозируемый денежный поток. Но считать время до 1 BTC только по красивому значению в интерфейсе нельзя: нужно понимать, учитывает ли показатель комиссию пула, какой период используется для fee-компонента и когда меняется payout rate.

PPLNS: связь выплаты с фактически найденными блоками

PPLNS сильнее связывает выплаты с удачей пула и вашими shares в заданном окне. На коротком отрезке начисления могут заметно колебаться. На длинном горизонте при корректной работе схема стремится отражать реальную долю участия, но путь до 1 BTC будет менее ровным, чем в PPS-подобной модели.

Нельзя автоматически утверждать, что одна схема прибыльнее. Комиссии, luck, размер пула, правила окна, payout threshold и техническое качество соединения способны перевесить название метода. Для статьи о времени важнее понимать источник колебаний.

Когда соло имеет смысл как осознанный выбор

Соло может быть принципиальным выбором для майнера, который не хочет делиться coinbase с оператором пула, готов принимать огромную дисперсию и способен самостоятельно построить корректную инфраструктуру. Это не режим максимальной доходности для маленького хешрейта. Малый майнер должен понимать, что годами может не видеть ни одной выплаты.

С технической стороны соло требует надёжного узла, корректного формирования шаблонов блока, сетевой связности и безопасного хранения ключей. Человек, который просто перенёс строку подключения с пула на соло-сервер, не отменяет эксплуатационные риски.

Главная практическая граница

Если нужен предсказуемый поток сатоши, думайте в терминах пула и ожидаемой доли. Если сознательно выбираете редкий шанс на полный блок, оценивайте соло через вероятность, а не через среднее число лет.

Эта граница избавляет от рекламного заблуждения. «Соло может найти блок завтра» — правда, но без вероятности бессмысленна. «В пуле 1 BTC получится примерно через N дней» — тоже неполно, если N рассчитано при вечной сегодняшней сложности и субсидии. Хорошая модель всегда показывает условия.

Можно ли намайнить 1 биткоин на видеокарте

Технически SHA-256 доступен, практически конкуренция давно ASIC

GPU умеет выполнять SHA-256, но современный Bitcoin mining оптимизирован специализированными ASIC. Их производительность и энергоэффективность на этом алгоритме несопоставимы с обычной видеокартой. Поэтому поисковые вопросы «за какое время можно намайнить 1 биткоин на 1 видеокарте» нельзя отвечать простой пропорцией от цены GPU.

Если видеокарта выдаёт ничтожную долю терахеша относительно ASIC, ожидаемый срок до сетевого результата становится астрономическим, а электричество расходуется всё это время. Это не означает, что GPU бесполезны вообще: они могут использоваться в других задачах и алгоритмах, но прямой SHA-256 майнинг Bitcoin — другой рынок оборудования.

Почему сравнение по ваттам особенно невыгодно GPU

В майнинге важна не только скорость, но и эффективность — сколько джоулей требуется на один терахеш. ASIC проектируется для узкого набора операций и избавлен от универсальной архитектуры, необходимой видеокарте для графики и разных вычислений. Поэтому два устройства с одинаковым энергопотреблением могут отличаться по Bitcoin hashrate на порядки.

Новичок иногда сравнивает видеокарту на несколько сотен ватт и ASIC на несколько киловатт и делает вывод, что GPU экономичнее. Нужно сравнивать не абсолютную мощность, а хеши на единицу энергии. ASIC потребляет больше в абсолюте, потому что одновременно выполняет несопоставимо больше SHA-256 работы.

Почему старые статьи про GPU-майнинг Bitcoin вводят в заблуждение

Исторически Bitcoin действительно майнили на CPU и GPU. Затем появились FPGA и ASIC. Чтение старых инструкций без даты создаёт ложное ощущение, что способ всё ещё конкурентоспособен. Протокол не запретил GPU, но экономическая среда изменилась: сеть и difficulty выросли, специализированное оборудование стало стандартом.

Поэтому полезно отличать «можно отправлять хеши» от «имеет практический смысл». Техническая возможность не является экономической рекомендацией. Аналогично старый ASIC может продолжать вычислять корректные hashes, но более новое поколение способно сделать его нерентабельным при конкретном тарифе.

Если у вас уже есть видеокарта

Не пытайтесь переводить её цену или игровые характеристики в срок до 1 BTC. Сначала найдите реальный SHA-256 hashrate именно этой конфигурации, измеренный в сопоставимых условиях. Затем подставьте его в формулу. Обычно уже первый порядок величины показывает, насколько результат далёк от ASIC.

Если цель пользователя — именно получить BTC, а не изучить майнинг как технологию, следует отдельно сравнить стоимость электричества, износ и альтернативную стоимость оборудования. Статья не предлагает способ покупки BTC; её задача — показать, когда прямой майнинг перестаёт быть рациональным способом достижения количественной цели.

Что значит «шесть видеокарт»

Умножение количества GPU на шесть не меняет классовую проблему. Если одна карта даёт очень маленький SHA-256 hashrate, шесть карт дают в шесть раз больше очень маленького числа. Линейность формулы сохраняется, но порядки величин остаются далеко от современного ASIC.

Именно поэтому хвост «за какое время можно намайнить 1 биткоин на 6 видеокартах» полезно раскрывать через принцип, а не рисовать универсальное число. Модели GPU, разгон, программное обеспечение и потребление различаются; без фактического SHA-256 hashrate точный срок просто выдуман.

Электричество, uptime и реальные потери: время до 1 BTC не равно окупаемости

Энергопотребление считается отдельно от хешрейта

Допустим, установка потребляет 3,5 кВт из розетки. За сутки непрерывной работы это 3,5 × 24 = 84 кВт·ч. За 30 дней — около 2 520 кВт·ч. Умножив на свой полный тариф, вы получите стоимость активного энергопотребления оборудования. В реальном объекте дополнительно могут быть вентиляция, кондиционирование, сетевое оборудование и инфраструктурные потери.

Если тариф 5 рублей за кВт·ч используется исключительно как учебный пример, 84 кВт·ч стоят 420 рублей в сутки. При 8 рублях — 672 рубля. Эти числа ничего не говорят о прибыльности без ожидаемого BTC/day и текущей цены BTC. Правильная последовательность: сначала измерить мощность, затем посчитать энергию, затем сопоставить с ожидаемым доходом.

Эффективность J/TH связывает электричество и вычислительную мощность

Показатель J/TH показывает, сколько джоулей энергии требуется устройству для выполнения терахеша вычислений. Чем он ниже, тем меньше электричества нужно на одинаковый hashrate. При равной цене энергии более эффективный ASIC выдерживает более высокую сетевую сложность и падение дохода дольше.

Если производитель заявляет эффективность, полезно проверить фактическое потребление из розетки и стабильный hashrate. Температура, режим питания и прошивка могут менять результат. Для модели времени нужен effective hashrate, а для экономики — фактические киловатты.

Uptime: 95% и 100% — не мелкая разница

Теоретические таблицы предполагают 24/7. На практике бывают перезагрузки, перегрев, профилактика, отключения электричества, сетевые проблемы и простой пула. Если uptime составляет 95%, эффективное рабочее время уменьшается на 5%, а календарный срок до того же количества BTC увеличивается примерно на 1/0,95 — около 5,26%.

Для короткого теста это кажется мелочью. Для долгой эксплуатации потери накапливаются. Журнал работы должен хранить не только заявленный hashrate, но и средний accepted hashrate за сутки или неделю, время простоя и причины.

Stale и rejected shares

Пул может отклонять часть shares из-за задержки, неправильной работы или потому, что share относится к уже устаревшему заданию. Низкая доля stale нормальна для сетевой системы, но её рост ухудшает реальную эффективность. Нельзя считать, что 200 TH/s на экране ASIC автоматически равны 200 TH/s оплачиваемой работы.

Сравнивайте локальный hashrate устройства с accepted hashrate на стороне пула. Если расхождение устойчиво, исследуйте задержку, сеть, перегрев, ошибки чипов и настройки. Устранение технических потерь иногда даёт больше результата, чем агрессивный разгон.

Комиссия пула

Если пул удерживает процент, время до чистого 1 BTC увеличивается. При условной комиссии 2% и неизменном валовом начислении нужно накопить больше валового дохода, чтобы после удержания получить целый BTC. Точный эффект зависит от того, что входит в fee и как схема учитывает transaction fees.

Не фиксируйте рекламный процент навсегда. Условия сервиса меняются. Перед расчётом откройте текущие правила своего пула и запишите дату. В модели полезно иметь отдельное поле fee, которое можно менять без переписывания всей таблицы.

Порог выплаты и баланс пула

Даже если экономически уже заработано определённое количество сатоши, они могут оставаться внутренним балансом до достижения payout threshold. Это влияет не на физическое время добычи, а на момент, когда BTC окажется под вашим контролем в кошельке. Для управления риском эти даты нужно разделять.

Сохраняйте историю начислений и фактических выплат. Если происхождение добытых монет важно для учёта или документов, полезно отдельно вести доказательства: адрес, TxID, отчёт пула и период работы. Эта тема раскрыта в материале о том, как подтвердить происхождение криптовалюты после майнинга.

Что изменит расчёт через месяц, год и после халвинга

Рост сетевого хешрейта

Если суммарный хешрейт сети растёт, но difficulty ещё не успела перестроиться, блоки временно могут находиться быстрее. После корректировки сложность поднимается, и доля фиксированного ASIC в ожидаемом выпуске снижается. Для долгой модели нельзя брать один network hashrate и растягивать его на годы.

Практический способ — строить несколько сценариев. Базовый: difficulty остаётся около текущей до ближайшей корректировки. Консервативный: сложность растёт на выбранный процент в каждый период. Стрессовый: одновременно растёт difficulty и снижается uptime. Это не прогноз будущего, а проверка устойчивости проекта.

Падение сетевого хешрейта

Обратный процесс тоже возможен. Если часть майнеров отключается из-за экономики или внешних условий, после корректировки сложность может снизиться. Оставшийся ASIC тогда получает большую относительную долю работы. Однако снижение difficulty не гарантирует рост прибыли: причина ухода других майнеров могла быть связана с падением цены BTC или ростом затрат.

Поэтому difficulty нельзя анализировать изолированно. В модели времени она влияет на BTC per TH, а цена и энергия — на денежный результат. Эти слои полезно хранить раздельно, чтобы не перепутать техническую производительность с финансовой доходностью.

Следующий халвинг

После следующего халвинга базовая субсидия блока станет вдвое меньше. Если предположить неизменные difficulty и hashrate — что само по себе нереалистично — базовый выпуск новых BTC на сутки тоже сократится вдвое, и ожидаемое время накопления 1 BTC только из субсидии удвоится.

Это особенно важно для расчётов, которые сегодня дают сроки больше нескольких лет. Нельзя сказать «200 TH/s = 27 лет до BTC» и забыть, что за этот период пройдут изменения subsidy. Текущая таблица нужна для масштаба и сравнения оборудования, а не для прямого календарного прогноза.

Transaction fees могут частично компенсировать снижение субсидии

Майнер получает не только subsidy, но и fees. В периоды высокой активности комиссии способны заметно увеличить доход блока. Но будущие fees неизвестны: они зависят от спроса на blockspace, поведения пользователей и состояния mempool. В модель можно добавить среднее значение по выбранному историческому окну, но его необходимо показать отдельно.

Для консервативной оценки времени до 1 BTC мы не используем комиссии как гарантированный бонус. Это делает результат осторожнее и понятнее. Если пул платит fee-компонент, его можно добавить в собственный сценарий на основе прозрачной методики.

Старение оборудования

Хешрейт ASIC не обязательно падает каждый год сам по себе, но экономическая конкурентоспособность может снижаться из-за более эффективных моделей. Старое устройство продолжает делать ту же работу, однако новые участники добавляют больше TH/s на ватт, повышая общий сетевой хешрейт. В результате доля старого аппарата становится меньше.

Также растёт вероятность ремонтов вентиляторов, блоков питания и плат. Поэтому очень длинные модели должны включать резерв на обслуживание и замену. Математический срок, превышающий разумный жизненный цикл установки, сам по себе сигнализирует: цель «1 BTC одним аппаратом» плохо описывает практическую задачу.

Изменение тарифа электричества

Цена энергии не меняет количество хешей, которое ASIC способен сделать в секунду, но определяет, сможете ли вы держать его включённым. Если тариф делает работу убыточной, рациональный оператор может снизить uptime или выключить оборудование. Тогда календарное время до 1 BTC увеличивается или задача прекращается.

Энергетический риск влияет на время косвенно — через доступность оборудования. В стресс-тесте полезно проверить тариф +20%, +50% и периоды простоя. Если проект ломается при небольшом изменении, текущая маржа слишком тонкая.

Периодический пересчёт вместо одного вечного калькулятора

Разумный цикл — обновлять модель после изменения difficulty, после существенного изменения хешрейта установки, тарифа, fee пула или subsidy. Тогда вы всегда знаете актуальный ожидаемый BTC/day и не опираетесь на старую картинку.

Для операционного контроля достаточно таблицы с датой, difficulty, local accepted hashrate, uptime, pool fee и фактическими BTC received. Сравнение прогноза с фактом помогает увидеть отклонения и понять, где они возникли: сеть, оборудование или пул.

Как самостоятельно посчитать свою установку и принять решение

Минимальный набор данных

Для честного расчёта нужны фактический accepted hashrate, текущая difficulty или усреднённый network hashrate, subsidy текущей эпохи, uptime, комиссия и схема пула, потребление из розетки и полный тариф электричества. Для соло дополнительно важна вероятность блока за выбранный горизонт, а не только средний срок.

• Зафиксируйте дату и высоту блока, к которой относятся сетевые параметры.
• Возьмите accepted hashrate за достаточно длинное окно, а не пик на экране.
• Отдельно запишите uptime и причины простоя.
• Проверьте текущую схему выплат и комиссию пула.
• Измерьте фактическую мощность установки из розетки.
• Посчитайте BTC/day, а затем стоимость энергии на тот же день.
• Создайте базовый и стрессовый сценарии, а не одну цифру.

Пошаговый пример для 250 TH/s

Берём 250 TH/s и учебный эквивалент сети 900,6 EH/s. Переводим сеть в TH/s: примерно 900,6 млн TH/s. Доля установки ≈ 250 / 900 600 000 = 2,776 × 10⁻⁷. Умножаем на 450 BTC суточной субсидии и получаем около 0,0001249 BTC, или примерно 12 492 сатоши в сутки до поправок.

Делим 1 BTC на 0,0001249 и получаем примерно 8 005 суток, около 21,9 года при замороженных условиях. Затем применяем uptime: если он 97%, ожидаемый валовой результат уменьшается. Если пул удерживает комиссию, чистое значение становится ещё ниже. Финальный срок уже отличается от красивого исходного числа.

Следующий шаг — электричество. Если фактическая мощность оборудования условно 4 кВт, суточное потребление составляет 96 кВт·ч. Умножьте на свой тариф. Затем сравните денежную стоимость энергии с денежной стоимостью ожидаемых сатоши по текущей цене BTC. Именно здесь становится видно, есть ли экономический смысл продолжать работу.

Сценарий A: домашний майнер с одним ASIC

Для одного аппарата главная ценность расчёта — разрушить иллюзию быстрого целого BTC. Даже мощный современный ASIC остаётся маленькой частью сети. Поэтому полезная цель — не «дождаться одного биткоина любой ценой», а контролировать чистый satoshi yield на кВт·ч и риск оборудования.

Домашнему майнеру особенно важны шум, тепло, электропроводка и допустимая длительная нагрузка. Эти ограничения могут сделать круглосуточный uptime невозможным ещё до экономических факторов. Если аппарат вынужден работать только часть суток, используйте фактические часы, а не паспортные 24/7.

Сценарий B: небольшая ферма

Для нескольких устройств важнее суммарный accepted hashrate и инфраструктурные потери. Номинальные 5 × 200 TH/s дают 1 PH/s, но реальный показатель может быть ниже из-за разных режимов и простоев. В модели нужно складывать не паспортные значения, а фактические средние каждого устройства.

У фермы появляются дополнительные расходы: распределение питания, охлаждение, мониторинг, запасные части, сеть и время персонала. Они не меняют формулу proof-of-work, но меняют стоимость достижения 1 BTC. Поэтому операционная таблица должна иметь как минимум два результата: BTC accumulated и total cost.

Сценарий C: соло ради редкого блока

Если сознательно выбирается соло, начинайте с вероятности. При 200 TH/s и текущей difficulty вероятность хотя бы одного блока за год порядка 1,16% в нашей замороженной модели. Нулевой результат за год — не неудачная аномалия, а подавляюще вероятный исход.

Если такой профиль риска приемлем и есть техническая мотивация, соло может быть осознанным экспериментом. Если же нужен регулярный денежный поток для оплаты электричества, статистически редкий блок — опасная база финансового плана.

Сценарий D: более мощный или более эффективный ASIC

Пусть устройство A даёт больше TH/s, но потребляет заметно больше энергии, а устройство B немного медленнее, зато эффективнее. По времени до 1 BTC A выигрывает: выше hashrate — выше доля сети. По себестоимости 1 BTC победитель может оказаться другим. Это два разных критерия.

Поэтому при выборе оборудования нельзя смотреть только на TH/s. Сначала сравните J/TH, затем цену, ожидаемый срок эксплуатации и тариф. Быстро добывать дороже не обязательно лучше, чем чуть медленнее с устойчивой маржой.

Сценарий E: калькулятор обещает намного быстрее

Если внешний сервис показывает для 200 TH/s не десятилетия, а несколько месяцев до 1 BTC при текущей сети, проверьте единицы и исходные данные. Возможно, калькулятор считает 1 PH/s вместо 200 TH/s, использует доходность в другой монете, показывает выручку в деньгах, а не 1 BTC, или применяет устаревшую difficulty.

Сделайте обратную проверку. Возьмите показанный BTC/day и сравните с долей сетевого хешрейта. Если цифра требует, чтобы ваш аппарат контролировал заметно большую долю сети, ошибка найдена. Именно воспроизводимость расчёта защищает от неправдоподобных обещаний.

Как понять, что модель достаточно качественная

Хорошая модель отвечает на вопросы: какие исходные данные, на какую дату, что считается доходом, учтён ли uptime, где fees, какой режим пула. Она не скрывает uncertainty и позволяет заменить любой параметр. Плохая модель выдаёт одно число «1 BTC за девять месяцев» без доказуемой математики.

В случае Bitcoin сетевую механику можно проверить независимо. Bitcoin Core предоставляет difficulty и оценку network hash rate через RPC, а блоки позволяют проверить coinbase subsidy и fees. Это сильная сторона открытой сети: фундаментальные параметры не нужно принимать на веру у продавца оборудования.

Почему среднее время соло-блока не совпадает с «типичным» ожиданием

У случайного процесса нахождения блока есть ещё одна особенность: среднее время T и медианное время различаются. Если вероятность описывается экспоненциальной моделью, шанс найти хотя бы один блок к моменту t равен 1 − exp(−t/T). Чтобы получить 50-процентную вероятность, достаточно примерно 0,693T. Для 90% нужно около 2,303T, для 95% — около 2,996T. Поэтому фраза «среднее 85 лет» не значит, что половина майнеров ждала бы 85 лет.

Для условных 200 TH/s при текущей difficulty среднее время до блока около 85,7 года. Медиана — примерно 59,4 года: к этому моменту в гипотетической огромной группе одинаковых независимых майнеров примерно половина нашла бы хотя бы один блок, а половина — нет. Чтобы вероятность достигла 90%, горизонт вырос бы примерно до 197 лет при полностью замороженных условиях. Такая математика хорошо показывает, почему малый соло-хешрейт нельзя использовать как источник регулярного дохода.

На практике условия не останутся одинаковыми даже несколько лет, тем более десятилетия. Поэтому эти числа — демонстрация дисперсии, а не прогноз. Они полезны, чтобы правильно читать слова «ожидаемое время»: среднее — параметр распределения, а не дата в календаре.

Как uptime меняет срок: простой стресс-тест

Допустим, базовая модель для конкретного оборудования даёт 10 000 суток до суммарного 1 BTC. При uptime 100% это и есть исходный календарный ориентир. При 98% эффективной работе тот же объём вычислений потребует около 10 204 календарных суток. При 95% — около 10 526, при 90% — около 11 111. Даже небольшая потеря доступности заметно растягивает очень длинный горизонт.

Этот расчёт предполагает, что во время работы hashrate остаётся прежним. Если простои совпадают с перегревом, троттлингом и rejected shares, фактическая потеря может быть больше. Поэтому uptime лучше измерять не только по статусу «online», а по accepted hashrate за период.

Почему 24 часа недостаточно для оценки реального хешрейта

Локальный ASIC может показывать стабильные 200 TH/s, а пул за последние несколько минут — 180 или 230 TH/s. Это нормально: оценка по shares шумит. Чем короче окно, тем сильнее случайные отклонения. Если подставить минутный показатель в долгосрочную формулу, результат будет прыгать без реального изменения оборудования.

Для диагностики полезны разные окна. Несколько минут показывают, живо ли устройство. Суточное среднее помогает увидеть простои и крупные сбои. Недельное окно лучше отражает устойчивый accepted hashrate, если режим эксплуатации не менялся. Для финансовой модели имеет смысл брать именно устойчивый период и отдельно фиксировать, были ли профилактика, авария или изменение настроек.

Если за неделю локальная панель стабильно показывает 200 TH/s, а пул — 188 TH/s, не списывайте разницу на случайность автоматически. Проверьте rejected/stale, сеть, частоту ошибок и режим питания. Один-два процента потерь на длинном горизонте превращаются в месяцы дополнительного ожидания.

Разгон и андервольтинг: больше TH/s не всегда значит лучше

Прошивки и режимы питания позволяют менять производительность некоторых ASIC. Разгон повышает hashrate и теоретически сокращает время до 1 BTC. Но одновременно растут потребление, температура и нагрузка на компоненты. Если увеличение мощности вызывает больше ошибок или простоев, часть выигрыша исчезает.

Андервольтинг или экономичный режим может дать противоположный эффект: hashrate ниже, календарное время до целевого количества BTC длиннее, зато J/TH лучше и стоимость энергии на единицу вычислительной работы может снизиться. Для майнера, ограниченного тарифом или электросетью, это иногда важнее максимальной скорости.

Сравнивайте режимы по трём показателям одновременно: accepted TH/s, ваттам из розетки и проценту ошибок. Режим, который выглядит самым быстрым в локальной панели, не обязательно даёт лучший net result за месяц.

Температура — это не только вопрос срока службы

Высокая температура влияет на стабильность вычислений. Устройство может снижать частоты, перезапускаться или увеличивать число hardware errors. В результате паспортный hashrейт перестаёт совпадать с реальным accepted hashrate. Если формула времени использует паспортное число, а оборудование летом работает на 7% медленнее, расчёт систематически завышает добычу.

Поэтому для сезонной эксплуатации полезно вести отдельные профили: зимний и летний. В помещении с дешёвым естественным охлаждением зима может дать выше uptime и меньше затрат на вентиляцию. Летом тот же тариф электроэнергии не отражает всей экономики, если добавляется кондиционирование.

Не пытайтесь компенсировать плохое охлаждение только повышением оборотов вентиляторов без оценки электрики и шума. Инфраструктура должна выдерживать постоянную тепловую нагрузку. Майнинг — это непрерывный промышленный режим даже для одного домашнего аппарата.

Задержка до пула и выбор точки подключения

Share должна успеть попасть к пулу до того, как работа устареет. Большая задержка сама по себе не означает катастрофу, но нестабильная сеть и высокий latency повышают риск stale. Если пул предлагает несколько региональных endpoints, выбирайте тот, где соединение устойчиво и задержка ниже, а не тот, который просто первым указан в инструкции.

Полезно смотреть не только ping, но и фактический stale rate за сутки. Маршрут может иметь небольшой средний ping, но периодические потери пакетов. Для майнера важна стабильность. Если два endpoints дают одинаковую комиссию, тот, где accepted shares выше, фактически сокращает время до накопления целевого количества сатоши.

При резервном подключении настройте failover так, чтобы аппарат автоматически переходил на запасной сервер, но периодически проверяйте, что запасная конфигурация всё ещё актуальна. Ошибка в резервном адресе обнаруживается обычно именно тогда, когда основной пул недоступен.

Как комиссия пула меняет накопление 1 BTC

Комиссия в 1–3% кажется небольшой, но на цели ровно 1 BTC её видно. Если валовой расчёт даёт 0,0001 BTC в сутки, при условной комиссии 1% чистое начисление — около 0,000099 BTC, при 2% — 0,000098, при 3% — 0,000097. Соответственно, срок до чистого 1 BTC растёт примерно на 1,01%, 2,04% и 3,09% относительно модели без fee.

Реальный пул может учитывать transaction fees и применять другую формулу, поэтому таблица показывает только механику процента. Сначала разберите условия конкретной схемы, затем подставляйте fee. Нельзя сравнивать два пула только по строке «комиссия», если один включает fee-компонент блока, а другой нет.

Что такое «1 BTC чистыми»

Есть минимум три разных цели, которые люди называют одинаково. Первая — пул начислил суммарно 1 BTC до расходов. Вторая — на личный кошелёк пришёл 1 BTC после pool fee и payout fee. Третья — вы заработали экономический эквивалент 1 BTC после вычета электричества, оборудования, ремонта и налогов. Это совершенно разные показатели.

Статья считает время до количества BTC, а не до финансовой прибыли. Если электричество за период стоит больше рыночной стоимости добытых монет, технически 1 BTC можно намайнить, но экономически результат будет отрицательным. Для бизнеса ключевым показателем становится себестоимость одного сатоши или одного BTC, а не просто календарная скорость.

Перед стартом запишите, какой именно показатель является целью. Это избавляет от ситуации, когда продавец ASIC показывает валовые BTC, а пользователь мысленно воспринимает их как чистую прибыль.

Реинвестирование меняет траекторию, но не отменяет риск

Некоторые модели предполагают, что все первые выплаты автоматически идут на покупку новых ASIC. Тогда локальный хешрейт растёт, и путь к 1 BTC может ускоряться нелинейно. Но такая модель требует цены оборудования, сроков поставки, подключения, будущей difficulty и остаточной стоимости старых машин. Простое правило «реинвестируй и срок сократится вдвое» не работает.

Если новое оборудование появится через шесть месяцев, к этому моменту сеть может быть другой. Если покупка финансируется долгом, появляется стоимость капитала. Если техника простаивает на таможне или нет доступной мощности, запланированный hashrate существует только в таблице.

Реинвестиционный сценарий полезен как отдельная ветка: базовая модель без покупок, модель с добавлением оборудования по датам и стресс-модель с задержкой. Не смешивайте их в одно оптимистичное число.

Как проверить difficulty и network hash rate самостоятельно

В Bitcoin Core RPC команда getdifficulty возвращает proof-of-work difficulty относительно минимальной сложности. getnetworkhashps оценивает средний сетевой хешрейт по выбранному числу блоков или по периоду с последней корректировки. Эти значения можно получать со своего узла и не зависеть от интерфейса стороннего калькулятора.

Если используете explorer, фиксируйте конкретный блок и его difficulty. Так расчёт можно повторить. Для сетевого хешрейта помните, что это оценка, потому что сеть не публикует точный счётчик всех работающих ASIC. Hash rate выводится из частоты найденных блоков и difficulty.

Проверка собственным узлом особенно полезна при больших инвестициях в оборудование. Ошибка в одном нуле network hashrate способна полностью исказить бизнес-план, а исходные данные Bitcoin доступны для независимой верификации.

Как отличить расчёт от маркетингового обещания продавца ASIC

Фраза «этот аппарат добывает 1 BTC за два года» без даты и сетевых параметров должна вызывать вопросы. Попросите показать difficulty, subsidy, network hashrate, pool fee, uptime и формулу. Если продавец отвечает только текущей доходностью в долларах, это другой показатель.

Ещё один красный флаг — фиксированная доходность в BTC на несколько лет вперёд. Bitcoin difficulty и subsidy меняются. Даже если продавец честно использовал сегодняшние данные, результат не может быть гарантирован на многолетнем горизонте. Для оборудования корректнее показывать несколько сценариев и чувствительность к difficulty.

Наконец, проверяйте единицы. 200 TH/s, 2 PH/s и 200 PH/s отличаются на порядки. В рекламных таблицах иногда рядом стоят модели разного класса, а пользователь переносит срок одной установки на другую.

Что делать, если фактические выплаты ниже модели на 10%

Сначала не обвиняйте пул и не меняйте оборудование. Разложите разницу. Сравните фактический accepted hashrate с тем, который использован в модели. Проверьте uptime, stale/rejected и pool fee. Затем сравните фактическое число блоков и текущую difficulty с исходной датой расчёта. Только после этого ищите аномалию.

Если hashrate и uptime совпадают, но выплаты ниже, возможно, модель использовала устаревший network hash rate или не учла рост difficulty. В PPLNS-схеме короткий период может также отражать pool luck. Если отклонение сохраняется на достаточно длинном горизонте, проверьте правила начисления и отчёты пула.

Хороший журнал превращает спор в диагностику. Записывайте daily accepted TH/s, BTC accrued, fee, uptime и difficulty. Тогда видно, какой фактор изменился.

Что делать, если фактические выплаты выше модели

Положительное отклонение тоже нужно объяснить, а не считать новой нормой. Возможно, сеть временно находила блоки быстрее среднего, пул был удачлив, transaction fees выросли или difficulty снизилась. Если просто заменить базовый прогноз на один удачный день, будущие ожидания станут завышенными.

Используйте скользящее среднее и сохраняйте консервативную базу. Разовые всплески fees особенно опасно переносить на годы. Для долгосрочной экономики лучше недооценить переменный компонент и отдельно увидеть upside, чем финансировать постоянные расходы из временного пика.

Когда цель «1 BTC» лучше заменить другой метрикой

Целый биткоин психологически понятен, но для операционного управления часто неудобен. Если текущий срок исчисляется десятилетиями, полезнее отслеживать сатоши на TH в сутки, сатоши на кВт·ч и стоимость 100 000 сатоши. Эти показатели реагируют на изменения сети намного быстрее и помогают принимать решения еженедельно.

Для небольшой фермы можно использовать BTC per PH/day. Для домашнего аппарата — sat/TH/day и рубли на кВт·ч. Цель 1 BTC остаётся долгосрочным ориентиром, но ежедневные решения принимаются по текущей эффективности.

Такой переход не меняет конечную арифметику. Он просто даёт масштаб, на котором можно управлять системой, а не ждать годы до единственной контрольной точки.

Порог выплаты не сокращает и не увеличивает майнинг

Пулы часто устанавливают минимальную сумму вывода. Из-за этого пользователь может видеть накопленные сатоши в интерфейсе, но не получать on-chain транзакцию на кошелёк до достижения порога. Иногда это воспринимают как «пул медленно майнит», хотя вычислительная работа и внутреннее начисление уже произошли. Порог влияет на частоту вывода и кастодиальный риск, но не на долю хешрейта.

Для цели «1 BTC на собственном адресе» payout threshold имеет практическое значение: внутренний баланс пула нельзя считать равным монетам под вашим самостоятельным контролем. Если сервис меняет правила, блокирует аккаунт или требует дополнительную проверку, момент фактического получения может отодвинуться. Поэтому в журнале полезно иметь две колонки: accrued и paid.

Частые мелкие выплаты удобны для контроля, но увеличивают число UTXO и могут повлиять на будущие комиссии при расходовании. Редкие крупные выплаты уменьшают количество UTXO, но дольше оставляют накопленное у оператора. Это уже вопрос управления кошельком, а не производительности ASIC.

Десять минут на блок — среднее, а не расписание

Bitcoin не выпускает новый блок ровно каждые 600 секунд. Иногда два блока разделяют секунды, иногда сеть ждёт заметно дольше. Целевой десятиминутный интервал проявляется как среднее на длинном горизонте. Поэтому в отдельный день может быть не 144 блока, а больше или меньше, и суточная сумма subsidy соответственно отклонится от модельных 450 BTC.

Это объясняет, почему даже при стабильной difficulty и hashrate фактические выплаты пула меняются. На коротком окне случайность блоков заметна. На более длинном горизонте отклонения сглаживаются, но никогда не превращают сеть в механические часы.

Если проверяете модель по одному дню, не требуйте идеального совпадения. Лучше сравнивать недельное или месячное накопление с учётом режима пула. Для соло краткосрочная случайность ещё сильнее: один найденный блок полностью меняет статистику конкретного майнера.

Ремонт и амортизация: скрытое время, которого нет в калькуляторе

Многолетний срок до 1 BTC предполагает, что оборудование каким-то образом переживёт весь период. В реальности вентиляторы, блоки питания, платы и соединения требуют обслуживания. Даже если ремонт экономически оправдан, дни доставки деталей и диагностики уменьшают uptime. Поэтому длинный расчёт должен иметь резерв на технический простой.

Амортизация важна и по другой причине. ASIC может физически работать, но стать экономически устаревшим. Если новая техника делает значительно больше TH/s на ватт, старый аппарат может перестать покрывать электричество задолго до отказа. Тогда календарный путь до 1 BTC обрывается не технически, а экономически.

Для бизнес-модели разумно задавать предполагаемый срок эксплуатации оборудования и остаточную стоимость. Если идеализированный срок до 1 BTC в несколько раз превышает жизненный цикл, целый BTC нельзя использовать как единичный KPI одного аппарата.

Почему прибыль в рублях и накопление BTC могут двигаться в разные стороны

Майнер получает BTC, а значительная часть расходов оплачивается в национальной валюте. Если цена BTC растёт, денежная выручка от того же количества сатоши увеличивается, хотя техническое время до 1 BTC не меняется. Если цена падает, количество добываемых сатоши может быть прежним, но денежная маржа исчезает.

Из-за этого нужно вести две модели. Техническая отвечает: сколько BTC ожидается на единицу хешрейта. Финансовая отвечает: сколько стоит этот BTC после электричества и других затрат. Смешивание моделей приводит к ошибке, когда рост цены воспринимают как рост производительности ASIC.

Для оценки эффективности оборудования лучше держать BTC/day или sat/TH/day отдельно от денежного P&L. Тогда видно, что изменилось: сеть или рынок. Если BTC/day снизился при росте рублёвой прибыли, причина может быть исключительно в цене актива.

Контрольный список перед тем, как верить сроку до 1 BTC

Перед покупкой ASIC или запуском фермы перепроверьте расчёт своими руками. Зафиксируйте difficulty и высоту блока. Сверьте реальный hashrate устройства. Уточните потребление из розетки, тариф и доступную электрическую мощность. Проверьте pool fee, payout scheme и порог вывода. Затем посчитайте базовый BTC/day и только после этого переводите результат в годы.

• Есть дата и источник difficulty, а не безымянная цифра.
• TH/s, PH/s и EH/s приведены к одним единицам.
• Subsidy соответствует текущей эпохе Bitcoin.
• Комиссии транзакций не выданы за гарантированный постоянный доход.
• Uptime и rejected shares учтены отдельно.
• Pool fee и payout threshold проверены по текущим правилам.
• Электричество считается по фактическому потреблению, а не только по паспорту.
• Есть стресс-сценарий роста difficulty и простоя.
• Срок до 1 BTC не называется гарантией.

Если хотя бы один из этих пунктов неизвестен, итоговый срок нужно считать предварительным. Хорошая модель не обязана предсказывать будущее; она обязана честно показывать, из каких допущений получено число и как оно изменится при новых данных.

Как обновлять расчёт после каждой корректировки сложности

Когда сеть проходит очередной период корректировки difficulty, старый срок автоматически становится историческим. Не нужно переписывать всю модель: замените difficulty или network hashrate, оставьте фактический hashrate установки и пересчитайте BTC/day. Если одновременно изменился режим ASIC или пул, меняйте параметры по одному, чтобы понимать вклад каждого фактора.

Полезно хранить версии расчёта по датам. Например: 1 сентября — difficulty A, accepted hashrate B, ожидаемый BTC/day C; через две недели — новые значения. Такая история показывает, как быстро меняется экономика вашей установки и насколько реалистичным был первоначальный план.

Если цель — накопление определённого количества BTC, ведите остаток: сколько уже получено на собственный кошелёк и сколько осталось. Для оставшейся части используйте только текущую модель, а не первоначальный срок. Тогда прошлые хорошие или плохие периоды не искажают будущую оценку.

Почему лучший ответ — диапазон и сценарии, а не одна дата

Читателю хочется получить число: «ровно 412 дней». Но точность такого ответа иллюзорна. Даже при известных сегодняшних параметрах будущая difficulty неизвестна, а в соло добавляется фундаментальная случайность. Поэтому профессиональный расчёт показывает базовый ориентир, диапазон при изменении difficulty и отдельно вероятность для соло.

Например, можно взять сегодняшнюю модель как нулевую точку, затем проверить сценарий, где effective hashrate снижается на 5% из-за uptime, и сценарий роста difficulty. Если во всех разумных вариантах срок многократно превышает предполагаемый срок службы оборудования, вывод устойчив: цель одного BTC с этой установкой требует масштабирования или пересмотра.

Такой подход делает статью полезной спустя время. Конкретные сетевые числа устареют, но формулы, порядок проверки и различие между pool expected value и solo probability останутся применимыми. Достаточно подставить новый снимок сети.

Итоговый ответ

При параметрах сети, наблюдавшихся 1 сентября 2026 года, ASIC на 200 TH/s имеет математическое ожидание базовой субсидии примерно 0,0001 BTC в сутки и условный срок около 27,4 года до суммарного 1 BTC в пуловой модели, если невозможным образом заморозить difficulty, subsidy и uptime. При 500 TH/s ориентир сокращается примерно до 11 лет, при 1 PH/s — до 5,5 года.

В соло ожидаемый срок до собственного блока намного длиннее, потому что один успешный блок даёт сразу 3,125 BTC плюс fees. Для 200 TH/s текущая математическая средняя до блока — около 85,7 года, но это не расписание: вероятность события распределена случайно.

Реальный ответ всегда меняется. Difficulty корректируется, сетевой хешрейт растёт или падает, халвинг уменьшает subsidy, оборудование простаивает, а пул удерживает комиссию. Поэтому использовать одну сегодняшнюю цифру как обещание нельзя. Правильный вывод — регулярно пересчитывать модель и следить за эффективным BTC per TH и себестоимостью.

Если нужно глубже понять, откуда берётся блок и почему proof-of-work работает, откройте материал как работает Bitcoin. Время до целого BTC само по себе не отвечает на вопрос, выгоден ли майнинг.