Gloria Zhao is a Bitcoin Core developer and author of BIP 331 and BIP 431. She focuses on the mempool, each node’s local store of unconfirmed transactions, and on the rules for accepting and forwarding them. These largely unseen parts of the software shape which payments a node learns about and passes on. Developing them involves writing code, careful review and finding ways to prevent abuse.
Gloria Zhao joined Brink on 4 January 2021 as its first fellow. In 2022 she became a Bitcoin Core maintainer, one of the people responsible for looking after its source code and development process. This is work on particular software, not an appointment to lead Bitcoin. Brink’s alumni overview consulted for this review describes her as a former maintainer. Dates matter when reading her biography: an article about a past appointment does not establish the role someone holds today. [1] [2]
Good code needs other people to examine it. Zhao worked with Bitcoin Core PR Review Club, where newer contributors learn to read proposed changes and consider their consequences. A PR, or pull request, is a request to incorporate a change into a project. The club helps people understand the problem a change addresses and how to review it; its main aim is not to get a particular PR merged. Discussion supports learning and preparation, not automatic approval of code or a release. [2] [3]
The mempool is not a single queue shared by the entire network. Each node decides which unconfirmed transactions to accept and forward, considering fees and protection against resource exhaustion, for example. These are local policies. They differ from the consensus rules used to check whether blocks are valid. Zhao signed the developers’ statement of 6 June 2025 emphasizing users’ choice of software. A developer can propose a different policy, but neither a signature nor repository maintenance access rewrites the software on everyone else’s nodes. [4]
A transaction can spend funds from another transaction that is not yet confirmed. The earlier one is its parent; a transaction depending on it is its child. Zhao’s BIP 331 proposes Package Relay, the transfer of related transactions as a package. Nodes would negotiate support through sendpackages, first obtain information about required ancestors, then download the transaction data. This would avoid laboriously tracking down every missing link. The document has Draft status: its existence does not establish full deployment of the protocol across the network. [5]
Imagine receiving an unconfirmed payment whose fee is too low. If you can spend its output, you can create a following transaction with a higher fee. This is CPFP, Child Pays for Parent: to collect the child’s fee, a miner must include its parent too, so they can be assessed together. But a node missing the parent cannot normally accept the child on its own. BIP 331 addresses this obstacle to relay. A higher fee still does not replace valid signatures and inputs, or guarantee confirmation by a deadline. [5]
Bitcoin Core 28.0 introduced a limited 1P1C procedure, meaning one parent and one child. Using existing P2P communication, the direct exchange between nodes, it could pair suitable transactions and assess them together. This is a concrete improvement, but not full BIP 331 deployment. The release notes explicitly say that this network procedure does not support a child with multiple unconfirmed parents and is not yet reliable under attack. Distinguishing a limited release feature from the broader proposal matters when building a wallet that relies on relay. [5] [6]
An attacker can exploit mempool limits to make replacing a transaction or raising its fee difficult. This is called pinning. TRUC policy restricts transaction dependencies until confirmation, making acceptance and replacement easier to assess. Bitcoin Core 28.0 introduced it for transactions with nVersion=3. Zhao’s BIP 431 describes the approach as an informational document with Draft status. Restricting unconfirmed ancestors and descendants helps, but protection also depends on other nodes adopting the policy. It is not a guarantee against every pinning attack or a promise of timely mining. [6] [7]
An application can submit a package to its own node using submitpackage. The Bitcoin Core 28.0 documentation explains that this command, available through the RPC interface for communicating with a node, checks both consensus rules and mempool policy. Transactions passing the checks may be accepted even if another part of the package fails. An error therefore need not roll back the entire package. Read both the overall package_msg and the individual tx-results. Even success at the local node does not mean the package reached the whole network or its transactions entered a block. [8]
For the clearest picture, read this entry together with Mike Hearn, Mempool, Package Relay. The reverse links also lead from Package Relay, Mike Hearn, Sergio Demian Lerner.