Комиссия Bitcoin до отправки: как выбрать sat/vB, рассчитать vsize и не переплатить

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

В Bitcoin комиссия определяется не процентом от суммы перевода. Основная логика другая: кошелёк формирует транзакцию определённого виртуального размера, а затем применяет к этому размеру ставку fee rate. Упрощённая рабочая формула выглядит так: комиссия в сатоши = virtual size в vB × ставка в sat/vB. Поэтому перевод 0,01 BTC не обязан быть дешевле перевода 1 BTC. Если первый собирается из множества мелких UTXO, он может занимать больше места и заплатить больше.

Ставка sat/vB отвечает за конкурентоспособность транзакции на рынке блокового пространства. Размер vsize зависит прежде всего от структуры: какие UTXO используются как inputs, сколько создаётся outputs, есть ли сдача, какие скрипты и типы адресов участвуют. А требуемый fee rate зависит от состояния mempool и того, насколько быстро вам действительно нужно подтверждение.

Поэтому вопрос «какая комиссия Bitcoin сейчас?» полезен только как начало. Перед нажатием Send нужно ответить ещё на четыре вопроса: какой vsize сформировал мой кошелёк; какую цель подтверждения я выбрал; какие UTXO он собирается потратить; смогу ли я безопасно повысить fee после отправки, если рынок комиссий изменится. Эти проверки дают больше контроля, чем слепое копирование «рекомендуемых 5 или 20 sat/vB» из статьи, написанной несколько часов назад.

Эта инструкция посвящена именно решению до подписи и broadcast. Если транзакция уже отправлена и долго не подтверждается, используйте отдельный материал OneMagic о том, как ускорить зависшую Bitcoin-транзакцию через RBF или CPFP. Здесь задача другая: заранее понять стоимость конкретного перевода и не создавать проблему, которую потом придётся исправлять.

Короткий ответ: из чего складывается комиссия Bitcoin перед отправкой

Для обычного пользователя достаточно разделить расчёт на два уровня. Первый — fee rate, то есть сколько сатоши вы готовы платить за каждый виртуальный байт транзакции. Второй — vsize, то есть сколько виртуальных байтов займёт сформированная операция. Перемножение этих величин даёт сетевую комиссию в sat.

Предположим, кошелёк до подписи показывает размер 180 vB и выбранную ставку 6 sat/vB. Расчёт: 180 × 6 = 1080 sat. Если структура транзакции не меняется, повышение ставки до 12 sat/vB удвоит общую комиссию до 2160 sat. Если ставка остаётся 6 sat/vB, но кошелёк добавляет новые inputs и размер увеличивается до 360 vB, комиссия тоже удвоится — уже из-за структуры.

Именно поэтому нельзя оценивать перевод только по сумме BTC. В Bitcoin вы платите за использование ограниченного места в блоке, а не за «процент от пересылаемых денег». Один крупный UTXO может позволить построить компактную транзакцию на большую сумму. Десятки мелких поступлений способны создать большую операцию даже при небольшом платеже.

Есть третий уровень — способ, которым кошелёк выбирает ставку. Современный кошелёк обычно оценивает рынок комиссий автоматически: пользователь выбирает желаемую скорость или target в блоках, а программное обеспечение предлагает fee rate. В Bitcoin Core 31.0 функция оценки привязана именно к цели подтверждения в блоках; доступны более чувствительный к краткосрочным изменениям режим economical и более осторожный conservative.

Поэтому ручной ввод sat/vB — не обязательный признак «продвинутого» использования. Если кошелёк имеет качественный estimator и показывает итоговый vsize/fee до подписи, автоматический режим часто разумнее числа из чужой инструкции. Ручная ставка полезна, когда вы понимаете текущий mempool, можете оценить последствия задержки и хотите контролировать стоимость точнее.

Перед подтверждением полезно видеть пять полей: сумма получателю, fee rate, total network fee, предполагаемый размер/vsize и выбранная цель подтверждения. Если приложение показывает только «быстро / обычно / медленно», попробуйте открыть расширенные детали. Отсутствие деталей не делает перевод неправильным, но уменьшает возможность понять, за что именно вы платите.

Что такое sat/vB и почему нельзя сравнивать переводы только по общей комиссии

sat/vB читается как «сатоши за виртуальный байт». Сатоши — минимальная стандартная единица BTC, а virtual byte — единица учёта размера транзакции после правил SegWit. Fee rate позволяет сравнивать конкурентоспособность операций разного размера.

Два человека могут заплатить одинаковые 3000 sat и получить разный приоритет. Если первая транзакция занимает 150 vB, её ставка равна 20 sat/vB. Если вторая занимает 600 vB, ставка всего 5 sat/vB. Для выбора в блок майнеру важен не только абсолютный fee, а экономическая привлекательность занимаемого пространства; поэтому total fee без vsize мало говорит о позиции в очереди.

Обратная ситуация тоже важна. Две транзакции с одинаковыми 10 sat/vB могут иметь общую комиссию 1500 и 6000 sat, если их размеры различаются в четыре раза. Пользователь второй транзакции не обязательно «выбрал слишком дорогую комиссию» — возможно, его кошелёк вынужден потратить больше inputs или создать больше outputs.

Из этого следует простой способ проверки. Если приложение показывает total fee, но скрывает ставку, разделите комиссию в sat на vsize, если размер доступен. Если показывает fee rate и vsize — перемножьте их и сравните с total fee. Небольшое отличие может возникать из-за округления или окончательной сериализации, но порядок величины должен быть понятен.

Не путайте sat/vB с sat/byte и тем более с BTC/kB или BTC/kvB. В современных Bitcoin Core RPC для отправки ставка может задаваться непосредственно в sat/vB, а другие низкоуровневые показатели могут возвращаться в иной единице. Ошибка единиц способна превратить разумную ставку в огромную переплату. Если кошелёк просит просто число «fee rate», проверьте подпись поля, а не переносите значение из другого приложения наугад.

В пользовательской практике sat/vB удобно воспринимать как цену одного места, а vsize — как количество покупаемого места. Чтобы снизить итоговую комиссию, можно работать с любой частью произведения: выбрать менее срочный fee rate либо уменьшить размер транзакции за счёт разумного управления UTXO. Это два разных инструмента, и они не должны подменять друг друга.

Virtual size и weight: почему Bitcoin считает не обычные байты

После внедрения Segregated Witness в Bitcoin появилась система веса транзакции. BIP 141 определяет transaction weight через базовый и полный сериализованный размер, а virtual transaction size — как вес, делённый на четыре с округлением вверх. Witness-данные получают меньший вес, чем невитнесная часть, поэтому «размер файла транзакции в байтах» и vsize могут различаться.

Для пользователя это объясняет, почему в обозревателе можно встретить одновременно size, weight и virtual size. При расчёте fee rate ориентируются на vsize. Если транзакция имеет weight 800 WU, её виртуальный размер по формуле будет 200 vB. Если weight 801 WU, после деления и округления получается 201 vB. Комиссия при 8 sat/vB соответственно составит 1600 или 1608 sat.

