Respuesta Directa
Las tarifas de Bitcoin dependen del tamaño virtual de la transacción, la tasa de tarifa y la demanda cambiante de espacio en bloque, no simplemente de la cantidad enviada.
Dos pagos de Bitcoin pueden enviar la misma cantidad y pagar tarifas de red muy diferentes. La diferencia no es el valor que se transfiere. Es la transacción que la billetera tiene que construir: qué salidas no gastadas se convierten en entradas, cuántas salidas nuevas se crean, qué tipos de script están involucrados, cuántos datos serializados contiene la transacción firmada y qué tasa de tarifa aplica la billetera a ese tamaño virtual.
Por eso una billetera puede mostrar una tarifa antes de la selección de monedas y otra después de que se eligen las entradas finales. También es por eso que enviar 0.01 BTC puede costar más que enviar 1 BTC. Bitcoin no cobra un porcentaje del pago. Precia el espacio en bloque.
El cálculo sigue un camino continuo:
Entradas y salidas
→ datos de transacción serializados
→ Peso de la transacción
→ tamaño virtual en vB
→ tasa de tarifa en sat/vB
→ tarifa total en satsEntender ese camino te permite leer una vista previa de tarifa de la billetera sin confundir el monto del pago, la tasa de tarifa y la tarifa final.
La tarifa no es un porcentaje
Una tarifa de transacción de Bitcoin es la diferencia entre el valor total de sus entradas y el valor total asignado a sus salidas:
Tarifa de transacción
=
Valor total de entrada
−
Valor total de salidaSupongamos que una billetera gasta una entrada por valor de 120,000 sats. Crea una salida de pago de 100,000 sats y una salida de cambio de 18,500 sats. Los 1,500 sats restantes son la tarifa de transacción:
120,000 sats
− 100,000 sats
− 18,500 sats
= 1,500 sats de tarifaLa red no retira esa tarifa por separado de una cuenta. La tarifa es el valor de entrada que la transacción no asigna a una nueva salida.
Una billetera puede presentar varias cifras relacionadas en la misma pantalla. Describen diferentes partes de la transacción y no deben compararse sin sus unidades.
| Valor mostrado | Lo que significa | Ejemplo |
|---|---|---|
| Monto del destinatario | Bitcoin asignado a la salida del destinatario previsto | 100,000 sats |
| Tarifa total | Valor de entrada no asignado a ninguna salida | 1,500 sats |
| Tarifa por byte | Precio aplicado por byte virtual | 10 sat/vB |
| Tamaño virtual | Tamaño de transacción ponderado utilizado para comparar tarifas | 150 vB |
| Débito total de la billetera | Monto del destinatario más la tarifa cuando el remitente la paga por separado | 101,500 sats |
El monto del pago y la tarifa total se miden en sats o BTC. La tarifa se mide en sat/vB. El tamaño virtual se mide en vB. Si esas etiquetas no le resultan familiares, primero lea qué significa un satoshi en billeteras y pantallas de tarifas.
Entradas y salidas determinan el tamaño
Las entradas gastan UTXOs existentes
Las billeteras de Bitcoin no gastan desde un saldo de cuenta. Gastan salidas de transacciones no gastadas existentes, comúnmente llamadas UTXOs. Cada UTXO seleccionado se convierte en una entrada en la nueva transacción.
Una entrada identifica una salida anterior y proporciona los datos necesarios para satisfacer las condiciones de gasto de esa salida. Dependiendo del tipo de script, algunos datos de autorización aparecen en la serialización base de la transacción y otros en el witness.
Un saldo mostrado puede ocultar la estructura que importa para las tarifas. Una billetera que muestra 500,000 sats podría controlar:
- un UTXO por valor de 500,000 sats;
- cinco UTXOs por valor de 100,000 sats cada uno;
- o cincuenta UTXOs por valor de 10,000 sats cada uno.
Las tres billeteras muestran el mismo saldo total. Gastar desde ellas no crea la misma transacción. Más UTXOs seleccionados generalmente significan más entradas, y cada entrada adicional trae otro outpoint, campo de secuencia, script o datos de witness, y prefijo de longitud a la transacción serializada.
Un pago de 50,000 sats financiado por un UTXO adecuado puede, por lo tanto, ser más pequeño que el mismo pago financiado por ocho UTXOs pequeños. La selección de monedas también cambia la privacidad y el conjunto futuro de UTXOs de la billetera. Para comparar el costo de consolidar UTXOs ahora con gastarlos por separado más tarde, use la Calculadora de Consolidación de UTXOs de Bitcoin.
Salidas de destinatario y cambio
Una salida de transacción contiene un valor entero en satoshis y un script de bloqueo. El pago al destinatario es una salida. El cambio devuelto al remitente es generalmente otra.
Si una billetera selecciona un 120,000-sat UTXO para realizar un pago de 100,000-sat, normalmente no puede gastar solo una parte de ese UTXO. La nueva transacción consume la salida completa. Después de contabilizar la tarifa, el valor no utilizado regresa a una salida de cambio controlada por la billetera.
Un pago típico puede, por lo tanto, contener una o más entradas, una salida para el destinatario, una salida de cambio y campos fijos como versión y locktime. También contiene contadores de entradas y salidas, y cada entrada tiene su propio valor de secuencia.
Agregar otro destinatario agrega una salida. Agregar cambio también agrega una. Cada salida aumenta el tamaño de la transacción, aunque una entrada ordinaria de firma única generalmente agrega más tamaño virtual que una salida ordinaria.
Una billetera puede evitar el cambio cuando el valor de la entrada seleccionada coincide estrechamente con el pago más la tarifa. También puede agregar un remanente muy pequeño a la tarifa en lugar de crear una salida de cambio antieconómica. Esa decisión depende de la selección de monedas y las reglas de política de la billetera, por lo que “un pago” no es información suficiente para reproducir una tarifa.
Bytes, Weight y vSize
Las transacciones de Bitcoin se serializan en bytes. La estructura cruda incluye una versión, contador de entradas, entradas, contador de salidas, salidas y locktime. Las transacciones SegWit también incluyen un marcador, bandera y campos de testigos.
Antes de SegWit, las comparaciones de tarifas a menudo se referían directamente a los bytes de la transacción. BIP 141 introdujo el Weight de transacción para que los datos de testigos pudieran contribuir de manera diferente a los datos que no son de testigos.
BIP 141 define Weight como:
Transaction Weight
=
Base transaction size × 3
+
Total transaction sizeLa misma relación se puede escribir como:
Transaction Weight
=
Non-witness bytes × 4
+
Witness bytesUn byte que no es de testigos contribuye con cuatro unidades de Weight. Un byte de testigos contribuye con una. La ponderación más baja no hace que los datos de testigos sean gratuitos; todavía consumen Weight de bloque y aún aumentan el tamaño relevante para la tarifa.
Las billeteras y los mercados de tarifas comúnmente expresan el resultado en bytes virtuales, abreviados como vB:
vSize
=
ceil(Transaction Weight ÷ 4)La división se redondea hacia arriba a un byte virtual completo. El tamaño base, el tamaño total serializado, Weight y vSize son medidas relacionadas, pero no son intercambiables. El tamaño base excluye los datos relacionados con testigos. El tamaño total incluye la serialización completa. Weight aplica la regla de cuatro a uno. vSize convierte ese Weight en el tamaño entero utilizado para los cálculos comunes de tarifas.
sat/vB Precia la Transacción
La unidad común de tarifa de Bitcoin es satoshis por byte virtual, escrita sat/vB. Una vez que la estructura de la transacción ha producido un vSize, el cálculo simplificado de la tarifa es:
Tarifa estimada en sats
=
vSize de transacción
×
Tarifa en sat/vBLas unidades se cancelan limpiamente: los bytes virtuales multiplicados por satoshis por byte virtual dejan un número total de satoshis.
La tarifa y la tarifa total responden preguntas diferentes:
- Tarifa de comisión: cuánto paga la transacción por cada unidad de tamaño virtual.
- Tarifa total: cuántos satoshis paga la transacción completa.
Una transacción grande puede pagar una tarifa total alta a una tarifa moderada. Una transacción compacta puede pagar un total más bajo incluso a una tarifa más alta. Comparar solo la tarifa total oculta la diferencia entre el tamaño de la transacción y la urgencia del mercado de tarifas.
Una vez que se conoce la transacción firmada final, su tarifa efectiva se puede calcular a partir de la tarifa real y el vSize real:
Tarifa efectiva
=
Tarifa real en sats
÷
vSize real en vBLa tarifa efectiva puede contener un decimal aunque la tarifa de la transacción en sí sea un número entero de satoshis.
Una billetera o calculadora también puede aceptar un objetivo de tarifa decimal. La tarifa de la transacción en sí sigue resolviendo a un número entero de sats porque los valores de entrada y salida son enteros. Cuando la multiplicación produce un satoshi fraccionario, la implementación debe elegir una tarifa de satoshi completo. Redondear hacia arriba evita caer por debajo de la tarifa objetivo solicitada, lo que puede hacer que la tarifa efectiva final sea ligeramente más alta que el valor ingresado.
Un Cálculo de Tarifa Reproducible
El siguiente ejemplo modela una estructura de transacción firmada común:
- 2 entradas P2WPKH SegWit nativo;
- 1 salida de destinatario P2WPKH;
- 1 salida de cambio P2WPKH;
- Conteos CompactSize que caben cada uno en un byte;
- Firmas ECDSA serializadas de 72 bytes en el testigo;
- y una tarifa seleccionada de 12 sat/vB.
Este es un modelo técnico ilustrativo, no un registro de transacción de usuario ni una afirmación sobre una billetera específica. Las longitudes finales de las firmas ECDSA pueden variar, por lo que una billetera puede reservar un Weight máximo de entrada ligeramente diferente antes de firmar.
De la serialización a la tarifa final
Las dos entradas P2WPKH contribuyen con 41 bytes base cada una. Las dos salidas P2WPKH contribuyen con 31 bytes cada una. Los campos fijos y los conteos de entrada y salida de un byte contribuyen con otros 10 bytes base. Cada entrada modelada lleva 108 bytes de testigo: un byte de conteo de elementos de pila, un byte de longitud de firma, una firma serializada de 72 bytes, un byte de longitud de clave pública y una clave pública comprimida de 33 bytes.
| Componente | Bytes base | Bytes de testigo | Contribución de Weight |
|---|---|---|---|
| Versión, conteos y tiempo de bloqueo | 10 | 0 | 40 WU |
| Dos entradas P2WPKH | 82 | 216 | 544 WU |
| Dos salidas P2WPKH | 62 | 0 | 248 WU |
| Marcador y bandera SegWit | 0 | 2 | 2 WU |
| Total | 154 | 218 | 834 WU |
Weight
= (154 base bytes × 4) + 218 witness bytes
= 834 WU
vSize
= ceil(834 ÷ 4)
= 209 vB
Fee
= 209 vB × 12 sat/vB
= 2,508 satsCada suposición es visible. Cambie el número de entradas, el número de salidas, el tipo de script, el tamaño del testigo o la tarifa, y el resultado cambia. Para modelar tipos de entrada y salida mixtos, abra el Calculadora de tarifas de transacción de Bitcoin, ingrese la estructura mostrada por la billetera y compare la estimación con la vista previa final de la transacción.
Mismo Pago, Diferente Tarifa
Considere dos billeteras que cada una envía el mismo pago de 100,000-sat, crean una salida de cambio de P2WPKH y usan una tarifa de 12 sat/vB. La única diferencia es el número de entradas de P2WPKH.
Usando el mismo modelo de firma de 72 bytes que en el ejemplo trabajado:
| Transacción modelada | Entradas | Salidas | Weight | vSize | Tarifa a 12 sat/vB |
|---|---|---|---|---|---|
| Billetera A | 1 P2WPKH | 2 P2WPKH | 562 WU | 141 vB | 1,692 sats |
| Billetera B | 8 P2WPKH | 2 P2WPKH | 2,466 WU | 617 vB | 7,404 sats |
El destinatario recibe la misma cantidad. La tarifa es la misma. La billetera B paga más porque gasta más entradas y crea una transacción más grande.
La cantidad puede ser la misma. La estructura de la transacción no lo es.
Una estimación de tarifa que no conoce los UTXOs reales de la billetera es, por lo tanto, un escenario, no la transacción final. La billetera debe seleccionar entradas reales antes de poder determinar el tamaño y la tarifa probables.
El Tipo de Entrada Cambia el Costo
El número de entradas no es la única variable estructural. Las condiciones de gasto de las salidas seleccionadas determinan qué debe serializar cada entrada.
Los perfiles comunes de firma única incluyen Legacy P2PKH, SegWit P2SH-P2WPKH anidado, SegWit P2WPKH nativo y Taproot ruta de clave P2TR. No agregan el mismo Weight.
| Perfil de entrada común | Dónde aparecen los datos de autorización | Tamaño marginal ilustrativo | Límite importante |
|---|---|---|---|
| P2PKH | scriptSig de transacción base | Aproximadamente 148 vB | La longitud de la firma ECDSA puede variar |
| P2SH-P2WPKH | Programa de redención en scriptSig más testigo | Aproximadamente 91 vB | SegWit anidado incluye datos de envoltura |
| P2WPKH | Testigo | Aproximadamente 68 vB | La longitud de la firma ECDSA puede variar |
| Ruta de clave P2TR | Firma Schnorr única en testigo | Aproximadamente 58 vB | Un byte de sighash no predeterminado agrega un byte |
Estas cifras describen rutas de gasto de firma única comunes, no todas las transacciones posibles. Multifirma, P2WSH, rutas de script Taproot, inscripciones, scripts complejos y construcciones no estándar pueden llevar datos de testigo muy diferentes.
El tipo de salida también importa, aunque una dirección de recepción no revela el costo futuro exacto de entrada en todos los casos. Para una comparación enfocada de codificaciones de direcciones, compatibilidad y familias de scripts comunes, lea Bitcoin tipos de direcciones y sus implicaciones en la billetera.
Por qué cambian las estimaciones de la billetera
Una estimación de tarifa de la billetera puede cambiar entre el formulario de pago y la pantalla de firma, incluso cuando el monto del destinatario permanece igual. Varias decisiones de construcción de transacciones pueden seguir sin resolverse cuando aparece la primera estimación.
La selección de monedas y el cambio son provisionales
La billetera puede modelar inicialmente un recuento de entradas, luego seleccionar un conjunto diferente después de considerar el estado de confirmación, la configuración de control de monedas, las reglas de privacidad, la evitación de cambio o la necesidad de cubrir la tarifa. Una vez que se conocen las entradas, puede agregar, eliminar o cambiar el tipo de una salida de cambio.
Bitcoin Core's fundrawtransaction la documentación refleja estas elecciones: una billetera puede agregar entradas, crear como máximo una salida de cambio, seleccionar un tipo de cambio, usar una tarifa en sat/vB o restar la tarifa de las salidas especificadas. Agregar una entrada aumenta Weight. Agregar cambio aumenta el tamaño de salida. Restar la tarifa cambia el monto del destinatario. Evitar una salida de cambio pequeña puede mover el resto a la tarifa.
Las firmas y las tarifas se estiman
No se garantiza que las firmas ECDSA tengan longitudes serializadas idénticas. La documentación de financiamiento de transacciones de Bitcoin Core recomienda usar el tamaño máximo serializado de firma DER cuando se proporciona una estimación de Weight de entrada externa. Por lo tanto, una billetera puede reservar un máximo seguro antes de que existan las firmas reales.
La tarifa también puede actualizarse antes de firmar. Si la billetera recibe una estimación más reciente o el usuario cambia el objetivo de confirmación, la tarifa seleccionada de sat/vB cambia incluso cuando la estructura de la transacción no lo hace.
Estas no son discrepancias aleatorias. Una tarifa cambiada debería corresponder a un conjunto de entradas cambiado, estructura de salidas, suposición de tamaño de firma, estimación de tarifa o alguna combinación de ellos.
La demanda de la red establece la tarifa
La estructura de la transacción determina vSize. Las condiciones de la red influyen en la tarifa que una billetera elige para un objetivo de confirmación.
El espacio de bloque Bitcoin es limitado. Las transacciones no confirmadas compiten por la inclusión, y la tarifa es una de las principales señales utilizadas para comparar cuánto paga cada transacción en relación con su tamaño virtual. Una billetera puede seleccionar una tarifa más alta para un objetivo más agresivo o una tarifa más baja cuando el usuario acepta más demora.
Bitcoin Core's estimatesmartfee RPC devuelve una tarifa aproximada para que una transacción comience a confirmarse dentro de un número solicitado de bloques cuando hay datos suficientes disponibles. Utiliza el tamaño virtual de la transacción y proporciona dos modos de estimación:
- Económico responde más rápidamente a las caídas de tarifas a corto plazo y puede devolver una estimación más baja.
- Conservador utiliza un historial más largo, responde más lentamente a las caídas a corto plazo y puede devolver una estimación más alta.
Ningún modo reserva espacio de bloque. La estimación se basa en el comportamiento observado, no en una promesa de que un minero incluirá la transacción en un bloque particular.
Las billeteras, exploradores y servicios pueden usar diferentes ventanas de tiempo, vistas de mempool, márgenes de seguridad y etiquetas de objetivo. Dos interfaces pueden, por lo tanto, recomendar tarifas diferentes al mismo momento sin aplicar reglas de consenso Bitcoin diferentes.
No hay una única cola de mempool global que cada nodo vea exactamente en el mismo orden. Los nodos reciben transacciones en diferentes momentos y aplican sus propias configuraciones de política. Una estimación de billetera describe los datos disponibles para su fuente de tarifa; un minero finalmente selecciona de las transacciones y políticas disponibles para esa operación de minería.
La transacción firmada final
Antes de firmar, una billetera estima los datos de autorización requeridos para cada entrada. Después de firmar, la transacción contiene las firmas reales y las pilas de testigos. La serialización final revela el Weight real, vSize, la tarifa total y la tarifa efectiva.
Por lo tanto, la pantalla de firma debe tratarse como más autoritativa que una estimación temprana de entrada de monto. Puede revelar que la billetera seleccionó más entradas de lo esperado, agregó cambio, usó un tipo de salida diferente, produjo un tamaño de firma diferente o actualizó la tarifa antes de la autorización.
Los detalles de pago pueden ser correctos mientras la estructura de la transacción aún merece otra revisión. Verifique ambos antes de transmitir.
Cambios de tarifa después de la transmisión
La transmisión envía la transacción a los pares. No garantiza que cada nodo la acepte y la retenga, ni que aparezca en el siguiente bloque. Nuevas transacciones pueden entrar al mercado de tarifas después de la tuya, haciendo que la tarifa original sea menos competitiva.
Algunas billeteras pueden crear un reemplazo con tarifa más alta cuando una transacción no confirmada es elegible para aumentar la tarifa. El flujo de trabajo de Bitcoin Core bumpfee puede reducir el cambio o agregar entradas cuando sea necesario, lo que significa que el tamaño y la tarifa total de la transacción de reemplazo pueden diferir del original.
Lea la vista previa final de la billetera
Antes de firmar, verifique las cifras que establecen la tarifa en lugar de confiar en una sola línea de “tarifa de red”.
- Monto del destinatario: Confirme el monto asignado al destinatario previsto y si la tarifa se deduce de esa salida.
- Entradas seleccionadas: Un recuento de entradas mayor de lo esperado explica muchos aumentos de tarifa.
- Salidas y cambio: Confirme las salidas del destinatario, la salida de cambio y el destino del cambio.
- Tamaño virtual: Revise la cifra vB cuando la billetera la exponga.
- Tarifa de comisión: Distinga una tarifa en sat/vB del cargo absoluto en sats.
- Tarifa total: Confirme el total de satoshis que la transacción paga por completo.
- Objetivo de confirmación: Trátelo como una estimación y tenga en cuenta si la billetera puede aumentar la tarifa más tarde.
La verificación cruzada más útil es aritmética:
¿El vSize mostrado × sat/vB mostrado
coincide aproximadamente con la tarifa mostrada en sats?Una pequeña diferencia puede provenir de una tarifa decimal, redondeo de satoshi completo o valores mostrados redondeados. Una gran diferencia inexplicada merece otra revisión antes de firmar.
Para un contexto más amplio sobre UTXOs, confirmaciones, mineros y validación, continúe con la referencia de red y transacciones Bitcoin.
Lo que la estimación no puede garantizar
Una estimación de tarifa completa puede describir la transacción y la tarifa seleccionada. No puede garantizar:
- confirmación en el próximo bloque o en un momento exacto;
- aceptación y retención continua por cada nodo;
- demanda de red sin cambios después de que se firme la transacción;
- o que la billetera eligió las entradas más privadas y económicas o que nunca necesitará un aumento de tarifa.
La pregunta reproducible es más estrecha: dada esta estructura de transacción y esta tarifa, ¿cuántos satoshis paga la transacción? El tiempo de confirmación sigue siendo probabilístico.
Preguntas frecuentes sobre tarifas de transacción Bitcoin
¿Las tarifas de transacción de Bitcoin se basan en el monto enviado?
No. Las tarifas de transacción de Bitcoin se basan principalmente en el tamaño virtual de la transacción y la tarifa seleccionada. El monto enviado puede afectar qué UTXOs necesita una billetera, pero un pago más grande no crea automáticamente una tarifa más alta.
¿Qué significa sat/vB?
Sat/vB significa satoshis por byte virtual. Es una tarifa aplicada al tamaño virtual de una transacción. Multiplicar vSize por la tarifa da una tarifa total modelada en satoshis.
¿Por qué cambió la tarifa de mi billetera Bitcoin antes de firmar?
La billetera puede seleccionar diferentes entradas, agregar o eliminar cambio, actualizar el tipo de cambio, reservar un tamaño de firma diferente o actualizar la tarifa. Cualquiera de esos cambios puede alterar la tarifa final.
¿Por qué dos billeteras pueden cobrar tarifas diferentes por el mismo pago?
Las billeteras pueden controlar diferentes UTXOs, elegir diferentes entradas, crear diferentes salidas de cambio, usar diferentes estimaciones de tarifa o aplicar diferentes márgenes de seguridad. El monto del destinatario puede ser el mismo mientras las estructuras de transacción difieren.
¿Una tarifa más alta de Bitcoin garantiza una confirmación más rápida?
No. Una tarifa más alta puede mejorar la prioridad relativa de una transacción, pero no puede garantizar un bloque en particular. La demanda futura, la selección de mineros, la política de mempool y el descubrimiento de bloques permanecen fuera del control de la billetera.
¿Se puede aumentar una tarifa de Bitcoin después de la transmisión?
Algunas billeteras pueden crear un reemplazo con tarifa más alta cuando la transacción original es elegible para el aumento de tarifa. El reemplazo puede reducir el cambio o agregar entradas, por lo que su tamaño de transacción y tarifa total pueden cambiar.
Fuentes técnicas
Las fórmulas y los límites de construcción de transacciones en esta guía se basan en las especificaciones primarias de Bitcoin y la documentación de Bitcoin Core.
- BIP 141: Testigo segregado — define la transacción Weight, el tamaño base, el tamaño total y el tamaño virtual de la transacción.
- Referencia de transacciones para desarrolladores de Bitcoin — documenta entradas y salidas serializadas y explica que los valores de salida se registran en satoshis.
- Bitcoin Core 31.0 RPC estimatesmartfee — documenta la estimación de tarifa por objetivo de confirmación, el uso del tamaño virtual y los modos económico y conservador.
- Bitcoin Core 31.0 RPC fundrawtransaction — documenta la selección automática de entradas, la creación de cambio, la configuración de tarifa, la resta de tarifa y las suposiciones de entrada-Weight.
- Bitcoin Core 31.0 RPC bumpfee — documenta el reemplazo de tarifa de la billetera y cómo una transacción con tarifa más alta puede reducir el cambio o agregar entradas.
- BIP 341: Taproot — define las firmas de ruta de clave Taproot y el comportamiento del testigo utilizado en el modelo común de tamaño de entrada P2TR.
Fuentes
¿Encontraste un error? Reportar un problema de contenido o lee nuestro Política de Correcciones.