glozow

Twitter Hack Notice

I do not control the Twitter / x.com account glozow.

The email address, password, and 2fa settings on the account were changed on the morning of 2026-01-20. It appears to be a targeted social engineering attack; I have also received emails indicating attempts to change my password on other social media. The impersonator has also pretended to be me regaining access, "verified" the account, and privated it. I do not have access and have not recieved a response to my technical support ticket. Do not click on any links posted or sent to you from that account.

glozow

Emergency Replace By Feerate

Over the last 5 years, there have been many proposals of the form:

"Instead of Rule 3+4, just enforce some feerate rule for replacements when the replcement would confirm soon."

Examples:

• Always use replace by feerate
• Allow replace by feerate if the replacement would confirm "soon"
• "[PROPOSAL] Emergency RBF (BIP 125)"

glozow

Token Bucket Orphan Protection Design Document

This document describes the orphan protection scheme implemented in bitcoin/bitcoin#27742.

Orphanage Today

• When tx is missing inputs, add to orphanage and request parents
  • If any parents were rejected, don’t store in orphanage (fRejectedParents)
• On each tx acceptance
  • Orphanage tracks who provided orphan - adds it to work set
  • On peer’s next ProcessMessages(), first ProcessOrphanTx before other messages
  • 1 orphan validation (accept or reject) per turn (see bitcoin/bitcoin#26551)

glozow

Package Relay Links Collection

Linearized Reading List

"If I were starting from scratch, how would I get up to speed on what package relay and the v3 proposals are?"

1. What is policy and what are pinning attacks: Basics Talk, L2 Talk
2. What is package relay + some history: see "Background and Motivation" section of post
3. What is RBF and why is it designed the way it is: docs, code
4. BIP 331, Ancestor Package Relay: bips PR

glozow

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGIbe0UBEADJ/y3qS3g2F944+KSde7k91duiL/lhk/d6s+h07sdwyGpOi5cM
gAEcj99FuB088Z29ZfKuqHj2Zd772MMSW66RmGqvOBfniRMEE5rEOaQAN57adhT7
W93WP2HolWrtTF6s0BChi6WEp65TCPbE2C+PwbFHpgIDJfBj9XyVFbKPswktPKeW
Zpu9J7QcBuui7mUT8AxLU3n22uCVJR6KKBEfUnf2CKlyMd1MpfAfrQ86sEpZcjfv
VQPk+NgJXbJZCiGYUm5BNx1G0s2tS/faFjkaG/vmt4EC4ntU3bQfc22HYYVB4tRw
Px71GHOll7MZwleMjW83Q7fWNDnaIfUSAX6Wbhys5tswJ9VflFjZZLZFMAKkdSXV
yGheEAt4wN0VkUQzKwsNl9roqouVt8sXcF4+cFtU015SKKN/2IAelm9T3ZpkHKEQ
V/MeQI6nQPiom8UIL51TnJvb2aLASuI9q2irXxGbCgw+8k5290L+hMlXa42RwSSE

glozow

Replace by Fee Improvements

This post discusses limitations of current Bitcoin Core RBF policy and attempts to start a conversation about how we can improve it, summarizing some ideas that have been discussed. Please reply if you have any new input on issues to be solved and ideas for improvement!

Background

Please feel free to skip this section if you are already familiar

glozow

Package Mempool Accept Post

Hi there,

I'm writing to propose a set of mempool policy changes to enable package validation (in preparation for package relay) in Bitcoin Core. These would not be consensus or P2P protocol changes. However, since mempool policy significantly affects transaction propagation, I believe this is relevant for the mailing list.

My proposal enables packages consisting of multiple parents and 1 child. If you develop software that relies on specific transaction relay assumptions and/or are interested in using package relay in the future, I'm very interested to hear your feedback on the utility or restrictiveness of these package policies for your use cases.

A draft implementation of this proposal can be found in [Bitcoin Core PR#22290][1].

glozow

Mempool Witness Replacement Project

Two transactions with the same non-witness data but different witnesses have the same txid but different wtxid, and the same fee but not necessarily the same feerate. Currently, in mempool validation, if we see a transaction that has the same txid as one in the mempool, we reject it as a duplicate. This shouldn’t pose a serious security risk except in transactions where multiple parties contribute to the inputs (which is also rare and usually involves trusted or somewhat trusted parties). However, the correct behavior should be to replace mempool transactions if a new transaction has a better feerate, with some caveats to avoid DoS attacks (similar to BIP125).

Previous work and discussion:

• Antoine Riard first pointed out this issue in #19645. His implementation uses the existing mempool validation code to replace by BIP125 rules. He has indicated that he isn’t planning to return to this work in the near future (in #l2-onchain-support): https://gist.github.com/glozow/d

glozow

[2021-06-22 19:00:47] <ariard> hi
[2021-06-22 19:00:52] <glozow> hi!
[2021-06-22 19:00:54] <harding> hi
[2021-06-22 19:00:54] <suredbits> hi
[2021-06-22 19:00:58] <michaelfolkson> hi
[2021-06-22 19:01:01] <t-bast> hi!
[2021-06-22 19:01:13] <ariard> #startmeeting
[2021-06-22 19:01:22] * suredbits → Chris_Stewart_5
[2021-06-22 19:01:28] <darosior> hi
[2021-06-22 19:02:23] <ariard> will try to do a different meeting format, like sharing the question and give time to everyone to share their thoughts?

glozow

Packages

Framework / Background

The purpose of the mempool is to store the best candidates for inclusion in a block, i.e., the ones with the highest fees (including fee-bumped ones). Non-mining nodes use the mempool to make block validation faster and to aid transaction relay. If transaction relay and mempool logic are working well, all transactions paying reasonable fees should make it to miners, and all nodes with (even small) mempools should have the transactions that will be in the next blocks.

Currently, we limit the size of our mempool (default 300MB) and only validate transactions one at a time - this creates a limitation in a node's ability to determine which transactions have the highest fees, because a low fee transaction can have a high fee child.