Не нужно вручную вычислять weight каждого скрипта перед обычной отправкой. Хороший кошелёк знает структуру своих inputs, тип change output и может оценить финальный размер. Но понимание vsize полезно в трёх случаях: когда total fee кажется неожиданно большим; когда вы вручную выбираете UTXO; когда сравниваете два варианта одной операции.

Например, вы формируете один и тот же платёж, но в первом варианте кошелёк выбирает один input, а во втором — восемь. Если vsize заметно увеличился, причина стоимости уже видна без гадания о «перегруженной сети». Ставка могла остаться прежней, а изменился объём данных.

Типы адресов также влияют на структуру скриптов и вес. Bitcoin Core поддерживает разные change types, включая legacy, wrapped SegWit, bech32 и bech32m. Однако правило «любой bc1 всегда дешевле любого другого адреса» слишком грубое: итог зависит от того, какие именно inputs расходуются и outputs создаются. Поэтому для конкретного платежа лучше смотреть на фактически рассчитанный vsize, а не на одну букву префикса.

Практический вывод: перед отправкой не пытайтесь угадывать комиссию только по количеству BTC и типу адреса получателя. Сначала дайте кошельку сформировать preview транзакции. Именно после выбора inputs и change становится известна структура, с которой имеет смысл применять fee rate.

UTXO и inputs: почему кошелёк с большим балансом может создать дорогую транзакцию

Баланс Bitcoin-кошелька — это не одна запись «у вас 0,8 BTC». Он складывается из доступных неизрасходованных выходов предыдущих транзакций — UTXO. Когда вы отправляете BTC, кошелёк выбирает один или несколько таких выходов и использует их как inputs новой транзакции.

Представьте два кошелька с одинаковым балансом 0,1 BTC. В первом вся сумма пришла одним UTXO 0,1 BTC. Во втором баланс собран из ста мелких поступлений по 0,001 BTC. Для платежа 0,08 BTC первый кошелёк потенциально может использовать один input, а второму понадобится множество. Каждый дополнительный input увеличивает данные и, следовательно, vsize.

Это не означает, что кошелёк всегда использует минимальное число inputs. Алгоритм coin selection учитывает сдачу, доступность подтверждённых выходов, настройки приватности и другие ограничения. Поэтому два приложения, контролирующие похожие наборы монет, могут построить операции разного размера.

Bitcoin Core предоставляет список UTXO через listunspent и позволяет в низкоуровневых операциях указывать конкретные inputs. В пользовательских кошельках аналогичная функция обычно называется coin control, coins, UTXOs или outputs. Если её нет, выбор делает программа автоматически.

Перед крупным или дорогим по комиссии переводом полезно открыть UTXO-список, если кошелёк это позволяет. Смотрите не только на общий баланс, но и на количество фрагментов. Если для небольшой суммы интерфейс выбирает десятки inputs, высокая total fee может быть рациональным следствием накопленной структуры кошелька.

Есть важное ограничение: ручной coin control способен ухудшить приватность. Объединение UTXO из разных контекстов в одной транзакции создаёт on-chain связь между ними. Поэтому «выбрать самые крупные монеты и всё объединить» нельзя считать универсальным советом. Экономия комиссии и минимизация связности адресов иногда конфликтуют.

Опытный пользователь принимает это как отдельное решение: какая задача важнее сейчас — срочный платёж, минимальная комиссия, сохранение определённого набора UTXO или приватность. Для обычного перевода безопаснее сначала изучить автоматический preview, а ручное вмешательство использовать только при понятном выигрыше.

Outputs и change: почему «сдача» увеличивает размер и почему новый адрес не означает утечку BTC

Когда выбранные inputs превышают сумму платежа плюс fee, разница обычно возвращается владельцу кошелька как change output. Это похоже на сдачу при оплате наличными, только в Bitcoin сдача создаётся отдельным выходом новой транзакции и часто отправляется на новый адрес вашего же кошелька.

Допустим, у вас один UTXO 0,05 BTC, а получателю нужно 0,02 BTC. Кошелёк не «отрезает» часть существующего UTXO. Он расходует его целиком как input и создаёт как минимум выход получателю; оставшаяся величина после комиссии возвращается в новый output сдачи. Поэтому в обозревателе после отправки можно увидеть незнакомый адрес, который фактически контролируется вашим кошельком.

Change увеличивает число outputs, а значит влияет на vsize. Но попытка любой ценой избавиться от сдачи тоже не всегда экономна. Кошелёк может подобрать другой набор inputs, создать больше данных или сформировать невыгодный остаток. Хорошие алгоритмы coin selection учитывают стоимость создания и будущего расходования change.

Ещё одна настройка — subtract fee from amount. В Bitcoin Core можно явно указать, что комиссия вычитается из одного или нескольких outputs. Тогда получатель получает меньше суммы, которую вы ввели. Если оплата требует точные 0,005 BTC, такое поведение способно создать недоплату. Поэтому перед подписью проверяйте не только total debit кошелька, но и фактический amount recipient.

В обычном режиме комиссия оплачивается сверх суммы получателю: inputs должны покрыть payment + fee, а остаток возвращается change. В режиме «отправить всё» логика другая: кошелёк старается потратить выбранные UTXO и отправить доступный остаток после fees на один или несколько адресов без привычной сдачи.

Если после изменения суммы на несколько сатоши total fee внезапно меняется, причина может быть не в mempool. Алгоритм мог перейти к другому набору inputs или решить создать/не создавать change. Смотрите на vsize: если он изменился при той же ставке, вы нашли структурную причину.

Не пугайтесь нового change-address в обозревателе, но и не принимайте любой дополнительный output за свой автоматически. В аппаратном или PSBT-сценарии кошелёк должен уметь распознать сдачу. Если устройство показывает второй внешний адрес, который программа не объясняет как change, остановите подпись и разберите структуру операции.

Как тип inputs и адресов влияет на стоимость, не превращая выбор адреса в магию

Legacy, wrapped SegWit, native SegWit и Taproot используют разные структуры скриптов и свидетельств. Из-за этого одинаковое число inputs и outputs может дать разный weight. Но пользовательская формула остаётся прежней: кошелёк показывает итоговый vsize, и именно его нужно умножать на выбранную ставку.

Распространённая ошибка — выбирать адрес получателя исключительно по принципу «этот начинается с bc1, значит комиссия точно будет минимальной». Адрес получателя влияет на output, но большая часть размера нередко формируется inputs, которые вы расходуете. Если кошелёк собирает десятки старых UTXO, одна смена формата destination не превратит большую транзакцию в маленькую.

При создании собственного современного кошелька разумно использовать поддерживаемые им актуальные типы адресов и не возвращаться к legacy без необходимости совместимости. Но перед переводом на биржу, обменник или сервис нельзя самостоятельно «преобразовать» выданный депозитный адрес ради экономии. Отправляйте только на реквизит, который сервис официально показывает для Bitcoin.

Для change Bitcoin Core умеет выбирать тип выхода автоматически или по настройке. Пользовательские кошельки делают это без отдельного диалога. Это ещё одна причина не пытаться вручную оценивать всю транзакцию по внешнему виду одного адреса.

Если вы сравниваете два кошелька по комиссии, делайте честный тест: одинаковый набор spendable UTXO, тот же получатель, та же сумма и одинаковый fee rate. Только тогда разница vsize показывает различие в структуре или coin selection. Сравнение двух случайных платежей вводит в заблуждение.

