Skip to content

Instantly share code, notes, and snippets.

Avatar
🐒

Gloria Zhao glozow

🐒
View GitHub Profile
View package_relay_links.md
View pubkey.asc
-----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
View rbf-improvements.md

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
glozow / package_mempool_accept_post.md
Last active October 26, 2022 16:01
ML post for package policies
View package_mempool_accept_post.md

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
glozow / witness-replacement-project.md
Created July 1, 2021 17:05
Mempool Witness Replacement Project
View witness-replacement-project.md

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
View package-relay-meeting-log.txt
[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?
View packages.md

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.

@glozow
glozow / keybase.md
Last active September 30, 2020 13:02
View keybase.md

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: