[Feature Request] Enable CPFP via GUI

[viaj3ro]

I have more than 0.5 BTC of incoming tx that are stuck indefinitely due to low fees. CPFP is desperately needed!

Its easy to spend unconfirmed UTXOs from console with createrawtransaction,signrawtransactionwithwallet and sendrawtransaction : https://bitcoin.stackexchange.com/a/99679/

Not sure why its not possible with GUI. Also things mentioned in above link ignores specifying a fee rate for the transaction. It can be done with fundrawtransaction or manually calculate and use change address amount accordingly in createrawtransaction

[viaj3ro]

easy for some, not so easy for others. I'm reluctant to mess around with manually created raw transactions. I'd assume it's pretty easy to fuck things up and render funds inaccessible.

I'd argue this is something that is desperately needed in the GUI. So regular users and not just cli wizards with programming skills can use it. There is a constant backlog of tx since many months already and this will only get worse in the future. Without CPFP, incoming funds are basically lost indefinitely if the fee is set to low.

@viaj3ro I discussed the issue with @harding in IRC channel ##bitcoin-core-gui and looks like there won't be enough ACKs to get this option in GUI.

(harding) prayank: I mean, if we're encouraging other people to use RBF then allowing you to spend your unconfirmed coins to other people creates several problems. First, it makes it more expensive for the original sender to RBF their transaction (since they need to pay to replace both the original and all descended transactions). Second, it means that if you actually pay someone, not just CPFP back to your self, your payment will be deleted; this could end up with you thinking you paid someone and them thinking you didn't, causing problems.

Possible workarounds right now for you:

1. Use CLI: [Feature Request] Enable CPFP via GUI #242 (comment)
2. Use a different wallet: https://bitcoin.stackexchange.com/questions/102904/recovering-and-transferring-bitcoin-to-new-wallet

[viaj3ro]

Fair points.

How about only enabling CPFP with a timelock of 5 or 7 days (720/1008 blocks).

If sender hasn't bumped the fees by then, its pretty unlikely they ever will. Therefor the likelihood of conflicts with RBF become increasingly unlikely, but as a receiver I'd still be able to get my tx unstuck even if sender doesn't cooperate or the tx doesn't even have RBF enabled.

[kristapsk]

How about enabling CPFP only if original tx does not signal opt-in RBF?

[viaj3ro]

@prayank23

any chance this will receiver further considerations?

any chance this will receiver further considerations?

Maybe. I am not sure. Suggestion by @kristapsk also looks interesting.

[harding]

Sorry, I just saw this. The conversation of mine referred to in #242 (comment) seems to have been misunderstood. My first response to seeing this issue was, "GUI CPFP is a good idea". The rest of my response, including what's quoted above, was about allowing spending unconfirmed incoming payments to other people. I think it would definitely be good to allow:

• Alice pays Bob with a low fee
• Bob right clicks the unconfirmed transaction it the GUI, clicks "bump fee"
• Bob is prompted for how much fee he wants to pay
• Wallet generates a spend of the UTXO to a new address belonging to Bob

What we don't want to do is:

• Alice pays Bob with a low fee
• Bob goes to the regular Send screen, types in Carols address, and sends her the unconfirmed coins from Alice

Sorry for any confusion. Here's the full conversation:

[6:18:43 pm] <prayank> Can we change `spendzeroconfchange` to `spendzeroconfcoins` ?

[8:37:09 pm] <harding> prayank: are you suggesting just changing the
option name, or changing its behavior so that it'll spend coins received
from third parties as well as your own change?

[8:44:10 pm] <prayank> harding: name and behavior
[8:44:22 pm] <prayank> Context: https://github.com/bitcoin-core/gui/issues/242

[8:46:55 pm] <harding> Hmm.  GUI CPFP is a good idea, but I think that's
a different issue than allowing spends of other people's unconfirmed
transactions, especially if we're also encouraging ecosystem adoption of
RBF.

[9:02:38 pm] <prayank> RBF can always be used if I am sending BTC but
CPFP is the only option left if I received it with a low fee from
someone. It's already possible using CLI and other wallets so why not
GUI?

[9:05:32 pm] <harding> prayank: I mean, if we're encouraging other
people to use RBF then allowing you to spend your unconfirmed coins to
other people creates several problems.  First, it makes it more
expensive for the original sender to RBF their transaction (since they
need to pay to replace both the original and all descended
transactions).  Second, it means that if you actually pay someone, not
just CPFP back to your self, your payment will be deleted; this could
end up with you thinking you paid someone and them thinking you didn't,
causing problems.

[9:15:19 pm] <prayank> Payment will be deleted? This is something new. I
don't think I understood. So you are saying if I received 0.1 BTC from
Binance with fee rate 10 sat/vByte, didn't confirm for hours, I spent
the unconfirmed UTXO to send BTC to Bitfinex with fee rate 200
sat/vByte. Will there be an issue?

[9:19:50 pm] <harding> If Binance RBFs the 0.1 transaction, say
increasing it to 20 sat/vbyte, that changes its txid.  Your transaction
to Bitfinex now references the wrong previous txid, so it is deleted
from the mempool.  You'll need to create a new spend to Bitfinex.

[9:23:56 pm] <prayank> Yeah RBF + CPFP can have issues
[9:31:10 pm] <prayank> Maybe offtopic for this channel but sharing a
link I read last year. Thread is about receiver paying fees for a
transaction instead of sender. Interesting thought and CPFP usage in
different wallets can make it easier:
https://twitter.com/LaurentMT/status/1292100695584378883

[9:38:03 pm] <harding> I think you probably want something like payjoin
rather than CPFP for receiver-pays-fee, at least when interaction is
possible.
[9:38:55 pm] <harding> Ultimately, a merchant is going to pass on the
cost of fees to the buyer, so I'm not sure receiver-pays makes sense in
most cases.

[9:44:34 pm] <prayank> Yes also it can be exploited in few cases
mentioned by Sergej Kotliar:
https://twitter.com/ziggamon/status/1292115411761344512
[9:47:05 pm] <prayank> In few cases it can make sense. For example: A
DEX protocol which involves on-chain bitcoin transaction and two peers.
The one who is taker in this trade should pay the fees and maker should
just broadcast with 1 sat/vByte. Or maybe so many other cases that I
can't think of right now

[viaj3ro]

Ok. Thanks for the clarification! So there are basically no show stoppers for CPFP in the GUI (as long as it's just fee bumping, not forwarding unconfirmed tx)?!