Для аппаратных и multisig-кошельков структура может быть сложнее обычного single-signature перевода. В этом случае особенно полезно доверять фактическому preview и PSBT, а не таблице «типичный Bitcoin перевод — N байт». Таблица может быть верной для другого сценария, но неверной для вашей политики подписей.

Итоговое правило простое: формат адреса — одна из переменных, но решение о fee принимается по vsize всей сформированной транзакции. Это защищает от чрезмерно простых советов и помогает объяснить стоимость именно вашего платежа.

Mempool: почему «правильная» ставка меняется даже при неизменном размере транзакции

Mempool — локальный набор неподтверждённых транзакций, которые узел считает допустимыми для последующего включения в блок. У разных узлов содержимое может немного различаться, но для пользователя важна общая идея: новые операции конкурируют за ограниченное блоковое пространство, и рынок fee rate меняется вместе с очередью.

Bitcoin Core показывает через getmempoolinfo количество транзакций, суммарный virtual size, total fees и минимальные ставки, с которыми текущий узел принимает операции. Эти параметры не являются универсальной «ценой следующего блока». Они описывают состояние конкретного mempool и правила узла.

Чтобы выбрать ставку, недостаточно узнать, сколько неподтверждённых транзакций находится в очереди. Десять тысяч компактных низкооплачиваемых операций могут оказывать меньше давления на ближайшие блоки, чем меньший набор большого vsize с конкурентными feerates. Поэтому графики mempool обычно группируют объём по ставкам.

С практической точки зрения нужно смотреть на то, сколько виртуальных байтов находится выше вашей ставки и как быстро этот слой очереди может быть обработан. Именно поэтому live fee estimators меняют рекомендацию: новые высокооплачиваемые транзакции могут поднять порог, а несколько ёмких блоков — очистить верхние слои.

Не существует правила «ночью всегда дёшево» или «в выходные всегда 1 sat/vB». Исторические привычки иногда работают, но событие на рынке, массовый вывод с бирж, новая on-chain активность или изменение спроса способны нарушить календарный шаблон. Ориентируйтесь на текущую очередь и собственную срочность.

Если кошелёк открыт на экране подтверждения долго, обновите estimate перед подписью. Ставка, разумная десять минут назад, могла стать либо завышенной, либо слишком низкой. Особенно это важно во время резкого движения рынка, когда пользователи одновременно перемещают средства.

Главная мысль: vsize отвечает на вопрос «сколько места я покупаю», mempool — «сколько сейчас стоит место нужного приоритета». Только их комбинация даёт осмысленную комиссию. Если меняется total fee при неизменном vsize, смотрите на rate; если rate тот же, а fee вырос, ищите структурное изменение.

Цель подтверждения: выбирайте блоки, а не обещание «10 минут»

Bitcoin-кошельки часто превращают сложный выбор в кнопки «быстро», «обычно», «экономно». За ними обычно стоит целевой горизонт подтверждения. Bitcoin Core принимает conf_target в блоках для оценки fee. Это более корректный язык, чем гарантированное число минут.

Блоки не появляются по расписанию каждые ровно десять минут. Интервал случайный: два блока могут прийти близко друг к другу, а следующий — заметно позже среднего. Поэтому «цель 2 блока» не следует переводить в обещание «точно 20 минут». Estimator пытается подобрать ставку, которая исторически и по текущему рынку соответствует выбранному горизонту.

Перед оплатой сначала определите реальный дедлайн. Если продавец держит заказ 30 минут, ставка с целью «в течение суток» экономически бессмысленна, даже если она дешевле. Если вы переводите BTC между собственными кошельками и готовы ждать до завтра, переплачивать за следующий блок тоже может быть лишним.

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

Для крупной операции срочность может быть не технической, а риск-управленческой. Например, вы перемещаете средства с устройства, которому перестали доверять. Тогда более высокий fee оправдан стоимостью времени. Для планового перевода в холодное хранение можно выбрать более длинный target.

Превратите выбор в явное решение: что дороже — несколько тысяч дополнительных sat или вероятность задержки. Такой вопрос полезнее «какая ставка самая правильная». Одному пользователю нужен следующий блок, другому достаточно подтверждения сегодня.

Если приложение не показывает target в блоках, используйте его уровни как интерфейс к той же идее. Но не считайте названия универсальными: «Normal» в двух кошельках может опираться на разные алгоритмы и горизонты. Сравнивать надо цель и итоговую ставку, а не название кнопки.

Economical и conservative: почему два корректных estimator могут предложить разные ставки

Bitcoin Core 31.0 различает режимы economical и conservative. Economical использует более короткий временной горизонт и быстрее реагирует на краткосрочное снижение prevailing fee market; результат может быть ниже. Conservative смотрит на более длинный горизонт, медленнее реагирует на падение и потенциально предлагает более высокую ставку.

Это не деление на «правильный» и «неправильный» режим. Economical подходит пользователю, который чувствителен к цене и готов принять больший риск задержки. Conservative полезнее, когда стоимость повторного вмешательства или пропущенного дедлайна выше небольшой экономии.

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

Сравнивайте не только число sat/vB, но и скрытую цель. Если один кошелёк предлагает «next block», а второй — «within 6 blocks», различие ставки естественно. Нельзя объявлять второй estimator плохим лишь потому, что он дешевле.

Если вы выбираете ручной fee rate, вы фактически отключаете часть автоматической логики и сами принимаете рыночный риск. Это разумно, когда у вас есть актуальный mempool и понимание дедлайна. Но копировать вчерашнюю ставку из форума хуже, чем использовать свежий estimator.

Для важного платежа полезен перекрёстный контроль: сравните оценку кошелька с независимым live mempool-источником. Если кошелёк предлагает ставку в несколько раз выше текущих уровней для той же цели, выясните причину. Возможно, estimator консервативен; возможно, preview содержит большую транзакцию; возможно, вы смотрите на total fee, а не rate.

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

Как выбрать sat/vB самому: алгоритм для срочного, обычного и несрочного перевода

Ручной выбор стоит начинать не с числа, а с классификации задачи. Введите сумму и адрес, дайте кошельку выбрать inputs, откройте preview и зафиксируйте vsize. Затем посмотрите live fee market и определите целевой горизонт.

Срочный платёж с реальным дедлайном

Если пропуск следующего одного-двух блоков создаёт финансовый или операционный риск, выбирайте ставку, конкурентную верхнему слою mempool для соответствующего target. Не ставьте огромный запас «на всякий случай» без причины: переплата не делает блок детерминированным. Перед подписью обновите estimate.

Обычный перевод без жёсткого дедлайна

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

Несрочное перемещение и обслуживание UTXO

Если вы готовы ждать долго и кошелёк поддерживает повышение fee при необходимости, можно использовать более низкую ставку в периоды слабого спроса. Но минимум, который ваш узел или сеть готова эффективно ретранслировать, и будущий fee market остаются ограничениями. «Самый низкий видимый rate» не равен гарантии подтверждения.

