-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix orphan pool for long pending tx issues #4199
Fix orphan pool for long pending tx issues #4199
Conversation
2f1f131
to
89531c3
Compare
89531c3
to
b4c38ad
Compare
Please choose the release note for the PR. |
1e8dbe4
to
2c37b15
Compare
2c37b15
to
3653c3e
Compare
664898a
to
fb33a74
Compare
fb33a74
to
ebae19a
Compare
pub(crate) const ORPHAN_TX_EXPIRE_TIME: u64 = 2 * 48; // double block interval | ||
|
||
/// 100 max block interval | ||
pub(crate) const ORPHAN_TX_EXPIRE_TIME: u64 = 100 * MAX_BLOCK_INTERVAL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bitcoin will expire orphan tx after 20 mintues: https://github.com/bitcoin/bitcoin/blob/2a349f9ea5de9f0157cd117289996e8640473a6d/src/txorphanage.cpp#L14 which equals 2 block interval, so we use the 2 * 48 in our code. we may need to double check the impaction of increasing it to 100 block interval.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one issue with increasing it to 100 block interval is we may store more orphan tx in the pool, but we still have 100 max orphan numbers limit, so it should be ok.
on the other hand, the previous 96 seconds is too short in practice, we have observed this kind of case, so let's keep this change.
f68f7fd
to
c1134f4
Compare
c1134f4
to
8b49def
Compare
8b49def
to
83e62a0
Compare
83e62a0
to
97bdabd
Compare
What problem does this PR solve?
Project Godwoken found that some
tx
will stay inpending
for a long time. After analyzing the log(at most 4 hours), we foundtx
may unexpectedly stay inorphan pool
for the scenario transaction chain. For example,tx1 -> tx2
, aftertx1
is submittedtx2
stayed inpending
for a long time, actuallytx2
wasn't submitted intotxpool
.Problem Summary:
What is changed and how it works?
Fix the issues in
process_orphan_tx
which may forget some txs inorphan pool
. There are 3 issues this PR targeted to resolve:find_by_previous
was only returning onetx
by searching with input(because thetx
in orphan pool may have conflicts), which may cause issue when there are multiple childtx
for one parenttx
,process_orphan_tx
may can not process all of them.2 * max_block_interval
, which is96
seconds, this is too short for the delay of networking, and we didn't sendReject
to filter, which may make the node don't broadcast them later.tx
scenario, since we can not resolve all inputs inorphan pool
, we can not addReplace-by-fee
checking rules for them, so I change the code to useHashMap<OutPoint, HashSet<ProposalShortId>>
, so we don't handle the conflict inorphan pool
.What's Changed:
Related changes
owner/repo
:Check List
Tests
Side effects
Release note