Compact block relay. Basically speeds up syncing by not downloading TXs in new blocks that you already have in your mempool. Everyone was claiming you needed everything in your mempool or you would sync slower because you'd need to download the TXs that you filtered out. Now this point was bullshit, but even this doesn't apply to your proposal.
I can see your point being somewhat useful for almost valid TXs that will be valid in a few hours, but anything more than that is not useful because you don't know the fee rate in the future.
Who is gonna find this useful? It's like setting a limit buy order for a stock in the future. If you set it too high, you will overpay, if you set it low, it's not gonna go through. You will either overpay or have a high chance of it not going through in a reasonable time frame. The further in the future, the worse this problem gets.
There's also the issue with no cost mempool spam from bad actors. Imagine if there wasn't a minimum feerate for the mempool. A bad actor could just print a billion TXs to himself to bloat the mempool. The mempool can only persist as a free public service if there's a cost to using it. Currently, in order to have the mempool store your TX, your TX needs to have a decent likelihood of paying TX fees. Even though that fee doesn't go to node runners, it is still a cost associated with taking their mempool space, it's a cost that adds up if you try to put a million TXs in the mempool. You essentially have to take a 20-50% chance of paying .25 - 1 sat/byte of mempool space you take up for 2 weeks (how long TXs stay before bring dropped). This comes out to about .25 sats/byte/month of spam. This is already cheap for any wealthy actors to spam the mempool. Now if you instead allow TXs 1 year before they are valid, you are now cheapening the cost by a factor of 26.
The mempool isn't made for long term storage. Many different aspects of its design (TTL, TX propagation, node economics, fee rate fluctuations etc.) fall apart if you try to make it useful for such purposes. You'd have to rework it completely to the point that you'd have something else entirely that doesn't resemble the mempool you know today. This could be made into an entirely separate decentralized service disconnected from bitcoin core, but it's not what the mempool is for.
Karadenizli
npub15r…t7dpl
2026-01-29 17:50:14 UTC
in reply to nevent1q…8ngv
Author Public Key
npub15r9hp5eq3a0heantnja4sth3ug277nhse9f3scu937mxfh0mpw8snt7dplPublished at
2026-01-29 17:50:14 UTCEvent JSON
{
"id": "a309e0e0623bcb2d8df0571edaf23a0c389b8c04cd6339eaabecee8522b93bcf",
"pubkey": "a0cb70d3208f5f7cf66b9cbb582ef1e215ef4ef0c9531863858fb664ddfb0b8f",
"created_at": 1769709014,
"kind": 1,
"tags": [
[
"alt",
"A short note: Compact block relay. Basically speeds up syncing b..."
],
[
"e",
"c01bcc1b49bab2d4dd5582b3267422132d14257833928d8e08e32688b13a088a",
"wss://nos.lol/",
"root",
"4f4f82846698ff66ae5fa9fad4c0c4eb7823afb07fa9f54ea9d15f1217ae96cc"
],
[
"e",
"080582bc66e72168b9f0573629b1642acf358728439ec4a7971acb1925f67d30",
"wss://relay.damus.io/",
"",
"a0cb70d3208f5f7cf66b9cbb582ef1e215ef4ef0c9531863858fb664ddfb0b8f"
],
[
"e",
"8a51ed4e219abc44a175f9d26fc5abbd3f4396c39edce335982ab0306adae556",
"wss://nos.lol/",
"reply",
"4f4f82846698ff66ae5fa9fad4c0c4eb7823afb07fa9f54ea9d15f1217ae96cc"
],
[
"p",
"a0cb70d3208f5f7cf66b9cbb582ef1e215ef4ef0c9531863858fb664ddfb0b8f",
"wss://relay.damus.io/"
],
[
"p",
"4f4f82846698ff66ae5fa9fad4c0c4eb7823afb07fa9f54ea9d15f1217ae96cc",
"wss://relay.snort.social/"
]
],
"content": "Compact block relay. Basically speeds up syncing by not downloading TXs in new blocks that you already have in your mempool. Everyone was claiming you needed everything in your mempool or you would sync slower because you'd need to download the TXs that you filtered out. Now this point was bullshit, but even this doesn't apply to your proposal. \n\nI can see your point being somewhat useful for almost valid TXs that will be valid in a few hours, but anything more than that is not useful because you don't know the fee rate in the future. \n\nWho is gonna find this useful? It's like setting a limit buy order for a stock in the future. If you set it too high, you will overpay, if you set it low, it's not gonna go through. You will either overpay or have a high chance of it not going through in a reasonable time frame. The further in the future, the worse this problem gets. \n\nThere's also the issue with no cost mempool spam from bad actors. Imagine if there wasn't a minimum feerate for the mempool. A bad actor could just print a billion TXs to himself to bloat the mempool. The mempool can only persist as a free public service if there's a cost to using it. Currently, in order to have the mempool store your TX, your TX needs to have a decent likelihood of paying TX fees. Even though that fee doesn't go to node runners, it is still a cost associated with taking their mempool space, it's a cost that adds up if you try to put a million TXs in the mempool. You essentially have to take a 20-50% chance of paying .25 - 1 sat/byte of mempool space you take up for 2 weeks (how long TXs stay before bring dropped). This comes out to about .25 sats/byte/month of spam. This is already cheap for any wealthy actors to spam the mempool. Now if you instead allow TXs 1 year before they are valid, you are now cheapening the cost by a factor of 26. \n\nThe mempool isn't made for long term storage. Many different aspects of its design (TTL, TX propagation, node economics, fee rate fluctuations etc.) fall apart if you try to make it useful for such purposes. You'd have to rework it completely to the point that you'd have something else entirely that doesn't resemble the mempool you know today. This could be made into an entirely separate decentralized service disconnected from bitcoin core, but it's not what the mempool is for. ",
"sig": "588fc2a47475a56e27dd171579bc6dfef17690575a1066442f27fc0639649d74965c06f9aace07b3df6abc6a6d02b07db1aa3be0458407829a2d8fef79ed44bb"
}