После выбора ставки посчитайте total fee в sat и переведите её в BTC: 1000 sat = 0,00001000 BTC. Для оценки в фиатной валюте используйте текущий курс только как удобство; on-chain сеть списывает sat, а не рубли или доллары. При изменении курса фиатный эквивалент той же комиссии изменится.

Наконец, сравните fee с экономической ценностью перевода. Для платежа на 20 долларов комиссия в несколько долларов может быть нерациональной; для перемещения крупного резерва та же комиссия может быть несущественной. Это не означает, что сеть берёт процент — просто пользовательская оценка расходов зависит от цели.

Если результат выглядит нелепо, не уменьшайте rate автоматически. Сначала проверьте vsize и количество inputs. Возможно, проблема не в цене блокового пространства, а в структуре вашего кошелька. Только если структура объяснима, имеет смысл корректировать target.

Как посчитать итоговую комиссию вручную: три примера с разными причинами стоимости

Примеры ниже не являются рекомендацией текущих ставок. Числа выбраны для арифметики; реальный fee rate нужно брать из актуального estimator в момент отправки.

Пример 1: меняется только fee rate

Кошелёк сформировал 160 vB. При 4 sat/vB комиссия равна 640 sat. При 10 sat/vB — 1600 sat. При 25 sat/vB — 4000 sat. Структура неизменна, поэтому стоимость растёт строго вместе со ставкой. Такой сценарий показывает чистую цену срочности.

Пример 2: ставка одинаковая, но вырос vsize

Два платежа используют 8 sat/vB. Первый имеет 150 vB и стоит 1200 sat. Второй — 450 vB и стоит 3600 sat. Пользователь не выбирал «в три раза более дорогую сеть»; кошелёк создал в три раза больший virtual size. Следующий вопрос — почему: больше inputs, outputs или более сложная структура.

Пример 3: сравниваем две стратегии одной операции

Вариант A использует много мелких UTXO: 500 vB при 6 sat/vB = 3000 sat. Вариант B после другого coin selection имеет 260 vB при той же ставке = 1560 sat. Разница 1440 sat возникает из-за vsize. Но выбирать вариант B можно только если изменение inputs не создаёт нежелательных связей или других последствий.

Эти три примера покрывают две независимые переменные. Не нужно строить десятки таблиц на 1, 2, 3, 4… sat/vB: формула линейна. Новое знание возникает там, где меняется структура или цель, а не только число в одной ячейке.

Почему маленький перевод BTC иногда имеет комиссию больше ожидаемой

Самая частая причина — путаница между value и data size. Отправка 0,0002 BTC не означает, что транзакция «маленькая» в блокчейн-смысле. Если для неё кошелёк собирает 20 inputs, она может быть крупнее перевода 2 BTC из одного UTXO.

Вторая причина — накопленная «криптовалютная мелочь». Частые небольшие поступления создают множество UTXO. Пока fee market дешёвый, проблема незаметна. Во время дорогого рынка попытка потратить их вместе превращает каждую мелкую монету в дополнительные virtual bytes.

Третья причина — несколько outputs. Если вы платите нескольким получателям, добавляете change или используете сложную схему кошелька, размер растёт. Это не всегда плохо: batching может быть выгоднее нескольких отдельных транзакций, но один batch визуально имеет более высокий total fee.

Четвёртая причина — кошелёк выбрал слишком срочный target. Пользователь нажал «High priority», хотя перевод не имеет дедлайна. Здесь vsize нормальный, но fee rate дорогой. Решение — изменить target, а не UTXO.

Пятая причина — вы вообще смотрите не сетевую комиссию. Биржа может показывать собственный withdrawal fee, который не обязан равняться фактической mining fee конкретной on-chain транзакции. В кастодиальном приложении пользователь часто не выбирает inputs и sat/vB вовсе.

Шестая причина — курс BTC. Сеть измеряет fee в sat, но интерфейс переводит его в доллары или рубли. При резком росте цены BTC одинаковые 2000 sat выглядят дороже в фиате, хотя fee rate и vsize не изменились.

Диагноз занимает меньше минуты, если интерфейс прозрачен: fee rate → vsize → inputs → outputs → кто устанавливает fee. Эти пять полей отделяют сетевой рынок от структуры кошелька и комиссии сервиса.

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

Coin control: когда ручной выбор UTXO действительно помогает, а когда создаёт новый риск

Coin control позволяет указать, какие UTXO кошелёк должен использовать. Это мощный инструмент для расчёта комиссии: вы можете увидеть, как меняются vsize, change и total fee при другом наборе inputs. Но экономия — лишь одна сторона.

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

Второй сценарий — сохранить конкретный UTXO нетронутым. Например, вы разделяете рабочие средства и долгосрочное хранение. Coin control помогает не смешивать их механически в одном платеже.

Третий — подготовка крупного платежа. Предварительный просмотр нескольких наборов inputs позволяет заранее оценить, какой total fee получится при одинаковом fee rate. Главное — не подписывать тестовые варианты; сравнение делается до broadcast.

Риск №1 — приватность. Когда несколько ранее раздельных UTXO используются как inputs одной транзакции, наблюдатель может получить дополнительную связь между ними. Это не абсолютное доказательство общего владельца, но вы сами добавляете on-chain информацию.

Риск №2 — ошибка суммы и сдачи. Пользователь вручную выбирает UTXO, не замечает, что они едва покрывают payment + fee, и кошелёк вынужден добавить ещё input или изменить структуру. Всегда пересчитывайте финальный preview после coin control.

Риск №3 — неподтверждённые или небезопасные inputs. Bitcoin Core различает safe и unsafe UTXO; unconfirmed replacement и некоторые внешние неподтверждённые средства могут быть рискованными для новой транзакции. Не выбирайте input только потому, что он виден в балансе.

Если вы не можете объяснить, зачем выбран каждый input, автоматический coin selection безопаснее. Coin control нужен не для того, чтобы «обмануть комиссию», а чтобы осознанно управлять структурой, сроком и on-chain последствиями.

UTXO consolidation: когда объединение мелких выходов экономит будущие комиссии

Консолидация — это намеренная транзакция, которая тратит несколько UTXO и создаёт меньшее число новых выходов под вашим контролем. Экономический смысл возникает, когда вы делаете большую по vsize операцию в период дешёвого block space, чтобы будущий срочный платёж потребовал меньше inputs.

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

Консолидация переносит расходы во времени: вы заранее покупаете block space по более низкой ставке. Это не бесплатная оптимизация — сама consolidation transaction тоже платит fee. Выигрыш зависит от разницы между текущим и будущим fee market и от того, действительно ли объединённые UTXO понадобятся.

Не объединяйте все монеты автоматически. Такой шаг связывает ранее раздельные UTXO в одной on-chain операции и может ухудшить приватность. При этом слишком крупная consolidation в период, когда mempool внезапно дорожает, сама становится дорогой.

Практичная стратегия — наблюдать за кошельком заранее. Если у вас регулярные небольшие поступления и известны будущие крупные выплаты, рассматривайте consolidation в спокойный период. Если UTXO связаны с разными целями или идентичностями, оцените приватность до экономии.

После консолидации не нужно сразу делать второй перевод только для проверки. Дождитесь подтверждения и убедитесь, что новый UTXO доступен. Создание цепочки неподтверждённых зависимых транзакций усложняет последующий fee management.

Для бизнеса consolidation лучше включать в treasury-процесс: отслеживать количество UTXO, средний размер, прогнозируемые выплаты и текущий fee market. Тогда это становится управлением будущей стоимостью block space, а не случайной реакцией на дорогую комиссию.

И не путайте consolidation с «очисткой кошелька». Если вы объединяете монеты только ради эстетики одного баланса, экономический выигрыш может не оправдать fee и потерю приватности. У операции должна быть понятная будущая польза.

Send all и sweep: почему перевод «всего баланса» считается иначе

Команда «Send all», «Max» или sweep означает, что пользователь хочет потратить выбранный набор UTXO и отправить максимально доступную сумму после комиссии. В таком сценарии fee обычно вычитается из того, что могло бы уйти получателю, потому что отдельного дополнительного баланса для оплаты уже нет.

Bitcoin Core 31.0 в sendall работает с расходованием подтверждённых UTXO и сдачи; опция send_max может исключать inputs, стоимость расходования которых выше их полезного вклада при данной ставке. Это важная идея для кошелька с множеством крошечных UTXO: иногда экономически бессмысленно тянуть каждый sat в одну дорогую транзакцию.

Перед sweep проверяйте net amount recipient, а не только исходный balance. Если кошелёк показывает 0,01000000 BTC и fee 0,00002000 BTC, получатель при отправке всего не должен ожидать полные 0,01000000 BTC. Точный интерфейс зависит от приложения, но математика должна сходиться.

Если sweep делается на новый собственный холодный кошелёк, высокая стоимость из-за десятков UTXO может быть ожидаемой. Вы фактически закрываете множество старых outputs и создаёте новый. Это отличается от обычного платежа, где coin selection может оставить часть UTXO нетронутой.

Если среди входов есть совсем мелкие UTXO, сравните два preview: «всё» и «экономически полезные монеты». Не подписывайте ничего между сравнениями. Задача — понять, сколько сатоши вы платите за включение конкретных inputs.

С точки зрения безопасности sweep часто используется при миграции seed или кошелька. Если старый ключ скомпрометирован, экономия fee может быть менее важна, чем скорость. Если это плановая миграция, наоборот, можно дождаться низкого рынка. Одинаковая структура имеет разную оптимальную ставку в зависимости от причины.

Для обычной покупки или перевода другому человеку Max используйте осторожно: продавцу может требоваться точная сумма, а fee subtraction изменит получаемый amount. Сначала определите, кто должен получить фиксированное значение и кто несёт комиссию.

Комиссия биржи за вывод BTC и network fee — разные величины

Когда вы отправляете BTC из личного кошелька, вы видите собственную on-chain транзакцию и можете управлять fee rate, если приложение это позволяет. При выводе с централизованной биржи ситуация другая: площадка списывает внутренний баланс пользователя и сама формирует одну или несколько блокчейн-транзакций.

Биржа может установить фиксированный withdrawal fee, динамический fee, минимальную сумму вывода или субсидировать часть сетевой стоимости. Поэтому цифра в форме вывода не обязана совпадать с mining fee конкретного TxID. Платформа может батчить выплаты нескольких клиентов в одну транзакцию, а затем распределять свои издержки по собственной модели.

Это объясняет странную на первый взгляд ситуацию: реальная транзакция в explorer заплатила определённый total fee, но с вашего аккаунта списана другая комиссия. Здесь нет математической ошибки — вы сравниваете цену услуги биржи и fee блокчейн-транзакции.

Пользователь биржи обычно не выбирает UTXO, change и sat/vB hot wallet. Его реальные инструменты — сравнить withdrawal fee до подтверждения, выбрать поддерживаемый маршрут, проверить net amount и решить, выгодно ли выводить сейчас.

Не пытайтесь уменьшить биржевой withdrawal fee, посылая службе поддержки «рекомендуемую sat/vB». Инфраструктура площадки управляет собственной политикой. Если комиссия слишком велика относительно суммы, можно увеличить вывод, выбрать другой разрешённый сервис или дождаться изменения тарифа — но нельзя считать другую blockchain network эквивалентом Bitcoin только потому, что там дешевле.

Если биржа предлагает wrapped BTC в другой сети, это уже другой актив или маршрут с другим риском. Не выбирайте его только по комиссии, если цель — получить нативный BTC на Bitcoin-кошелёк.

Перед выводом сверяйте четыре числа: gross BTC, withdrawal fee, net BTC на адрес и minimum withdrawal. Для общей структуры расходов OneMagic отдельно объясняет, как считать полную комиссию криптоплатежа с учётом сервиса и сети.

RBF как страховка до отправки: что проверить, не превращая статью в инструкцию по спасению

Fee market может измениться после broadcast. Поэтому до подписи полезно знать, умеет ли ваш кошелёк повышать комиссию неподтверждённой транзакции. Это не повод специально ставить заведомо недостаточный fee, но возможность bumping снижает стоимость ошибки прогноза.

Bitcoin Core имеет механизмы повышения fee, а современная mempool policy поддерживает replacement шире старой модели явного opt-in. Однако пользовательская возможность зависит от конкретного кошелька и его интерфейса. Если приложение не даёт создать replacement, знание сетевой политики само по себе не создаёт кнопку «ускорить».

Перед важным платежом найдите в документации кошелька fee bump, increase fee или replace transaction. Лучше сделать это заранее, а не после нескольких часов ожидания. Аппаратный кошелёк может потребовать повторную подпись replacement-транзакции.

Не используйте RBF как универсальную стратегию «поставлю минимум, потом разберусь». Replacement должен заплатить больше и требует дополнительного действия. Если получателю нужен быстрый первый confirmation, сознательное занижение ставки создаёт ненужный риск.

Для несрочной транзакции наличие bumping даёт больше свободы: можно выбрать экономный target, наблюдать рынок и вмешаться только если задержка стала неприемлемой. Это уже осознанная стратегия, а не случайная экономия.

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

Если платёж уже висит, перейдите к отдельной статье OneMagic о RBF, CPFP и безопасном ускорении Bitcoin. До отправки достаточно одного вывода: знайте возможности своего кошелька и не загоняйте fee в крайность без плана B.

Batching: почему одна транзакция нескольким получателям может быть выгоднее нескольких отдельных

Если нужно отправить BTC нескольким получателям, каждый отдельный перевод создаёт собственную структуру и часто собственный change output. Batching объединяет несколько выплат в одну транзакцию с несколькими outputs. Общий total fee такой операции может выглядеть большим, но стоимость на одного получателя часто ниже, чем при серии отдельных отправок.

Экономия возникает потому, что общие служебные части и inputs не повторяются для каждой отдельной транзакции. Однако batch увеличивает vsize относительно единичного перевода, поэтому нужно оценивать total fee и cost per payment одновременно.

Для частного пользователя batching полезен редко: обычно нужно заплатить одному человеку. Для бизнеса, майнингового пула, сервиса выплат или treasury с регулярными контрагентами это отдельный инструмент оптимизации.

