Transacción TRUC

TRUC es una política de retransmisión por la que opta un remitente al establecer en 3 la versión de una transacción, no una regla de consenso. Bitcoin Core 28.0 la convirtió en estándar conforme al BIP 431, que limita la transacción a 10.000 bytes virtuales y su transacción hija a 1.000. No será usted quien la active: el BIP 431 dirige la política a protocolos como Lightning, cuyas transacciones de compromiso se prefirman y reciben su aumento de comisión en el momento de la difusión.

Cómo funciona

TRUC consiste en seis reglas añadidas a una transacción ordinaria, y un remitente activa las seis a la vez al establecer en 3 el campo de versión.

La regla uno hace que la transacción sea reemplazable tanto si señaliza a la antigua usanza del BIP125 como si no, una distinción que esa misma versión volvió irrelevante de todos modos al adoptar por defecto el replace-by-fee completo. La regla dos hace persistente la elección: todo ancestro sin confirmar de una transacción TRUC debe ser TRUC, y todo descendiente de una transacción TRUC sin confirmar también debe serlo, de modo que nadie esquive los límites acoplando una transacción hija ordinaria, aunque las monedas confirmadas quedan exentas en ambos sentidos. La regla tres es la restricción de la que viene el nombre: un ancestro sin confirmar y un descendiente sin confirmar, sin la excepción CPFP (CPFP carve-out). La regla cuatro limita la transacción a 10.000 bytes virtuales, frente al límite de 100.000 de las reglas de transacción estándar para todo lo demás. La regla cinco limita la transacción hija a 1.000 bytes virtuales, lo que con entradas Taproot todavía deja espacio para 15 entradas y 2 salidas. La regla seis permite que la transacción quede por debajo de la comisión mínima de retransmisión del nodo, incluso en cero, siempre que el paquete que la rodea pague lo suficiente.

El motivo de todo ello es el pinning (inmovilización de la transacción): la basura de otro que vuelve imposible aumentar la comisión de una transacción propia. Las reglas de reemplazo exigen que un reemplazo pague más comisión absoluta que todo lo que desplaza, y rechazan de plano cualquier reemplazo que expulsaría más de 100 transacciones. El BIP 431 pone cifras a lo fácil que es abusar de ello. Si se quieren reemplazar cinco transacciones propias y una contraparte ha acoplado 21 descendientes a cada una, el reemplazo se rechaza solo por el recuento, pague lo que pague. Quien puede acoplar descendientes baratos a la transacción sin confirmar de otro decide cuánto le costará a ese otro su propio aumento de comisión.

El límite de 1.000 bytes virtuales para la transacción hija es la respuesta directa a eso. Con los límites de descendientes predeterminados, una transacción hija que aumenta la comisión puede ocupar ella misma 100.000 bytes virtuales, y a un satoshi por byte virtual eso supone 100.000 satoshis o más que un reemplazo debe cubrir antes de competir por sus propios méritos. Limitar la transacción hija a 1.000 reduce la cota superior en un factor de cien.

Dos mecanismos acompañan a las reglas. La expulsión entre hermanas permite que un nodo que se encuentra con una segunda hija que paga mejor expulse a la primera conforme a las reglas de reemplazo, en lugar de rechazar a la recién llegada, y como solo puede existir una hija, no hay que adivinar cuál descartar. El replace-by-fee de paquetes, que Bitcoin Core 28.0 activó para grupos conectados de tamaño dos, funciona entonces con las transacciones TRUC porque esa forma está garantizada.

Por qué importa cuando compra bitcoin

TRUC afecta al propietario corriente de bitcoin en un único momento: cuando hay que cerrar on-chain un canal Lightning y aumentar la comisión después de haber firmado la transacción.

No es al comprar cuando se nota. De las 41 reseñas de billeteras de este sitio, las que ponen un nodo Lightning real en su teléfono son aquellas en las que la política deja de ser una curiosidad. Phoenix, de ACINQ, está calificada con 4,0 en este sitio y ejecuta un nodo autónomo protegido por una frase semilla de 12 palabras, y la ruta de emergencia que documenta ACINQ consiste en forzar el cierre, esperar aproximadamente 720 bloques, alrededor de cinco días, y recuperar los fondos on-chain con una herramienta como Electrum. Ese cierre difunde una transacción de compromiso, que el BIP 431 identifica como la que se apoya en la excepción CPFP para evitar el pinning. Una transacción de compromiso que no logra entrar en un bloque antes de que expire un plazo no se queda simplemente ahí: el dinero que protegía pasa a ser reclamable por la otra parte.

