CPFP: Allow telling coin selector that a candidate has unconfirmed parents

[LLFourn]

I guess this is just a new field on Candidate which lets you say the combined weight and fee of all parents. I think the approach to use in practice in bdk is to roll all inputs that are in an unconfirmed tree into a single candidate. This will give you the correct answer but has the disadvantage of forcing you to spend them altogether. Needs some design work before trying to implement it. Looking at the actual CPFP related logic in core might provide some inspiration.

[murchandamus]

Unfortunately, the problem of assessing the effective feerate of a new transaction in the context of its ancestry can become fairly complex to assess. E.g. when parents have a higher feerate than the transaction to be created, they do not encumber the confirmation of the new transaction; or when a lower feerate parent transaction is already reprioritized by another child transaction, it may similarly not require a bump.

We worked on solving this problem for Bitcoin Core in bitcoin/bitcoin#27021.

[jp1ac4]

I guess this is just a new field on Candidate which lets you say the combined weight and fee of all parents.

Please note that we followed a similar approach in Liana, where we increase a candidate's weight if it has ancestors at a lower feerate:
https://github.com/wizardsardine/liana/blob/27570b4de97e7068ba79cfae1b4495d517eb6cfc/liana/src/spend.rs#L299-L330

With this approach, we ignore the more complex scenarios described above and also assume no two candidates have ancestors in common. It would be good if coin selection could check for a given selection if two candidates have ancestors in common and to consider each common ancestor transaction only once. For that, I guess it would be necessary to keep track of each ancestor txid's individual weight and fee when defining candidates.