Allow CPFP on unconfirmed incomming tx

[NicolaLS]

Feature request: #1208

The wallet only considers outputs with only (all) inputs controlled by the wallet or confirmed outputs as spendable. This makes CPFP impossible right now.

This has good reasons though and it should not be possible to spend unconfirmed outputs without any precautions for reasons described in this issue.

[NicolaLS]

Output never confirms/transaction is removed

• Parent gets RBFed
• Eclipse/Double spend attack
• Parent gets pruned

Right now the UX regarding unconfirmed incoming transactions is straight forward and most users know what to expect. Introducing CPFP would change the UX regarding sending (to a third-party) which is a safe operation right now.

Additionally this dynamic (spend not safe) leaks into the change output too! This has annoying implications on the UX of the wallet balance/state as well.

In case the user did not exclusively spend the unconfirmed output but also used one of the wallets (balance) outputs for the child itself there is another unsafe to spend change output created.

[NicolaLS]

RBFing the Parent

If the sender is a third-party they could decide to RBF (for example to get the change confirmed) they need to RBF with a fee which is greater than the sum of all of the children which the BBA user created, the BBA user could even 'pin' the transaction on accident. This is described here

Also the user might decide to RBF instead of CPFP for some reason and also has impacted UX here that he maybe did not anticipated when trying CPFP first (especially relevant when we implement RBF in the app).

[NicolaLS]

Maximum package size

The user can't add as many children as he wants and the fee for the n-th child needs to be higher then the one from the n-th-1 child (or parent).

This would need to be communicated to the user somehow.

[NicolaLS]

Possible solution

We can restrict the usage of unconfirmed outputs in transactions the following way:

• require all outputs are to the wallet itself and not a third-party
• only use the unconfirmed output as a single input, decreasing the new output to bump the fee
• only one child
• in case there are multiple outputs for our wallet only one CPFP transaction, no 'siblings'

This does not sound like CPFP anymore as CPFP contains these risks by definition, we make the feature less powerful to improve UX on purpose and just call it "speed up tx" instead of "CPFP tx".

Not allowing to spend to another wallet ensures that the dynamic of the receive but not spend problem in case of a e.g double spend is maintained. Only allowing to use the unconfirmed output for a single input to the child tx ensures that we do not create a unsafe to spend change output. Only allowing one child does seem a bit too restrictive but it does prevent all problems in regards to RBFing it and also its not necessary to communicate the max. package size to the user. Not allowing sibling is because sibling transactions are handled inefficiently apparently:

Also, a limitation of the current mining algorithm is that in a situation where a parent transaction has two different children trying to CPFP it (ie "sibling transactions" that each only depend on the parent, and not each other), the priority with which the parent will be mined will be at the higher of the two ancestor feerates of those children -- even though it's possible that the best feerate would be the one that includes all children taken together.
from this source.

we would also need to change allInputsOurs to also recursively check until it finds the first foreign input validating that it is confirmed (otherwise if we have a parent which is unconfirmed and cpfp to ourselves, this method would allow spending it immediately because it treats it as safe to spend change)