Как рассчитать размер транзакции перед отправкой (устаревший не-Segwit — P2PKH/P2SH)

Предполагая, что все входные данные, которые вы тратите, относятся к обычным транзакциям с оплатой по адресу, каждый ввод будет вносить в транзакцию 180 (плюс-минус 1) байтов. Каждый вывод добавляет к транзакции 34 байта. И есть фиксированные дополнительные 10 байт, которые всегда присутствуют.

«Плюс-минус 1» исходит из того факта, что для каждого ввода требуется подпись. Подпись содержит два 32-байтовых значения, но если какое-либо из значений имеет первый байт 0x80или больше, 0x00к нему добавляется байт. Поэтому я предполагаю, что один из двух высокий, а другой низкий. Таким образом, я ошибаюсь не более чем на один байт на вход.

Итак, если ваша транзакция имеет inвходы и outвыходы, размер транзакции в байтах будет:

in*180 + out*34 + 10 plus or minus 'in'

Например, эта транзакция имеет 40 входов и 16 выходов. Это дает нам размер транзакции

40*180 + 16*34 + 10 +- 40

т.е. 7754 +- 40байты. Фактический размер в 7761байтах.

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

Редактировать: эта транзакция была совершена с биткойнами, украденными в ограблении Linode, и показывает размер транзакции 1337 , возможно, преднамеренное использование leetspeak в блокчейне.

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

in*148 + out*34 + 10 plus or minus 'in'

Вот некоторые расчеты, основанные на документации протокола .

Биткойн-транзакция состоит из следующего:

• Версия (4 байта)
• Счетчик TxIn (1 ~ 9B)
• Для каждого TxIn:
  • Аутпойнт (36Б)
  • Длина сценария (1 ~ 9 байт)
  • СкриптСиг(?)
  • Последовательность (4Б)
• Счетчик TxOut (1 ~ 9B)
• Для каждого TxOut:
  • Стоимость (8B)
  • Длина сценария (1 ~ 9 байт)*
  • Скрипт (?)*
• Время блокировки (4B)

Предполагая, что создана стандартная транзакция P2SH/P2PKH, длина скрипта, отмеченная звездочкой, будет привязана к 1 байту, поскольку длина скрипта кодируется как переменное целое число; в то время как размер скрипта, отмеченный звездочками, будет привязан к 24 байтам, так как он будет содержать только хэш скрипта.

Таким образом, мы можем предположить, что максимальная граница каждого TxOut составляет 34 байта, если мы платим на адрес P2SH/P2PKH, поскольку в каждом выходном скрипте есть 4 кода операции. Большой разбивки можно найти здесь .

Предполагая, что мы тратим аутпойнты P2PKH на наш TxIn. Наш ScriptSig (состоящий из 72-байтовой подписи транзакции, закодированной DER + 33-байтового открытого ключа) будет иметь размер 146 байт, а длина нашего скрипта будет занимать только 1 байт, поскольку размер ScriptSig меньше 0xFD.

Следовательно, стандартная транзакция P2PKH/P2SH, затрачивающая ОДИН UTXO, подлежащий погашению, с базовым ScriptSig, оплачивающим только ОДИН выход, составляет 189 байт. В противном случае мы также можем дополнительно обобщить это до:

inотмечает количество TxIn

outотмечает количество TxOut

Предполагая, что in< 254 и out< 254.

Размер транзакции P2SH/P2PKH = in* 146 + out* 33 + 10

Вычисление размера транзакции P2SH/P2PKH, которая финансируется за счет сложных входных данных (т. е. UTXO, которые можно потратить с помощью M-of-N подписей, хешированных контрактов с временной блокировкой), по своей природе сложно и зависит от сложности redeemScript, используемого для создания scriptHash предыдущей транзакции P2SH.

Важно понимать, что комиссия за транзакцию, которую вы должны заплатить , зависит от того, как вы получили средства, которые используете для совершения платежа. Исходящий платеж (при условии, что он только в одно место) всегда будет одного размера. Таким образом, «исходящая» часть всегда будет иметь два стандартных сценария «оплаты по адресу». Размер «входной» части будет зависеть от того, сколько выходов вы должны получить, что зависит от того, как вы получили средства.

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

Представьте, что вы заходите в кондитерскую, и вам говорят, что шоколадка стоит 35 центов, а потом, когда вам звонят, добавляют 15 центов. Когда вы спросили их, для чего это, они объяснили, что предыдущий клиент заплатил им все копейки, и чтобы дать вам вашу сдачу, они должны были бы пересчитать все эти копейки, а это занимает больше времени.

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

Либо взимайте фиксированную комиссию за снятие средств (в настоящее время распространено 0,01 BTC), либо оплачивайте комиссию за транзакцию самостоятельно. И используйте разумные стратегии для снижения комиссий за транзакции . Но, на мой взгляд, вы действительно не хотите перекладывать такие расходы на клиента.