Bitcoin Forum
May 14, 2024, 11:16:46 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: RPF(Replace by Fee) vs CPFP(Child pays for parent)  (Read 260 times)
sansahu92 (OP)
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
December 15, 2018, 02:55:04 PM
 #1

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.
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715685406
Hero Member
*
Offline Offline

Posts: 1715685406

View Profile Personal Message (Offline)

Ignore
1715685406
Reply with quote  #2

1715685406
Report to moderator
1715685406
Hero Member
*
Offline Offline

Posts: 1715685406

View Profile Personal Message (Offline)

Ignore
1715685406
Reply with quote  #2

1715685406
Report to moderator
1715685406
Hero Member
*
Offline Offline

Posts: 1715685406

View Profile Personal Message (Offline)

Ignore
1715685406
Reply with quote  #2

1715685406
Report to moderator
AdolfinWolf
Legendary
*
Offline Offline

Activity: 1946
Merit: 1427


View Profile
December 15, 2018, 03:31:56 PM
Last edit: December 15, 2018, 03:46:40 PM by AdolfinWolf
 #2

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.

sansahu92 (OP)
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
December 15, 2018, 04:03:38 PM
 #3

is it also possible that Alice sends an invalid transaction from his wallet?? Or broadcasting any invalid transaction in mempool?
Rath_
aka BitCryptex
Legendary
*
Offline Offline

Activity: 1876
Merit: 3131



View Profile
December 15, 2018, 04:20:51 PM
 #4

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.
Abdussamad
Legendary
*
Offline Offline

Activity: 3612
Merit: 1564



View Profile
December 15, 2018, 05:11:50 PM
 #5

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!
Thirdspace
Hero Member
*****
Offline Offline

Activity: 1232
Merit: 738


Mixing reinvented for your privacy | chipmixer.com


View Profile
December 15, 2018, 11:56:38 PM
 #6

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

buwaytress
Legendary
*
Offline Offline

Activity: 2800
Merit: 3448


Join the world-leading crypto sportsbook NOW!


View Profile
December 16, 2018, 01:05:51 PM
 #7

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.

██
██
██
██
██
██
██
██
██
██
██
██
██
... LIVECASINO.io    Play Live Games with up to 20% cashback!...██
██
██
██
██
██
██
██
██
██
██
██
██
ranochigo
Legendary
*
Offline Offline

Activity: 2968
Merit: 4186



View Profile
December 16, 2018, 02:35:46 PM
Merited by ABCbits (1)
 #8

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.

█████████████████████████
████▐██▄█████████████████
████▐██████▄▄▄███████████
████▐████▄█████▄▄████████
████▐█████▀▀▀▀▀███▄██████
████▐███▀████████████████
████▐█████████▄█████▌████
████▐██▌█████▀██████▌████
████▐██████████▀████▌████
█████▀███▄█████▄███▀█████
███████▀█████████▀███████
██████████▀███▀██████████
█████████████████████████
.
BC.GAME
▄▄░░░▄▀▀▄████████
▄▄▄
██████████████
█████░░▄▄▄▄████████
▄▄▄▄▄▄▄▄▄██▄██████▄▄▄▄████
▄███▄█▄▄██████████▄████▄████
███████████████████████████▀███
▀████▄██▄██▄░░░░▄████████████
▀▀▀█████▄▄▄███████████▀██
███████████████████▀██
███████████████████▄██
▄███████████████████▄██
█████████████████████▀██
██████████████████████▄
.
..CASINO....SPORTS....RACING..
█░░░░░░█░░░░░░█
▀███▀░░▀███▀░░▀███▀
▀░▀░░░░▀░▀░░░░▀░▀
░░░░░░░░░░░░
▀██████████
░░░░░███░░░░
░░█░░░███▄█░░░
░░██▌░░███░▀░░██▌
░█░██░░███░░░█░██
░█▀▀▀█▌░███░░█▀▀▀█▌
▄█▄░░░██▄███▄█▄░░▄██▄
▄███▄
░░░░▀██▄▀


▄▄████▄▄
▄███▀▀███▄
██████████
▀███▄░▄██▀
▄▄████▄▄░▀█▀▄██▀▄▄████▄▄
▄███▀▀▀████▄▄██▀▄███▀▀███▄
███████▄▄▀▀████▄▄▀▀███████
▀███▄▄███▀░░░▀▀████▄▄▄███▀
▀▀████▀▀████████▀▀████▀▀
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!