-
Notifications
You must be signed in to change notification settings - Fork 281
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge bitcoin/bitcoin#31397: p2p: track and use all potential peers f…
…or orphan resolution 86d7135 [p2p] only attempt 1p1c when both txns provided by the same peer (glozow) f7658d9 [cleanup] remove p2p_inv from AddTxAnnouncement (glozow) 063c132 [functional test] getorphantxs reflects multiple announcers (glozow) 0da693f [functional test] orphan handling with multiple announcers (glozow) b6ea4a9 [p2p] try multiple peers for orphan resolution (glozow) 1d2e1d7 [refactor] move creation of unique_parents to helper function (glozow) c6893b0 [txdownload] remove unique_parents that we already have (glozow) 163aaf2 [fuzz] orphanage multiple announcer functions (glozow) 22b023b [unit test] multiple orphan announcers (glozow) 96c1a82 [unit test] TxOrphanage EraseForBlock (glozow) 04448ce [txorphanage] add GetTx so that orphan vin can be read (glozow) e810842 [txorphanage] support multiple announcers (glozow) 62a9ff1 [refactor] change type of unique_parents to Txid (glozow) 6951ddc [txrequest] GetCandidatePeers (glozow) Pull request description: Part of #27463. (Transaction) **orphan resolution** is a process that kicks off when we are missing UTXOs to validate an unconfirmed transaction. We currently request missing parents by txid; BIP 331 also defines a way to [explicitly request ancestors](https://github.com/bitcoin/bips/blob/master/bip-0331.mediawiki#handle-orphans-better). Currently, when we find that a transaction is an orphan, we only try to resolve it with the peer who provided the `tx`. If this doesn't work out (e.g. they send a `notfound` or don't respond), we do not try again. We actually can't, because we've already forgotten who else could resolve this orphan (i.e. all the other peers who announced the transaction). What is wrong with this? It makes transaction download less reliable, particularly for 1p1c packages which must go through orphan resolution in order to be downloaded. Can we fix this with BIP 331 / is this "duct tape" before the real solution? BIP 331 (receiver-initiated ancestor package relay) is also based on the idea that there is an orphan that needs resolution, but it's just a new way of communicating information. It's not inherently more honest; you can request ancestor package information and get a `notfound`. So ancestor package relay still requires some kind of procedure for retrying when an orphan resolution attempt fails. See the #27742 implementation which builds on this orphan resolution tracker to keep track of what packages to download (it just isn't rebased on this exact branch). The difference when using BIP 331 is that we request `ancpkginfo` and then `pkgtxns` instead of the parent txids. Zooming out, we'd like orphan handling to be: - Bandwidth-efficient: don't have too many requests out at once. As already implemented today, transaction requests for orphan parents and regular download both go through the `TxRequestTracker` so that we don't have duplicate requests out. - Not vulnerable to censorship: don't give up too easily, use all candidate peers. See e.g. https://bitcoincore.org/en/2024/07/03/disclose_already_asked_for/ - Load-balance between peers: don't overload peers; use all peers available. This is also useful for when we introduce per-peer orphan protection, since each peer will have limited slots. The approach taken in this PR is to think of each peer who announces an orphan as a potential "orphan resolution candidate." These candidates include: - the peer who sent us the orphan tx - any peers who announced the orphan prior to us downloading it - any peers who subsequently announce the orphan after we have started trying to resolve it For each orphan resolution candidate, we treat them as having "announced" all of the missing parents to us at the time of receipt of this orphan transaction (or at the time they announced the tx if they do so after we've already started tracking it as an orphan). We add the missing parents as entries to `m_txrequest`, incorporating the logic of typical txrequest processing, which means we prefer outbounds, try not to have duplicate requests in flight, don't overload peers, etc. ACKs for top commit: marcofleon: Code review ACK 86d7135 instagibbs: reACK 86d7135 dergoegge: Code review ACK 86d7135 mzumsande: ACK 86d7135 Tree-SHA512: 618d523b86e60c3ea039e88326d50db4e55e8e18309c6a20e8f2b10ed9e076f1de0315c335fd3b8abdabcc8b53cbceb66fb59147d05470ea25b83a2b4bd9c877
- Loading branch information
Showing
18 changed files
with
638 additions
and
174 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.