Есть trade-off по приватности: все recipients видны в одной транзакции и могут понять, что операция была пакетной. При этом управление сдачей и бухгалтерским сопоставлением становится сложнее. Экономия block space не автоматически означает лучший бизнес-процесс.

Batch не следует откладывать бесконечно ради минимальной комиссии. Если получателям обещан SLA, стоимость задержки важнее экономии sat. Правильная политика задаёт окна выплат, fee target и максимальную допустимую задержку.

Для расчёта используйте не «сколько outputs», а фактический vsize, который строит wallet или PSBT. Затем примените live fee rate. Если платёжная система позволяет сформировать draft без broadcast, можно сравнить batch и отдельные операции на одних и тех же входных условиях.

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

Когда Lightning рациональнее on-chain комиссии, а когда сравнение некорректно

Для небольших и частых платежей Bitcoin Lightning может быть экономически удобнее, потому что пользователь не покупает отдельное место в блоке для каждого маршрутизируемого платежа. Но Lightning и on-chain — не два тарифа одной и той же кнопки; у них разные требования, ликвидность каналов и сценарии.

Если продавец официально выставляет Lightning invoice, кошелёк показывает сумму и routing fee, а платёж укладывается в лимиты, сравнение с дорогим on-chain переводом имеет смысл. Для разового перемещения долгосрочного резерва на hardware wallet Lightning обычно не является заменой on-chain settlement.

Не отправляйте BTC «через Lightning» на обычный on-chain address и наоборот. Выбор маршрута определяется тем, какой invoice или address дал получатель и что поддерживает кошелёк.

Экономия также не бесплатна в широком смысле. Открытие и закрытие собственных каналов связано с on-chain операциями; кастодиальный Lightning-сервис добавляет counterparty risk. Пользователь должен сравнивать не только мгновенный fee, но и модель контроля.

Для покупки товара, где merchant поддерживает оба варианта, полезно сравнить: on-chain network fee, требуемое число confirmations, Lightning routing fee, срок invoice и риск custody. Для крупного необратимого перевода критерии могут быть другими.

Если цель — обычная покупка, OneMagic подробно разбирает on-chain и Lightning-платёж, invoice, подтверждения и возврат. В текущей статье Lightning важен как экономическая альтернатива, а не как способ «сделать on-chain fee нулевым».

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

Почему комиссия Bitcoin резко выросла: как реагировать до подписи

Резкий рост fee rate означает, что спрос на ближайшее block space увеличился быстрее, чем очистилась очередь. Причиной может быть массовая on-chain активность, движение рынка, крупные выводы сервисов или иной всплеск транзакций. Пользователю не обязательно знать новостную причину, чтобы принять правильное решение.

Первый вопрос — срочность. Если перевод не нужен сейчас, не соревнуйтесь с пиком только потому, что уже открыли форму Send. Закройте preview и сформируйте операцию позже, когда сможете заново проверить реквизиты и fee. До подписи и broadcast это ничего не стоит.

Второй — структура. Высокий рынок особенно болезнен для кошелька с множеством inputs. В момент пика не лучший момент для необязательной consolidation. Если payment можно собрать из меньшего набора UTXO без нежелательных последствий, preview покажет экономию.

Третий — target. Не выбирайте следующий блок для задачи «перевести до конца дня». Более длинный горизонт может снизить рекомендуемую ставку. Но не уходите ниже рынка настолько, что транзакция станет зависеть от редкого полного очищения mempool.

Четвёртый — возможность replacement. Если кошелёк умеет bump fee и задержка допустима, у вас больше пространства для экономной первоначальной ставки. Если replacement не поддерживается и дедлайн строгий, консервативный estimate может быть рациональнее.

Пятый — альтернативный способ. Для поддерживаемой merchant-оплаты Lightning может быть уместнее. Для биржевого вывода пользователь не управляет сетевой ставкой напрямую и должен сравнить тариф площадки, а не вручную выбирать sat/vB.

Не фиксируйте в заметках число «нормальная комиссия = X sat/vB». Оно быстро устаревает. Вместо этого сохраняйте процедуру: live estimate → target → vsize → total fee → решение. Процедура работает и при спокойном рынке, и во время резкого скачка.

Если рост комиссии совпал с падением или ростом цены BTC, не смешивайте две переменные. Сетевой fee формируется в sat, а фиатный эквивалент меняется ещё и из-за курса. Вы можете увидеть удорожание в долларах даже при умеренном изменении sat/vB.

Как не переплатить из-за неправильной единицы, курса или отображения кошелька

Комиссионные ошибки нередко возникают не из-за рынка, а из-за интерфейса. Одна программа показывает BTC/kvB, другая sat/vB, третья только total BTC. Перед ручным вводом ставки обязательно прочитайте единицу рядом с полем.

Сатоши и BTC отличаются в 100 миллионов раз. 10 000 sat — это 0,00010000 BTC. Если приложение отображает fee как 0,0001 BTC, это не «0,0001 sat/vB». Сначала определите, total это или rate.

Фиатная валюта добавляет ещё один слой. Кошелёк может показать «комиссия 2,50 USD», но сеть получает sat. При изменении курса BTC та же сетевой fee будет иметь другой долларовый эквивалент. Для сравнения двух fee options сначала сравнивайте sat/vB и total sat, затем переводите в фиат.

Некоторые сервисы добавляют service fee поверх network fee. Если экран показывает одну итоговую сумму, найдите breakdown. Особенно это важно в on-ramp, биржевых выводах и merchant-процессорах. Сетевая комиссия не должна становиться объяснением любой удержанной разницы.

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

Перед подписью перепишите четыре значения на бумаге или мысленно: получатель получает X BTC; fee rate Y sat/vB; vsize Z; total fee N sat. Если приложение не даёт собрать эту картину, хотя сумма значима, используйте кошелёк с более прозрачным preview.

Для понимания самой единицы sat и пересчёта BTC у OneMagic есть отдельный материал о сатоши в Bitcoin. Здесь важно не столько считать нули, сколько не перепутать единицу ставки с общей суммой.

Ещё одна проверка — decimal separator. В некоторых интерфейсах точка и запятая обрабатываются по-разному. Перед крупной суммой смотрите не только введённое поле, но и итог, который устройство предлагает подписать.

Адрес и сумма важнее идеальной комиссии: проверка безопасности на экране Send

Оптимизация fee не имеет смысла, если BTC уходят не тому получателю. Перед подписью сначала сверяйте адрес и сумму, а уже затем боритесь за несколько сотен sat экономии.

Копируйте адрес из актуального источника. После вставки сравните начало и конец, а при крупной сумме — больше символов или подтвердите адрес на доверенном устройстве. В аппаратном кошельке используйте экран самого устройства как последнюю точку проверки.

Не изменяйте адрес получателя ради уменьшения vsize. Если биржа выдала конкретный Bitcoin address, использование «более дешёвого формата» означает отправку на другой реквизит. Совместимость и контроль получателя важнее небольшого различия outputs.

Проверьте, что сумма получателю не уменьшается настройкой subtract fee. Для invoice с точной суммой это критично: транзакция может успешно подтвердиться, но merchant сочтёт заказ недоплаченным.

