pull down to refresh

I wonder, given the high fee rate variability, if it would be possible for a third party to increase the fee of a transaction I have broadcasted (and I have told him so), that now is in the mempool.
Imagine a subscription model where I can pay say $1 usd (in sats) monthly to a third party, with the agreement that this party will increase my transaction fee so It will be confirmed in the next mined block. It may give certainty to some businesses for periodic transactions they make, while a third party is assuming the fee risk, just like an insurance company. Despite all the trust and privacy issues, is it possible?
There are two ways to increase the fee:
  • Replace-by-fee (RBF), where any of the UTXO inputs for the transaction can be in a replacement transaction where a fee is higher
  • Child-pays-for-parent (CPFP), where any child (i.e., an Output from the 'stuck" transaction) can then spend the unconfirmed coin and include not just enough to be sufficient for the transaction spending the child's coin but an additional amount to add incentive to get the parent transaction confirmed (as that is either a prerequisite or if not confirmed already, something that needs to occur in the same block as the child transaction).
So, by definition, if you are paying a third party, they can always do a CPFP transaction to bump the fee of the parent transaction (which is your payment to them).
reply
Thanks. So there is in fact a way to provide that service: a company offers monthly fee in exchange to redirect your periodic payments with an incresed fee (using CPFP) so final receiver gets the btc confirmed in the next block. Alice wants to send fast onchain 1 btc to Bob, so she sends 1 btc to Carol with say a fee of 1 sat/vB. Carol sends that 1 btc to Bob with a new fee of x sat/vB, being x big enough so both transactions are included in the next block. Of course there has to be a formal contract between Alice and Carol, being that Alice pays monthly to Carol for this service.
reply
Yes, CPFP enables that.
reply