I meant to point out that there is no way that a client can make sure that an unconfirmed transaction will ever be confirmed, even if it seems to be valid by current rules. Everybody agrees on that.?
In fact, there is no way to put a probability value on that event, even with the usual assumptions of well-distributed mining etc. Everybody still agrees?
I disagree.
If you create a transaction that spends your own outputs, then it is possible to be sure that that transaction will be included in the blockchain. You might have to pay extra fees though (assuming some miners have child pays for parent).
A rule change can make the transaction invalid and that is a reason for not making those rule changes.
I insist: you cannot be sure, because a fee hike is not the only change that might prevent confirmation. Especially if the transaction is held for months before being broadcast.
Rule changes are inevitable. They are likely to be needed to fix bugs and to meet new demands and constraints. Many rule changes have happened already, and many more are in the pipeline.
As I pointed out, if Antpool, F2Pool, and any third miner decide to impose a soft-fork change, they can do it, and no one can stop them.
Curiously, it is soft-fork changes that can prevent confirmation of signed and validated but unconfirmed transactions. Hard-fork changes (that only make rules more permissive) will not affect them.
CPFP is a mempool management rule only. If a min fee hike is implemented as a mempool management rule only, or is an individual option of each miner, then one can
hope that some miner may also implement CPFP, and then the low-fee transaction will be pulled through. But there is no way for the client to know whether some miner is doing that, so he cannot put a probability on that.
On the other hand, if the min fee is implemented as a rule change (meaning that miners are prohibited from accepting low-paying transactions) then it seems unlikely that CPFP will be implemented too. The validity rules must be verifiable "on line", meaning that the validity of a block in the blockchain can only depend on the contents of the blockchain up to and including that block. In particular, the rules cannot say "a transaction with low fee is valid if there is a transaction
further ahead in the blockchain that pays for it.
Anyway, other possible soft-fork changes that could prevent confirmation of a currently valid transaction include reduction of the block size limit (as Luke has been demanding), imposing a minimum output value (an antispam measure proposed by Charlie Lee), limtiing the number of inputs and outputs, extending the wait period for spending coinbase UTXOs, and many more