Change Details

This patch limits the peer manager's orphan proof tracking since orphans are not guaranteed to have valid UTXOs nor connected nodes. Orphaned proofs usefulness varies by scenario: A) IBD - We want to collect proofs as we start to establish connections to help us build quorum. It's important to keep in mind these proofs cannot be trusted until their UTXOs are valid, so we rely on first-seen principle to admit orphans into the pool up to the limit. B) Reorg - We want to collect ALL proofs getting reorged so that we can reconcile them regardless of orphan pool limit. If we do not do this, it's trivial to force nodes to drop potentially-valid proofs during a reorg. C) Proof received before UTXO - This is an uncommon occurrence with little downside to dropping the proof, so we rely on best-effort (ie. the pool not being full). This patch implements the orphan proof pool limit in such a way that memory is reasonably bounded under all three scenarios regardless of the number/resourcing of malicious actors, with that bound being stricter for orphans received from the network.

This patch limits the peer manager's orphan proof tracking since orphans are not guaranteed to have valid UTXOs nor connected nodes. Orphaned proofs usefulness varies by scenario: A) IBD - We want to collect proofs as we start to establish connections to help us build quorum. It's important to keep in mind these proofs cannot be trusted until their UTXOs are valid, so we rely on first-seen principle to admit orphans into the pool from the network up to the limit. B) Reorg - We want to collect ALL proofs getting reorged so that we can reconcile them regardless of orphan pool limit. If we do not do this, it's trivial to force nodes to drop potentially-valid proofs during a reorg. C) Proof received before UTXO - This is an uncommon occurrence with little downside to dropping the proof, so we rely on best-effort (ie. the pool not being full). This patch implements the orphan proof pool limit in such a way that memory is reasonably bounded under all three scenarios regardless of the number/resourcing of malicious actors, with that bound being stricter for orphans received from the network. Note that these assumptions only hold well with the implementation of a UTXO age limit for proofs, which has not yet been completed. It will also be necessary to implement an expiration mechanism so that junk orphans do not sit around forever. This is work for future patches.

This patch limits the peer manager's orphan proof tracking since orphans are not guaranteed to have valid UTXOs nor connected nodes. Orphaned proofs usefulness varies by scenario: A) IBD - We want to collect proofs as we start to establish connections to help us build quorum. It's important to keep in mind these proofs cannot be trusted until their UTXOs are valid, so we rely on first-seen principle to admit orphans into the pool up to the limit. B) Reorg - We want to collect ALL proofs getting reorged so that we can reconcile them regardless of orphan pool limit. If we do not do this,us build quorum. iIt's trivial to force nodesimportant to drop potentially-validkeep in mind these proofs during a reorg.cannot be trusted until their UTXOs are valid, so we rely on first-seen principle to admit orphans into the pool from the network up to the limit. B) Reorg - We want to collect ALL proofs getting reorged so that we can reconcile them regardless of orphan pool limit. If we do not do this, it's trivial to force nodes to drop potentially-valid proofs during a reorg. C) Proof received before UTXO - This is an uncommon occurrence with little downside to dropping the proof, so we rely on best-effort (ie. the pool not being full). This patch implements the orphan proof pool limit in such a way that memory is reasonably bounded under all three scenarios regardless of the number/resourcing of malicious actors, number/resourcing of malicious actors, with that bound being stricter for orphans received from the network. Note that these assumptions only hold well with the implementation of a UTXO age limit for proofs, which has not yet been completed. It will also be necessary to implement an expiration mechanism so that junk orphans do not sit around forever. with that bound being stricter for orphans received from the networkThis is work for future patches.