Gloria Zhao es desarrolladora de Bitcoin Core y autora de los BIP 331 y BIP 431. Se centra en el mempool, el almacén local de transacciones sin confirmar de cada nodo, y en las reglas para aceptarlas y retransmitirlas. Estas partes poco visibles del software determinan qué pagos conoce y comunica un nodo. Desarrollarlas exige escribir código, revisarlo cuidadosamente y buscar formas de impedir abusos.
Gloria Zhao se incorporó a Brink el 4 de enero de 2021 como su primera becaria. En 2022 se convirtió en mantenedora de Bitcoin Core, una de las personas responsables de cuidar su código fuente y su proceso de desarrollo. Se trata de trabajar en un software concreto, no de ser nombrada dirigente de Bitcoin. El apartado de antiguos participantes de Brink consultado para esta revisión la describe como antigua mantenedora. Conviene leer su biografía con las fechas presentes: una noticia sobre un nombramiento pasado no acredita el cargo que alguien ocupa hoy. [1] [2]
Un buen código necesita que otras personas lo examinen. Zhao trabajó con Bitcoin Core PR Review Club, donde los nuevos colaboradores aprenden a leer cambios propuestos y estudiar sus consecuencias. Un PR, o pull request, solicita incorporar un cambio al proyecto. El club ayuda a entender qué problema resuelve y cómo revisarlo; su objetivo principal no es conseguir que se integre un PR concreto. La discusión sirve para aprender y prepararse, no para aprobar automáticamente el código o una versión. [2] [3]
El mempool no es una única cola compartida por toda la red. Cada nodo decide qué transacciones sin confirmar acepta y retransmite, atendiendo, por ejemplo, a las comisiones y a la protección frente a la saturación. Son políticas locales, distintas de las reglas de consenso con las que se comprueba la validez de los bloques. Zhao firmó la declaración del 6 de junio de 2025 que destaca la libertad de los usuarios para elegir software. Un desarrollador puede proponer otra política, pero ni su firma ni sus permisos de mantenimiento reescriben el programa de todos los demás nodos. [4]
Una transacción puede gastar fondos de otra que aún no se ha confirmado. La anterior es su padre; la que depende de ella, su hija. El BIP 331 de Zhao propone Package Relay, la transmisión de transacciones relacionadas como un paquete. Los nodos negociarían el soporte mediante sendpackages, obtendrían primero información sobre los antecesores necesarios y después los datos de las transacciones. Así evitarían rastrear laboriosamente cada pieza que falta. El documento tiene estado Draft, es decir, borrador; su existencia no demuestra que el protocolo esté desplegado por completo en toda la red. [5]
Imagina que recibes un pago sin confirmar cuya comisión es demasiado baja. Si puedes gastar su salida, puedes crear una transacción posterior con una comisión mayor. Es CPFP, Child Pays for Parent: para cobrar la comisión de la hija, el minero debe incluir también al padre, por lo que puede evaluar ambos conjuntamente. Pero un nodo que desconoce al padre normalmente no puede aceptar a la hija por separado. El BIP 331 aborda ese obstáculo de retransmisión. Una comisión mayor no sustituye firmas y entradas válidas ni garantiza la confirmación antes de un plazo. [5]
Bitcoin Core 28.0 introdujo un procedimiento limitado de 1P1C: un padre y una hija. Mediante la comunicación P2P existente, el intercambio directo entre nodos, podía combinar transacciones adecuadas y evaluarlas juntas. Es una mejora concreta, pero no el despliegue completo del BIP 331. Las notas indican expresamente que este procedimiento de red no admite una hija con varios padres sin confirmar y todavía no es fiable ante ataques. Distinguir una función limitada de una propuesta más amplia importa al construir un monedero que depende de la retransmisión. [5] [6]
Un atacante puede aprovechar los límites del mempool para dificultar la sustitución de una transacción o el aumento de su comisión. Esto se llama pinning. La política TRUC limita las dependencias entre transacciones hasta su confirmación, facilitando evaluar su aceptación o sustitución. Bitcoin Core 28.0 la incorporó para transacciones con nVersion=3. El BIP 431 de Zhao describe este enfoque como documento informativo en estado Draft. Limitar antecesores y descendientes sin confirmar ayuda, pero la protección también depende de que otros nodos adopten la política. No garantiza impedir cualquier pinning ni la inclusión puntual en un bloque. [6] [7]
Una aplicación puede presentar un paquete a su propio nodo mediante submitpackage. La documentación de Bitcoin Core 28.0 explica que este comando, disponible en la interfaz RPC de comunicación con el nodo, comprueba tanto las reglas de consenso como la política del mempool. Las transacciones que superan los controles pueden aceptarse aunque otra parte del paquete falle. Por tanto, un error no tiene por qué deshacer todo el resultado. Hay que leer el mensaje general package_msg y cada tx-results. Incluso el éxito local no demuestra que el paquete haya llegado a toda la red ni que sus transacciones estén en un bloque. [8]
Para obtener la imagen más completa, lee esta entrada junto con Mike Hearn, Mempool, Package Relay. También enlazan con esta entrada Package Relay, Mike Hearn, Sergio Demian Lerner.