This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU
And looking at https://ninjastic.space/post/65006434, he also forget to copy last part of Peter Todd's post.
Topic: Transaction expiration should be based on the most recent transaction in a group (Read 57 times)
Today at 04:10:32 AM
I won't comment about the code, but i have opinion about problem mentioned by Peter Todd.
And looking at https://ninjastic.space/post/65006434, he also forget to copy last part of Peter Todd's post.
And looking at https://ninjastic.space/post/65006434, he also forget to copy last part of Peter Todd's post.
January 30, 2025, 01:18:27 PM
This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU
- snip -im not trying to know how it came about. i want to know other peoples opinion about the code
Perhaps consider editing your initial post on this thread to indicate that this was something that Peter Todd brought up 2 days ago elsewhere (even better, also link to that source) and not an original thought of your own?
Plagiarism isn't a good look, but stating sources goes a long way toward establishing genuine curiosity.
January 30, 2025, 03:35:44 AM
This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU
well dipshit, im not trying to know how it came about. i want to know other peoples opinion about the code
January 30, 2025, 02:31:27 AM
This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU
January 29, 2025, 06:39:44 PM
Disclaimer: Peter Todd actually tested this. So there is a chance I'm
understanding the code entirely wrong. If so, feel free to make fun of
me for being too lazy to actually test this.
In BTCitcoin Core, mempool expiration is done by:
int CTxMemPool::Expire(std::chrono::seconds time)
{
AssertLockHeld(cs);
indexed_transaction_set::index::type::iterator it = mapTx.get().begin();
setEntries toremove;
while (it != mapTx.get().end() && it->GetTime() < time) {
toremove.insert(mapTx.project<0>(it));
it++;
}
setEntries stage;
for (txiter removeit : toremove) {
CalculateDescendants(removeit, stage);
}
RemoveStaged(stage, false, MemPoolRemovalReason::EXPIRY);
return stage.size();
}
This function is expiring transactions based on their entry time into
the mempool, a value that is set once and never changed. Transactions
are removed unconditionally on expiration, whether or not they have
descendents. That means that if you broadcast A, wait just prior to A's
expiration, and broadcast B, a transaction spending an output of A, B
will be evicted immediately when A's expiration time is reached.
There's at least three problems with this:
1) It's dumb. If I do a CPFP on an old transaction, I want that
transaction to get mined and am willing to pay money. It's silly to make
me jump through the hoop of rebroadcasting it again when it expires.
2) It's a free-relay DoS attack: just prior to A expiring, I could
broadcast B, a very large transaction, and use up bandwidth for "free".
Frankly, I'm not very concerned about this. But if you care, you
should fix this.
3) Expiration could maybe be leveraged in transaction cycling attacks:
https://stacker.news/items/866680
Personally, I'm not convinced that transaction expiration is actually a
good idea. The best argument for it IMO is in the case of some
soft-fork-style screwup where you're allowing stuff into your mempool
that will never get mined. But that means something is seriously wrong
to begin with - you probably should fix that. Otherwise, it's not
uncommon for transactions that are months old to eventually get mined.
Do we really need to waste bandwidth re-relaying them in the meantime?
Ref _ Peter Todd
understanding the code entirely wrong. If so, feel free to make fun of
me for being too lazy to actually test this.
In BTCitcoin Core, mempool expiration is done by:
int CTxMemPool::Expire(std::chrono::seconds time)
{
AssertLockHeld(cs);
indexed_transaction_set::index
setEntries toremove;
while (it != mapTx.get
toremove.insert(mapTx.project<0>(it));
it++;
}
setEntries stage;
for (txiter removeit : toremove) {
CalculateDescendants(removeit, stage);
}
RemoveStaged(stage, false, MemPoolRemovalReason::EXPIRY);
return stage.size();
}
This function is expiring transactions based on their entry time into
the mempool, a value that is set once and never changed. Transactions
are removed unconditionally on expiration, whether or not they have
descendents. That means that if you broadcast A, wait just prior to A's
expiration, and broadcast B, a transaction spending an output of A, B
will be evicted immediately when A's expiration time is reached.
There's at least three problems with this:
1) It's dumb. If I do a CPFP on an old transaction, I want that
transaction to get mined and am willing to pay money. It's silly to make
me jump through the hoop of rebroadcasting it again when it expires.
2) It's a free-relay DoS attack: just prior to A expiring, I could
broadcast B, a very large transaction, and use up bandwidth for "free".
Frankly, I'm not very concerned about this. But if you care, you
should fix this.
3) Expiration could maybe be leveraged in transaction cycling attacks:
https://stacker.news/items/866680
Personally, I'm not convinced that transaction expiration is actually a
good idea. The best argument for it IMO is in the case of some
soft-fork-style screwup where you're allowing stuff into your mempool
that will never get mined. But that means something is seriously wrong
to begin with - you probably should fix that. Otherwise, it's not
uncommon for transactions that are months old to eventually get mined.
Do we really need to waste bandwidth re-relaying them in the meantime?
Ref _ Peter Todd
Jump to: