Author

Topic: RPF(Replace by Fee) vs CPFP(Child pays for parent) (Read 283 times)

legendary
Activity: 3038
Merit: 4418
Crypto Swap Exchange
if I'm not mistaken, RBF can be done by adjusting output amount (decrease output and increase fee)
so I think you can't do RBF and send to another address at the same time
trying to send the same utxo to another address is called double spend attempt
RBF is essentially a double spend; your UTXO is double spent to initiate the RBF, whether if its to the same address or not. You can change your output to wherever you want or change the amount. What you're thinking is FSS-RBF which is not widely adopted but it was only adopted by F2Pool at one point before everyone switched to Opt-in RBF.
My Electrum experience, and assuming this works for all clients, RBF only increases the fee. Every other spend detail of the transaction is a copy of the original (receiving address, amount to be transferred, input address), except for the specified fee (and of course the tx ID itself), at least this is how all of my RBFs look like in Electrum. When I choose to RBF, only fee area is not grayed out.
Electrum would sometimes spend from another UTXO or decrease change amount if the fee is not sufficient.
legendary
Activity: 2968
Merit: 3684
Join the world-leading crypto sportsbook NOW!
if I'm not mistaken, RBF can be done by adjusting output amount (decrease output and increase fee)
so I think you can't do RBF and send to another address at the same time
trying to send the same utxo to another address is called double spend attempt

My Electrum experience, and assuming this works for all clients, RBF only increases the fee. Every other spend detail of the transaction is a copy of the original (receiving address, amount to be transferred, input address), except for the specified fee (and of course the tx ID itself), at least this is how all of my RBFs look like in Electrum. When I choose to RBF, only fee area is not grayed out.
hero member
Activity: 1232
Merit: 738
Mixing reinvented for your privacy | chipmixer.com
is it also possible that Alice sends an invalid transaction from his wallet?? Or broadcasting any invalid transaction in mempool?
an invalid transaction won't be accepted by any nodes in the network

... Of course, that transaction will not confirm very soon and Bob has doubt that Alice can do RBF and sent those bitcoins to his another address with higher transaction fees.
~
if I'm not mistaken, RBF can be done by adjusting output amount (decrease output and increase fee)
so I think you can't do RBF and send to another address at the same time
trying to send the same utxo to another address is called double spend attempt
legendary
Activity: 3682
Merit: 1580
I think the most important question here is whether Alice is a trans person since the OP keeps referring to her as 'he'?

Bob's transaction could confirm first or Alice's. It's not just about the fees.  Either transaction could be incorporated in a block first and if that block gets built on by other miners then that becomes the consensus. If both transactions were made at the same time then the chances of Bob's being incorporated are higher because he's paying a higher fee.

Only one transaction spending an input can be incorporated in the blockchain. Both Alice and Bob can't spend the same coins!
legendary
Activity: 1876
Merit: 3132
If Alice's transaction fee is worth 10x less than Bob's, it seems pretty obvious that most miners will include Bobs CPFP, even if that means also confirming the 4sat/b tx, and not Alices' RBF transaction of 50sat/b.

Keep in mind that some miners might not support CPFP since it's not compulsory so there is a chance that the RBF transaction gets confirmed faster if the next block is mined by a miner who doesn't support CPFP.

is it also possible that Alice sends an invalid transaction from his wallet?? Or broadcasting any invalid transaction in mempool?

What do you mean by "an invalid transaction"? If it doesn't comply to the rules then nodes should reject it.
newbie
Activity: 4
Merit: 0
is it also possible that Alice sends an invalid transaction from his wallet?? Or broadcasting any invalid transaction in mempool?
legendary
Activity: 1946
Merit: 1427
One would think that the 500 sat/b would automatically get added into the next block, since it has the highest fees, I'm not entirely sure however that you're also including the weight of those 3BTC from the 4sat/b in the complete picture correctly.



If Alice's transaction fee is worth 10x less than Bob's, it seems pretty obvious that most miners will include Bobs CPFP, even if that means also confirming the 4sat/b tx, and not Alices' RBF transaction of 50sat/b. (Which is also a double-spend. I'm not entirely sure how most miners react to them, but i wouldn't be surprised if some were reluctant of accepting those.)


I'm fairly certain someone can show the math behind accepting the CPFP tx vs the RBF, and the profitability of them weighed against each other.
newbie
Activity: 4
Merit: 0
I was curious to know about RBF and CPFP like example - If Alice has sent transaction worth 3 BTC to Bob with very low fees. But Alice doesn't want to confirm that transaction that's why he added very low fee 4 satoshis per byte. Of course, that transaction will not confirm very soon and Bob has doubt that Alice can do RBF and sent those bitcoins to his another address with higher transaction fees.

So Bob has already 0.012 btc in his address and he has already enabled "spent unconfirmed transaction" in his wallet(electrum) settings options. So he wants to prevent RBF by Alice. When he receives 3 bitcoins from Alice he spends those bitcoins along with his confirmed bitcoins to another address with very high fee 500 satoshis per byte fee added by Bob to another transaction immediately.

Alice also immediately uses RBF so he can get his bitcoins back with the fee of 50 satoshis per byte.

Which transaction will confirm first? If Bob's transaction gets confirmed than Alice won't get his bitcoins back. If Alice's RBF transactions get confirmed than Bob's transaction will be unconfirmed.
Jump to: