Комиссия Bitcoin: вес транзакции, vbytes и ставка
Денежный размер платежа и размер транзакции — разные величины. Перевод 30 000 сатоши может использовать один вход или десять и требовать разные данные расходования. В уроке научимся рассчитывать weight, виртуальный размер и бюджет по согласованной ставке. Это поможет объяснить, откуда берётся комиссия в плане кошелька.
Ставки в примерах выбраны для арифметики. Они не отражают текущие условия сети и не являются рекомендацией оплаты. Узел, кошелёк и измерители транзакций в этой работе не запускаются.
Базовые и общие байты
Для SegWit различают размер без данных свидетеля и полный размер соответствующего представления. Вес можно выразить как три базовых размера плюс полный размер. Эквивалентно базовые байты получают вес четыре, а дополнительные witness-байты — вес один, с учётом точных правил сериализации.
Возьмём собственный условный объект: базовый размер 100 байтов, полный размер 250. Тогда вес равен 3 × 100 + 250 = 550. Виртуальный размер для обычного объяснения получается округлением веса вверх после деления на четыре: ceil(550 / 4) = 138 vbytes.
Это модель уже измеренных размеров. В действительном кошельке структура входов и подписи определяет точные значения. Для отдельных правил политики может дополнительно учитываться стоимость операций подписи. Поэтому размер собственного файла JSON не подходит как замена сетевому измерению.
Умножение на ставку
Если согласованная ставка равна 5 сатоши за vbyte, арифметический бюджет для 138 vbytes составит 690 сатоши. При ставке 8 — 1 104. Библиотека продолжает требовать ровно 30 000 на выходе получения, а кошелёк отправителя изменяет сдачу при изменении бюджета.
| Виртуальный размер | Ставка | Бюджет |
|---|---|---|
| 138 vbytes | 5 sat/vB | 690 sat |
| 138 vbytes | 8 sat/vB | 1 104 sat |
| 220 vbytes | 5 sat/vB | 1 100 sat |
Последняя строка показывает, почему выбор большего числа входов влияет на расход. Общая цена курса не изменилась, но транзакционная структура стала крупнее. Комиссия связана с использованием ресурса блока, а не с фиксированным процентом от цены покупки.
Для учебного плана 80 000 → 30 000 + 49 300 + 700 проверяем обе величины: абсолютную комиссию 700 и эффективную ставку, полученную из фактического vsize. До завершения подписей размер может оцениваться, а после подготовки — проверяться по конкретному объекту. Приложение должно различать оценку и окончательные данные.
Округление и единицы RPC
В интерфейсах встречаются сатоши за виртуальный байт и BTC за киловиртуальный байт. Они не взаимозаменяемы как голые числа. Например, 0.00005000 BTC/kvB соответствует 5 000 сатоши на 1 000 vbytes, то есть 5 sat/vB. Ошибка масштаба может превратить ожидаемую небольшую комиссию в чрезмерный расход.
Каждый параметр читаем по справочнику конкретного RPC и версии. Нельзя переносить значение из ответа estimatesmartfee в другое поле с похожим названием, не сверив единицу. Внутренний объект приложения должен содержать единицу либо иметь строгий тип, например feeRateSatPerVbyte.
Для целочисленного денежного расчёта не используем округление к ближайшему сатоши после нескольких операций с дробными BTC. Сначала определяем точные входы, затем применяем выбранное правило ставки и округления бюджета, затем рассчитываем сдачу. Это делает порядок воспроизводимым.
Оценка не гарантирует блок
Оцениватель комиссии изучает наблюдаемую историю и условия. Его ответ связан с желаемой целью по числу блоков, однако не создаёт обязательства майнера включить транзакцию к сроку. Если данные недостаточны, ответ может не содержать ожидаемой ставки и сообщать причину.
В библиотеке интерфейс не показывает такую оценку как гарантированное время выдачи курса. Сервис принимает перевод по собственному правилу подтверждений. Отправляющий кошелёк может выбрать ставку и предоставить средства для последующего изменения комиссии, но эти действия требуют его полномочий.
Если узел находится в изолированном regtest без реалистичной истории спроса, результат оценивания может быть непоказательным. Лаборатория удобна для управления блоками и состояниями, а не для прогнозирования экономических условий основной сети. Для обучения расчёту лучше использовать явную согласованную ставку и подписать её как искусственную.
Как размер меняет выбор монет
Предположим, кошелёк выбирает между одним выходом на 80 000 и четырьмя по 20 000. Сумма одинаковая, но число входов отличается. Каждый вход добавляет сериализацию и данные разрешения. Если требуется подпись нескольких участников, размер также зависит от пути расходования.
Можно выбрать меньше входов ради текущей комиссии, но решение влияет на будущий набор выходов и приватность. Объединение нескольких поступлений связывает их в наблюдаемом графе. Поэтому простой алгоритм «всегда собрать все средства» может быть неудобен даже тогда, когда он арифметически корректен.
Отдельно оценим создание сдачи. Она добавляет новый выход и будущую стоимость его расходования. Если сдача очень мала, разумный алгоритм может предпочесть другой набор или явно включить остаток в комиссию. Нельзя принимать решение только по сумме, не замечая структуры.
Запись бюджета
Для готового плана сохраняем абсолютную комиссию, размер, единицу ставки, способ оценки и время наблюдения. В заявке подписи полезен верхний предел комиссии, который проверяется независимо от вывода кошелька. Превышение предела требует нового решения, а не молчаливого продолжения.
Если подготовленный пакет поддерживает несколько путей подписи, оценка должна назвать выбранный путь. Запас бюджета может быть полезен, но он не объясняет произвольное увеличение комиссии. Согласованная заявка сохраняет верхний предел, а подписант проверяет окончательные данные. Читатель видит сумму получения библиотеки отдельно от расхода кошелька.
Правила веса установлены в BIP 141; единицы оценивателя приведены в estimatesmartfee. После урока вы можете объяснить, почему два платежа одинаковой суммы имеют разные расходы и почему значение без единицы нельзя переносить между методами.