La custodia traslada la exposición, y esa es la diferencia entre nuestros registros. Strike, calificado con 4,6, le permite retirar por Lightning y no añade ninguna comisión propia a las transferencias, pero mientras están en la aplicación los saldos quedan bajo custodia, así que los canales y sus cierres pertenecen a Strike. Muun, calificada con 3,8, muestra on-chain y Lightning como un solo saldo y pasa de uno a otro mediante intercambios submarinos. Cuanto más de un canal tenga usted realmente, más le incumbe un aumento de comisión fiable, y TRUC es la política escrita para proporcionarlo dentro del conjunto de nodos que la ejecutan.

Un cierre forzado de Phoenix, con y sin pinning

Un cierre forzado de Phoenix es el lugar más claro para ver a TRUC hacer su trabajo, porque la transacción que se difunde se firmó mucho antes de que nadie supiera cómo sería el mercado de comisiones.

Considere primero la configuración antigua. Su transacción de compromiso es una transacción ordinaria que no declara la versión 3 y se difunde con una transacción hija que paga por ambas. Su contraparte tiene la segunda salida ancla, que existe para que cualquiera de las dos partes pueda aumentar la comisión, y la usa para acoplar una transacción hija propia de 100.000 bytes virtuales que paga un satoshi por byte virtual. Nada de lo que hizo es inválido. La excepción CPFP le permitía colar una transacción hija adicional por encima del límite de descendientes, pero a las reglas de reemplazo eso les da igual: desplazar la transacción hija de la contraparte significa pagar los 100.000 satoshis de comisión que ya lleva antes de que su propia comisión cuente para algo, y la excepción concedía exactamente una transacción hija adicional, así que fallaba en cuanto un tercero compartía la transacción. Su cierre queda inmovilizado por pinning con una basura que a su autor casi no le costó nada.

Ahora establezca ambas transacciones en la versión 3. La transacción de compromiso puede no pagar nada en absoluto, porque la regla seis la acepta por debajo del piso de retransmisión siempre que el paquete supere el listón, que es lo que necesita una transacción firmada con meses de antelación. Solo puede existir una transacción hija, y no puede superar los 1.000 bytes virtuales, así que el peor costo que alguien puede imponerle es la centésima parte del antiguo. Si la contraparte consigue meter primero su transacción hija, la suya la expulsa pagando más. Y las dos transacciones viajan como una unidad, porque Bitcoin Core 28.0 incluyó en esa misma versión la retransmisión de paquetes de una transacción padre y una hija, con las transacciones padre TRUC admitidas por debajo de la comisión mínima de retransmisión.

La salvedad honesta es la adopción. El BIP 431 dice que el beneficio contra el pinning se limita a la mempool de cada nodo individual, y lo segura que esté su transacción depende de qué parte de la red ejecute la política. La versión 3 no era estándar antes de Bitcoin Core 28.0, así que un nodo que siga en una versión anterior no la retransmitirá en absoluto, y las notas de la versión califican esa nueva retransmisión de paquetes de limitada y todavía no fiable en condiciones adversas.

Transacción TRUC frente a número de versión de la transacción

El número de versión de la transacción es un campo que lleva toda transacción de bitcoin, y TRUC es el conjunto de reglas que ahora se obtiene con un valor concreto de ese campo.

Establecer la versión en 3 es la forma en que un remitente opta por TRUC, pero las reglas no residen en el campo. Es un indicador; todo lo que importa ocurre en el código de política de un nodo, y por eso un nodo actualizado retransmite la transacción que uno más antiguo rechaza. El consenso nunca se pronunció en ningún sentido. El BIP 431 deja constancia de que la versión 3 antes no era estándar y no tenía conflictos conocidos con usos anteriores, así que lo que cambió en Bitcoin Core 28.0 fue que pasara a ser retransmisible, no su validez.

Transacción TRUC frente a cluster mempool

Cluster mempool aplica límites de topología a todas las transacciones de la mempool de un nodo, mientras que TRUC aplica límites mucho más estrictos solo a las transacciones que los solicitan.

Los dos son trabajos relacionados, no rivales, y el BIP 431 lo dice directamente: cluster mempool limita el tamaño de los clústeres (grupos de transacciones conectadas) para todas las transacciones, no solo para las que optan por ello, y es mucho menos restrictivo que los límites de TRUC. También deja brechas que el BIP 431 menciona: cluster mempool no resuelve el pinning a través de las comisiones absolutas ni a través del número de conflictos, y es incompatible con la excepción CPFP en la que se apoyaba el diseño anterior de los canales Lightning. TRUC, la expulsión entre hermanas y el reemplazo de paquetes son la ruta que se ofrece a los protocolos que dependían de ella.