Cómo calcular el tamaño de la transacción antes de enviar (Legacy Non-Segwit - P2PKH/P2SH)

Suponiendo que todas las entradas que está gastando provienen de transacciones regulares de "pago a la dirección", cada entrada contribuirá con 180 (más o menos 1) bytes a la transacción. Cada salida agrega 34 bytes a la transacción. Y hay 10 bytes adicionales fijos que siempre están presentes.

El "más o menos 1" proviene del hecho de que cada entrada necesita una firma para ser reclamada. La firma contiene dos valores de 32 bytes, pero si cualquiera de los valores tiene un primer byte de 0x80o más, tiene un 0x00byte antepuesto. Así que asumo que uno de los dos es alto y el otro es bajo. De esa manera, me equivoco como máximo en un byte por entrada.

Entonces, si su transacción tiene inentradas y outsalidas, el tamaño de la transacción, en bytes, será:

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

Por ejemplo, esta transacción tiene 40 entradas y 16 salidas. Eso nos da un tamaño de transacción de

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

es decir 7754 +- 40, bytes. El tamaño real es 7761bytes.

Si las entradas son de transacciones de "pago a clave pública", entonces las entradas son más pequeñas que para transacciones de "pago a domicilio". Y esto también será diferente para las entradas de "pago al hash de script", dependiendo de cómo/si se implementa.

Editar: esta transacción se realizó con bitcoins robados en el atraco de Linode y muestra un tamaño de transacción de 1337 , posiblemente un uso deliberado de leetspeak en la cadena de bloques.

Edit2: ahora que las claves públicas comprimidas son comunes, cada entrada es 32 bytes más corta, por lo que el tamaño de la transacción ahora es:

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

Aquí hay algunos cálculos basados ​​en la Documentación del Protocolo .

Una transacción de Bitcoin se compone de lo siguiente:

• Versión (4 bytes)
• Recuento de TxIn (1 ~ 9B)
• Para cada TxIn:
  • Punto de salida (36B)
  • Longitud del guión (1 ~ 9B)
  • ScriptSig(?)
  • Secuencia (4B)
• Recuento TxOut (1 ~ 9B)
• Para cada TxOut:
  • Valor (8B)
  • Longitud del guión (1 ~ 9B)*
  • Guion (?)*
• Tiempo de bloqueo (4B)

Suponiendo que se crea una transacción P2SH/P2PKH estándar, la longitud del script marcada con un asterisco se vinculará a 1 byte, ya que la longitud del script se codifica como un número entero variable; mientras que el tamaño del script marcado con asteriscos estará vinculado a 24 bytes, ya que solo contendrá un hash del script.

Entonces, en resumen, podemos asumir que el límite máximo de cada TxOut es de 34 bytes si estamos pagando a una dirección P2SH/P2PKH, ya que hay 4 códigos de operación en cada script de salida. Un gran desglose se puede encontrar aquí .

Suponiendo que estamos gastando puntos de salida P2PKH para nuestro TxIn. Nuestro ScriptSig (compuesto por una firma de transacción codificada DER de 72 bytes + una clave pública de 33 bytes) tendría un tamaño de 146 bytes y la longitud de nuestro script solo consumirá 1 byte, ya que el tamaño del ScriptSig es inferior a 0xFD.

Por lo tanto, una transacción P2PKH/P2SH estándar que gasta UN UTXO canjeable con un ScriptSig básico que paga solo UNA salida es de 189 bytes. De lo contrario, también podemos generalizar aún más esto a:

inmarca el número de TxIns

outmarca el número de TxOuts

Suponiendo que in< 254 y out< 254.

Tamaño de la transacción P2SH/P2PKH = in* 146 + out* 33 + 10

Calcular el tamaño de la transacción P2SH/P2PKH que se financia con entradas complejas (es decir, UTXO gastables con firmas M-de-N, contratos con bloqueo de tiempo hash) es inherentemente difícil y depende de la complejidad del script de rescate utilizado para producir el scriptHash de la transacción P2SH anterior.

Es importante comprender que la tarifa de transacción que debe pagar para realizar un pago se basa en cómo recibió los fondos que está utilizando para realizar el pago. El pago saliente (suponiendo que sea solo a un lugar) siempre será del mismo tamaño. Por lo tanto, la parte de 'salida' siempre tendrá dos scripts estándar de "pago a la dirección". El tamaño de la parte 'entrada' dependerá de la cantidad de productos que tenga que reclamar, lo que depende de cómo obtuvo los fondos.

Por lo tanto, no sugeriría cobrar la tarifa de transacción a la persona que retira, porque entonces le está facturando al usuario en función de los parámetros sobre los que el usuario no tiene control. Las tarifas de transacción dependen de cosas como la cantidad de transacciones que debe reunir para obtener las monedas necesarias. Eso depende completamente de cómo estén estructurados sus fondos.

Imagínese si entra en una tienda de dulces y le dicen que una barra de chocolate cuesta 35 centavos, pero luego, cuando lo llamaron, le agregaron una tarifa de 15 centavos. Cuando les preguntaste para qué era, te explicaron que el cliente anterior les había pagado todo en centavos, y para darte tu cambio, tendrían que contar todos esos centavos, y eso lleva más tiempo.

Creo que estaría enojado porque esa tarifa tiene que ver con cómo están estructurados sus fondos y no tiene nada que ver con su transacción. Usted esperaría que se comieran esos costos o los incorporaran a sus precios. No esperaría que calculen exactamente cuánto cuesta venderle una barra de chocolate en función de su configuración comercial interna y que le cobren personalmente en función de eso.

Cobra una tarifa fija por retiro (.01 BTC es actualmente común) o cubre las tarifas de transacción tú mismo. Y use estrategias sensatas para reducir las tarifas de transacción . Pero, en mi opinión, realmente no desea trasladar ese tipo de costo a un cliente.