Смотрите на change как на нормальный механизм, но убедитесь, что кошелёк действительно контролирует его. В аппаратном или PSBT-сценарии программа должна корректно распознавать change output. Если устройство показывает дополнительный неизвестный внешний output, не подписывайте, пока не объясните его.

Не доверяйте «оптимизатору комиссии», который просит seed phrase или private key. Для оценки sat/vB достаточно публичных данных рынка и структуры транзакции; секрет нужен только для подписи, которая должна происходить в вашем кошельке.

Если вы хотите отдельно проверить корректность реквизита и устройство кошелька, используйте материал OneMagic о том, как создать Bitcoin-кошелёк и проверить адрес. Комиссия — последняя экономическая настройка перед необратимой подписью, а не первая проверка.

При копировании адреса с компьютера на телефон или аппаратный кошелёк не считайте QR-код независимой проверкой, если он создан тем же потенциально скомпрометированным устройством. Критический реквизит лучше подтверждать через доверенный канал получателя.

Практический алгоритм: как проверить комиссию Bitcoin за две минуты до Send

1. Получите свежий адрес и точную сумму. Не начинайте расчёт на старом draft, если получатель мог изменить реквизит.
2. Введите данные, но не подписывайте. Дайте кошельку сформировать preview.
3. Запишите vsize или откройте advanced details. Если размер резко выше ожидаемого, посмотрите число inputs.
4. Проверьте выбранный target. Следующий блок, несколько блоков или несрочный режим должны соответствовать реальному дедлайну.
5. Посмотрите live fee market. Сравните рекомендацию кошелька с независимым актуальным источником.
6. Сверьте fee rate. Убедитесь, что единица — sat/vB, если вы вводите ставку вручную.
7. Пересчитайте total fee. vsize × sat/vB должен объяснять порядок величины списания.
8. Проверьте outputs. Получатель должен получить точную сумму; change должен быть вашим.
9. Проверьте возможность fee bump. Для несрочной ставки полезно заранее знать план на случай роста рынка.
10. Только после этого подпишите один раз. Сохраните TxID и не создавайте дубль из-за задержки интерфейса.

Если на шаге 7 total fee слишком высок, вернитесь не к одной кнопке «ниже», а к диагнозу. Высокий rate — выберите другой target или подождите. Большой vsize — изучите inputs и coin selection. Биржевой withdrawal fee — сравнивайте тариф сервиса. Так каждое действие отвечает реальной причине.

Если перевод большой, сделайте тест только когда он действительно снижает риск ошибки адреса или нового кошелька. Тест создаёт ещё одну on-chain транзакцию и ещё одну fee. При дорогом рынке бессмысленно дробить сумму на множество «проверок» без причины.

После broadcast задача меняется: проверяйте TxID и confirmations. OneMagic отдельно показывает, как читать статус Bitcoin-транзакции по TxID. Не возвращайтесь к экрану Send и не повторяйте платёж только потому, что интерфейс получателя ещё не обновился.

Если ваш кошелёк не показывает vsize, это не означает, что расчёт невозможен. Оцените total fee и fee rate, если они доступны, или используйте более подробный режим приложения. Для значимых сумм прозрачность preview — важная характеристика самого кошелька.

Когда лучше вообще не отправлять Bitcoin сейчас

Первый случай — комиссия экономически несопоставима с задачей, а дедлайна нет. Если перевод маленький и on-chain fee съедает заметную долю суммы, пауза может быть рациональнее попытки выжать минимальную ставку из перегруженного mempool.

Второй — вы не понимаете, откуда взялся большой vsize. Скрытые десятки inputs — повод изучить UTXO, а не подписывать «потому что кошелёк так посчитал». После отправки структура фиксируется.

Третий — получатель дал неоднозначный реквизит. Если адрес пришёл в сообщении, которое могло быть скомпрометировано, никакая комиссия не компенсирует ошибку получателя. Перепроверьте канал.

Четвёртый — кошелёк не показывает итоговую сумму получателю при subtract fee или Max. Для точной оплаты нужен интерфейс, где вы видите net amount до подписи.

Пятый — вы собираетесь вручную поставить экстремально низкий fee без плана replacement и при этом обещали получателю быстрый расчёт. Такой перевод создаёт конфликт ожиданий. Либо выберите реалистичный target, либо перенесите операцию.

Шестой — вы заметили, что seed или private key просят в веб-«калькуляторе комиссии». Закройте страницу. Расчёт fee не требует передачи секретов.

Седьмой — вы выводите BTC с биржи и пытаетесь применить инструкции по sat/vB к внутренней форме withdrawal. Сначала выясните тариф площадки и net amount: именно биржа формирует on-chain транзакцию.

Восьмой — вы не уверены, что получатель поддерживает именно нативный Bitcoin, а не wrapped BTC или Lightning invoice. Уточните маршрут до расчёта fee. Выбор неправильного платёжного слоя опаснее переплаты.

Остановка до подписи — бесплатна. Это одно из ключевых преимуществ предтранзакционного контроля: пока операция не broadcast, можно изменить target, выбрать другой UTXO, дождаться более спокойного рынка или вовсе отказаться без сетевой комиссии.

Чек-лист перед отправкой: достаточно ли данных, чтобы комиссия была осознанной

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

Не стремитесь сделать fee минимально возможным любой ценой. Оптимальная комиссия — это минимальная стоимость, которая соответствует вашей цели подтверждения и допустимому риску задержки для конкретной структуры транзакции.

Для регулярных операций сохраните не конкретное число sat/vB, а этот чек-лист. В следующий раз mempool будет другим, но порядок принятия решения останется применимым.

Если один пункт меняется после обновления preview — например, кошелёк выбрал другие inputs, — повторно проверьте связанные величины. Старый расчёт комиссии относится к старой структуре и не переносится автоматически на новый draft.

Для регулярных выплат: как превратить комиссию в управляемый процесс

Если Bitcoin отправляется раз в несколько месяцев, двухминутного чек-листа достаточно. Если компания, майнер, фрилансер или treasury делает выплаты регулярно, комиссия становится операционным процессом. Здесь экономия возникает не из одного удачного sat/vB, а из дисциплины UTXO и времени отправки.

Первый показатель — количество и распределение UTXO. Накопление сотен мелких выходов создаёт будущую стоимость: каждый из них придётся когда-нибудь потратить. Полезно отслеживать не только BTC balance, но и число spendable outputs и диапазоны их номиналов.

Второй — средний vsize типовой выплаты. Если он постепенно растёт при том же числе получателей, проверьте, не изменилась ли структура inputs. Это ранний сигнал, что кошелёк фрагментируется.

Третий — политика target. Срочные клиентские выплаты и внутренние treasury-перемещения не должны автоматически использовать один и тот же режим. Для каждой категории задайте допустимое окно подтверждения и правило пересмотра fee.

Четвёртый — batching. Если выплаты можно безопасно объединять в фиксированные окна, сравните vsize batch с суммой отдельных операций. Считайте cost per recipient, а не только total fee.

Пятый — политика consolidation. Она должна учитывать fee market и приватность. Не запускайте автоматическое объединение монет только потому, что ставка «низкая по историческим меркам»; задайте условия и максимальный допустимый fee.

