Gloria Zhao 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)"

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)

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?"

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

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

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].

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

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.

Keybase proof

I hereby claim:

I am glozow on github.
I am gloriazhao (https://keybase.io/gloriazhao) on keybase.
I have a public key ASB8B-9Q91SODP988GXIWddw_ufY86qKkEXXFMxxbVYhQgo

To claim this, I am signing this object:

	-----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

	[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?