Package Relay permite a los nodos de Bitcoin transmitir y evaluar conjuntamente transacciones relacionadas aún sin confirmar. Resulta útil cuando la primera ofrece una comisión insuficiente y otra que gasta su salida añade lo necesario para ambas. La validez y las reglas locales del nodo siguen siendo obligatorias; evaluar un paquete no garantiza su confirmación.
Anna espera un pago en bitcoin. El remitente eligió una comisión baja y, entretanto, aumentó la demanda de espacio en los bloques. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Un nodo es un programa que verifica transacciones y bloques y se comunica con otros participantes de la red. Por eso, algunos nodos no admiten la transacción en su mempool, la colección local de operaciones sin confirmar. Anna quiere añadir una comisión mediante otra transacción. Pero esta gasta monedas cuya llegada el nodo que rechazó la primera aún desconoce. Package Relay ayuda a salvar esa dificultad: aporta el contexto necesario para no evaluar únicamente la primera transacción, de comisión baja, por separado. [1] [6]
La primera transacción se denomina padre; la que gasta su salida, hijo. Anna puede crear un hijo si satisface las condiciones para gastar una salida del padre: una cantidad concreta disponible para gastar. Podría enviar las monedas recibidas a otra dirección propia y destinar parte a la comisión. Eso es CPFP (Child Pays for Parent): la comisión mayor del hijo puede favorecer la confirmación de ambos. Package Relay ayuda a transmitirlos y evaluarlos; no paga la comisión, no firma nada ni concede acceso a monedas ajenas. [1] [5]
Supongamos un padre de 200 vB con una comisión de 200 sat y un hijo de 100 vB con 1300 sat. Un vByte (vB) mide el tamaño virtual de la transacción, usado habitualmente para calcular comisiones; un sat es una pequeña unidad de bitcoin. En total pagan 1500 sat por 300 vB: 5 sat/vB. No es la media simple de las tasas individuales de 1 y 13 sat/vB. Suponemos solo estas dos transacciones todavía no aceptadas, sin otros antecesores sin confirmar ni ajustes locales de comisión. Los nodos no vuelven a contar las ya aceptadas; importa exactamente qué dependencias se evalúan. [5] [3]
La entrada del hijo hace referencia a una salida del padre. Puede tener sentido evaluarlos juntos, pero no ignorar antecedentes que faltan. La lista coloca cada padre incluido antes de su hijo; se llama orden topológico. Las firmas y las demás reglas de validez siguen comprobándose. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. Dos transacciones que gastan las mismas monedas no se vuelven compatibles por añadir una comisión. Los límites de cantidad, tamaño y estructura del paquete también acotan el trabajo del nodo: no permiten enviar una cadena arbitrariamente larga. [5] [3] [7]
Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. La recepción significa que el nodo obtuvo los datos. La aceptación significa que incorporó las transacciones a su mempool según sus reglas. La confirmación exige incluirlas en un bloque. Cada nodo tiene su propio mempool; el éxito en uno no revela qué hizo su vecino. En Bitcoin Core 28.0, la tasa conjunta puede superar el mínimo variable de un mempool congestionado, pero no elimina en general el mínimo independiente de transmisión. Esa versión contempla una excepción para TRUC Transactions, un tipo de transacción con restricciones especiales. Por tanto, un hijo que pague mucho no rescata a cualquier padre. [2] [5] [8]
BIP 331, de Gloria Zhao, describe cómo negociar compatibilidad y solicitar información sobre antecesores y las propias transacciones. Es una propuesta más amplia. Bitcoin Core 28.0 documentó un emparejamiento limitado de un padre con un hijo mediante el protocolo de red existente. Su interfaz local de programación RPC también admitía un hijo con varios padres independientes, sin que eso implicara la misma capacidad de transmisión entre nodos. Estos detalles corresponden a esa versión; para otra, hay que revisar su documentación y las capacidades del nodo vecino. [1] [2]
El comando submitpackage de Bitcoin Core 28.0 entrega un paquete preparado al nodo local. Espera un hijo y sus padres sin confirmar, sin dependencias entre esos padres y con el hijo al final. Hay que leer package_msg junto con cada elemento de tx-results. El nodo puede aceptar parte del paquete: un error no revierte automáticamente lo ya aceptado. Incluso el éxito global no demuestra propagación por la red ni confirmación. No es un servicio general de aceleración de pagos: requiere transacciones correctamente construidas, no solo direcciones. [3]
En un entorno de pruebas separado, testmempoolaccept comprueba la aceptación sin difundir transacciones. Si otra falla, puede faltar allowed porque la transacción correspondiente no se validó por completo. La prueba y submitpackage tampoco aplican condiciones exactamente iguales. Anote versión, configuración, dependencias, tamaños y comisiones, y observe por separado la aceptación en otro nodo. Las transacciones de Lightning Network con plazos siguen exigiendo actuar a tiempo: Package Relay por sí solo no elimina la congestión, los intervalos irregulares entre bloques ni el pinning, que utiliza deliberadamente las reglas del mempool para dificultar subir la comisión. [4] [2] [1]
Para obtener la imagen más completa, lee esta entrada junto con Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. También enlazan con esta entrada CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.