Шестой — контроль estimator. Сохраняйте рекомендованный rate, выбранный target и фактическое время первого confirmation для выборки операций. Со временем это покажет, насколько ваш wallet estimator соответствует реальному SLA. Не превращайте несколько случаев в статистику: нужна серия.

Седьмой — разделение service fee и network fee в учёте. Если часть выплат идёт через биржу, а часть из собственного wallet, агрегированная строка «комиссии BTC» скрывает разные причины. Разделяйте custody withdrawal charges и mining fees.

Восьмой — лимит ручных overrides. Если сотрудник может поставить любой sat/vB, нужен порог, после которого требуется повторная проверка. Ошибка единицы в корпоративном кошельке опаснее небольшого опоздания.

Девятый — тест восстановления. План fee bump должен быть проверен заранее на небольшом значимом сценарии, а не придуман во время инцидента. Убедитесь, что нужные подписанты доступны и hardware wallet поддерживает повторную подпись.

Десятый — отчётность. Для каждой значимой выплаты сохраняйте TxID, amount recipient, fee, vsize и контекст target. Эти данные позволяют объяснить расход и отличить рост рынка от изменения структуры кошелька.

Такой процесс не требует прогнозировать Bitcoin идеально. Он превращает комиссию из случайного числа в управляемый набор решений: когда отправлять, какие UTXO использовать, какой SLA покупать и как действовать при изменении рынка.

Итог: правильная комиссия Bitcoin — это не одно число, а проверяемое решение

Перед отправкой BTC у пользователя есть две независимые переменные: размер транзакции и цена виртуального байта. Vsize формируется UTXO, inputs, outputs, change и скриптами. Fee rate формируется рынком блокового пространства и вашим target по подтверждению. Итоговый fee — произведение этих факторов.

Если total fee кажется большой, сначала определите, какая сторона произведения выросла. Высокий sat/vB означает дорогую срочность или перегруженный рынок. Высокий vsize означает тяжёлую структуру. Эти причины требуют разных действий.

Не превращайте «среднюю комиссию сейчас» в тариф. Даже актуальная средняя цифра не знает ваш vsize и дедлайн. Live estimator полезен, когда вы связываете его с конкретным preview кошелька.

Не используйте coin control, consolidation и manual fee как соревнование в технической сложности. Каждый инструмент нужен только тогда, когда меняет решение: уменьшает будущий vsize, позволяет выбрать осознанный input или адаптирует target к реальной срочности.

Отдельно различайте личный wallet fee и биржевой withdrawal fee. В первом случае вы формируете транзакцию; во втором платформа продаёт услугу вывода и сама управляет on-chain структурой.

Если после отправки прогноз оказался неверным, не создавайте дубли. Откройте TxID, проверьте mempool и используйте возможности своего кошелька по fee bump. Для этого этапа есть отдельная аварийная инструкция.

Самый практичный принцип выглядит так: сначала адрес и сумма → затем inputs и vsize → затем target и live sat/vB → затем total fee → только потом подпись. Такой порядок одновременно защищает от переплаты, задержки и ошибки получателя.

Эффективная стоимость UTXO: когда монета есть в балансе, но тратить её невыгодно

Номинал UTXO и его экономическая ценность для будущего платежа — не одно и то же. Чтобы потратить выход, новая транзакция должна включить соответствующий input, а input увеличивает vsize. При высокой ставке стоимость добавления этого input может съесть заметную часть самого UTXO.

Представьте два маленьких выхода. Первый содержит 100 000 sat, второй — 500 sat. Пусть добавление конкретного input увеличивает будущий vsize на условные десятки виртуальных байтов. При дешёвом рынке оба выхода могут быть разумно расходуемыми. При очень дорогом fee market второй способен добавить к транзакции стоимость, сопоставимую с собственной суммой. Точные значения зависят от типа скрипта и ставки, поэтому здесь важен принцип, а не универсальный порог.

Именно поэтому слово dust не следует использовать как синоним «любая маленькая сумма». В Bitcoin существуют policy-ограничения на создание экономически слишком мелких outputs, но пользовательская проблема шире: выход может быть допустимым и находиться в балансе, однако быть экономически неудобным для расходования при текущем rate.

При выборе inputs хороший wallet учитывает стоимость их расходования. Bitcoin Core в современных командах работы со всем балансом также способен не включать outputs, если их ценность меньше ожидаемой стоимости добавления. Это защищает от ситуации, когда «забрать всё до последнего sat» увеличивает комиссию сильнее, чем сумму получателю.

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

Но и здесь нельзя автоматически консолидировать всё. Если рынок дорогой, попытка «почистить мелочь» сейчас фиксирует невыгодную цену. Если UTXO связаны с разными контекстами, объединение ухудшает приватность. Экономически слабый output можно оставить нетронутым до подходящего рынка или до сценария, где его использование оправдано.

Этот подход помогает объяснить ещё одну странность интерфейса: wallet balance может быть выше, чем сумма, которую функция Send Max считает рационально доступной при выбранной ставке. Это не потеря монет. Программа может исключать inputs, которые делают итог хуже. Перед выводом о проблеме сравните UTXO list, fee rate и правила конкретного кошелька.

Тестовый перевод: когда вторая комиссия оправдана, а когда это просто лишний расход

Совет «сначала отправьте маленькую сумму» полезен не всегда. В Bitcoin тест создаёт полноценную on-chain транзакцию со своим vsize и fee. Затем основной перевод платит комиссию ещё раз. При высоком рынке слепое дробление увеличивает расходы и создаёт дополнительные UTXO у получателя.

Тест оправдан, когда он проверяет новую существенную переменную: впервые используемый hardware wallet, незнакомый депозитный сервис, крупную сумму, сложную процедуру нескольких подписантов или операцию, ошибка которой будет критична. В этом случае дополнительная fee — стоимость проверки маршрута.

Тест мало полезен, если адрес получателя уже подтверждён, кошелёк давно используется, а вы просто боитесь большой цифры. Малый платёж не докажет, что основной будет иметь тот же vsize: при большей сумме wallet может выбрать другие UTXO и сформировать другой change. Поэтому копировать fee из теста в основной перевод нельзя.

Если тест делается на биржу, он должен превышать minimum deposit и учитывать правила зачисления. Слишком маленький перевод способен успешно подтвердиться on-chain, но не появиться в доступном балансе сервиса. Тогда вместо проверки вы создадите новую проблему.

После успешного теста заново откройте актуальный депозитный адрес, если сервис допускает его изменение, и сформируйте основной preview. Проверьте vsize и live sat/vB повторно. Момент между двумя транзакциями может совпасть с изменением mempool.

Если тестовый TxID ещё не подтверждён, подумайте, нужно ли создавать зависимую основную транзакцию сразу. Когда основной перевод использует change тестовой операции, появляется unconfirmed chain, а последующее управление fee становится сложнее. Для осторожного сценария дождитесь первого подтверждения.

Практическое правило: тест должен отвечать на конкретный вопрос, который нельзя достаточно надёжно проверить до подписи. Если вопроса нет, двойная комиссия не создаёт дополнительной безопасности. Сначала используйте бесплатные проверки — адрес на устройстве, preview, UTXO, vsize, target — и только затем решайте, нужна ли отдельная on-chain проба.