[Feature Request] Enable CPFP via GUI

viaj3ro commented at 8:38 pm on March 9, 2021: none

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

hebasto added the label Feature on Mar 9, 2021

ghost commented at 7:45 am on March 13, 2021: none

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 commented at 6:47 pm on March 18, 2021: none

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.

ghost commented at 8:59 am on March 19, 2021: none

@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:

Use CLI: #242 (comment)
Use a different wallet: https://bitcoin.stackexchange.com/questions/102904/recovering-and-transferring-bitcoin-to-new-wallet

viaj3ro commented at 1:19 pm on March 23, 2021: none

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 commented at 9:56 am on April 15, 2021: contributor

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

viaj3ro commented at 6:22 pm on April 19, 2021: none

@prayank23

any chance this will receiver further considerations?

ghost commented at 6:52 pm on April 19, 2021: none

any chance this will receiver further considerations?

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

hebasto added the label UX on May 1, 2021

harding commented at 0:06 am on June 3, 2021: contributor

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:

 0[6:18:43 pm] <prayank> Can we change `spendzeroconfchange` to `spendzeroconfcoins` ?
 1
 2[8:37:09 pm] <harding> prayank: are you suggesting just changing the
 3option name, or changing its behavior so that it'll spend coins received
 4from third parties as well as your own change?
 5
 6[8:44:10 pm] <prayank> harding: name and behavior
 7[8:44:22 pm] <prayank> Context: [#242](/bitcoin-core-gui/242/)
 8
 9[8:46:55 pm] <harding> Hmm.  GUI CPFP is a good idea, but I think that's
10a different issue than allowing spends of other people's unconfirmed
11transactions, especially if we're also encouraging ecosystem adoption of
12RBF.
13
14[9:02:38 pm] <prayank> RBF can always be used if I am sending BTC but
15CPFP is the only option left if I received it with a low fee from
16someone. It's already possible using CLI and other wallets so why not
17GUI?
18
19[9:05:32 pm] <harding> prayank: I mean, if we're encouraging other
20people to use RBF then allowing you to spend your unconfirmed coins to
21other people creates several problems.  First, it makes it more
22expensive for the original sender to RBF their transaction (since they
23need to pay to replace both the original and all descended
24transactions).  Second, it means that if you actually pay someone, not
25just CPFP back to your self, your payment will be deleted; this could
26end up with you thinking you paid someone and them thinking you didn't,
27causing problems.
28
29[9:15:19 pm] <prayank> Payment will be deleted? This is something new. I
30don't think I understood. So you are saying if I received 0.1 BTC from
31Binance with fee rate 10 sat/vByte, didn't confirm for hours, I spent
32the unconfirmed UTXO to send BTC to Bitfinex with fee rate 200
33sat/vByte. Will there be an issue?
34
35[9:19:50 pm] <harding> If Binance RBFs the 0.1 transaction, say
36increasing it to 20 sat/vbyte, that changes its txid.  Your transaction
37to Bitfinex now references the wrong previous txid, so it is deleted
38from the mempool.  You'll need to create a new spend to Bitfinex.
39
40[9:23:56 pm] <prayank> Yeah RBF + CPFP can have issues
41[9:31:10 pm] <prayank> Maybe offtopic for this channel but sharing a
42link I read last year. Thread is about receiver paying fees for a
43transaction instead of sender. Interesting thought and CPFP usage in
44different wallets can make it easier:
45https://twitter.com/LaurentMT/status/1292100695584378883
46
47[9:38:03 pm] <harding> I think you probably want something like payjoin
48rather than CPFP for receiver-pays-fee, at least when interaction is
49possible.
50[9:38:55 pm] <harding> Ultimately, a merchant is going to pass on the
51cost of fees to the buyer, so I'm not sure receiver-pays makes sense in
52most cases.
53
54[9:44:34 pm] <prayank> Yes also it can be exploited in few cases
55mentioned by Sergej Kotliar:
56https://twitter.com/ziggamon/status/1292115411761344512
57[9:47:05 pm] <prayank> In few cases it can make sense. For example: A
58DEX protocol which involves on-chain bitcoin transaction and two peers.
59The one who is taker in this trade should pay the fees and maker should
60just broadcast with 1 sat/vByte. Or maybe so many other cases that I
61can't think of right now

viaj3ro commented at 3:13 pm on June 6, 2021: none

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)?!

[Feature Request] Enable CPFP via GUI #242