package validation: relax the package-not-child-with-unconfirmed-parents rule #31385

1. 
   glozow commented at 1:33 am on November 28, 2024: member

   Draft because builds on #31096

   On master, package rules include (1) topology needs to be child-wth-parents (2) all of the child’s unconfirmed parents need to be present. This PR relaxes the second rule. The first rule is untouched.

   Original motivation for this rule was based on the idea that we would have a child-with-unconfirmed-parents package relay protocol, and this would verify that the peer provided the “correct” package. For various reasons, we’re not planning on doing this. We could potentially do this for ancestor packages (with a similar definition that all UTXOs to make the tx valid are available in this package), but it’s also questionable whether it’s useful to enforce this.

   This rule gets in the way of certain usage of 1p1c package relay currently. If a transaction has multiple parents, of which only 1 requires a package CPFP, this rule blocks the package from relaying. Even if all the non-low-feerate parents are already in mempool, when the p2p logic submits the 1p1c package, it gets rejected for not meeting this rule.

2. rpc: Allow single transaction through submitpackage

   And under the hood suppoert single transactions
   in AcceptPackage. This simplifies user experience
   and paves the way for reducing number of codepaths
   for transaction acceptance in the future.
   
   Co-Authored-By: instagibbs <gsanders87@gmail.com>

   32fc59796f
3. relax child-with-unconfirmed-parents rule

   This rule was originally introduced along with a very early proposal for
   package relay as a way to verify that the "correct"
   child-with-unconfirmed-parents package was provided for a transaction,
   where correctness was defined as all of the transactions unconfirmed
   parents. However, we are not planning to introduce a protocol where
   peers would be asked to send these packages.
   
   This rule has downsides: if a transaction has multiple parents but only
   1 that requires package CPFP to be accepted, the current rule prevents
   us from accepting that package. Even if the other parents are already in
   mempool, the p2p logic will only submit the 1p1c package, which fails
   this check. See the test in p2p_1p1c_network.py

   dad28726c9
4. glozow added the label TX fees and policy on Nov 28, 2024
5. 
   DrahtBot commented at 1:33 am on November 28, 2024: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31385.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

6. DrahtBot added the label CI failed on Nov 28, 2024
7. 
   DrahtBot commented at 2:08 am on November 28, 2024: contributor

   🚧 At least one of the CI tasks failed. Debug: https://github.com/bitcoin/bitcoin/runs/33632131707

   Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

   • Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

   • A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

   • An intermittent issue.

   Leave a comment here, if you need help tracking down a confusing failure.

Contributors
glozow DrahtBot instagibbs

Labels
TX fees and policy CI failed