 Can you explain the difference between replace by fee and child pays for parent? What are the use cases? Becker this is a great question. Replace by fee or RBF and child pays for parent or CPFP are two mechanisms used to bump the fee of a transaction in bitcoin when that transaction has due to demand for blockchain space become stuck. Effectively it's not getting mined into a block. You've made a transaction but it's not getting mined into a block because it doesn't have sufficient fee. So what do you do? Well there are two ways to bump the fee. One requires some proactive activity. The other one can be done in a more flexible way. Replace by fee is a flag that is set in your transaction when you send it that tells everybody this transaction may get replaced by another transaction that has a higher fee. Now what that means is that this transaction is even less trustworthy under zero confirmation conditions. Not really because you can do that by double spending a transaction anyway. What it means is primarily that the transaction ID may change. So if more fee is added to replace by fee transaction one of the most obvious things that happens is the transaction ID changes and so if you're looking at that transaction at a block explorer you might see it marked as double spent and that's because hopefully the sender replaced it with the transaction paying higher fee. Let me break this down for you. RBF is something the sender of a transaction does and says this transaction is currently paying a fee but in the future I will want to have the option to increase that fee if my transaction is not confirmed in the time frame I want. Now in my wallets all transactions I make are RBF meaning that every transaction I make with one of my wallets has the RBF flag on it and it's basically saying I'm trying to be a cheap ass here I'm going to go in with the lowest fee I think will make it and if I find out in an hour or two hours or three hours that it's still not confirmed or if it gets to a point where I really need it to be confirmed a bit more urgently I'm going to come back and I'm going to bump this fee up so that I can get it confirmed but I'm not going to overpay in advance because I'm a cheap ass so one Satoshi per byte is all you get all of my transactions RBF on one Satoshi per byte and then just hope for the best sometimes it works sometimes it doesn't Child phase for parent is interesting because it's a slightly different formulation and has different characteristics. Child phase for parent is something the recipient or the sender can do to get a stuck transaction confirmed mined into the next block now where RBF can only be done by the sender child pays for parent can be done by the sender or the recipient or under some circumstances with anchor payments by any third party and we'll talk a bit about that in a second all right so what does child pay for parent do it takes advantage of a mining policy where transactions are not considered in isolation but they are considered as packages especially when there is a parent transaction and one of its outputs is being spent by a child's transaction and both of those transactions have yet to be confirmed they're sitting in the mempool so when you look at transactions in the mempool they might just be isolated transactions or they might be chains of transactions where you have one transaction some of its change is then spent or some of its outputs are being spent by another transaction and another transaction and another transaction in a chain and this chain needs to be confirmed altogether you can't confirm one of the children until the parents have been confirmed they're all waiting in the mempool now the interesting thing here is that from the miners perspective what matters is not the fees in any one of those transactions in the package but the overall level of fees across the entire package so if by confirming all of them you can get a higher level of fee per byte when aggregated together that's an appealing proposition to miners all they care about is the fundamental metric of fee per byte so that means if you put a parent transaction if you put a transaction into the mempool and it's not being confirmed what you can do is you can purposely create a child transaction in order to add fee by making the child overpay so that it carries along the parent by increasing the average fee across the two so let's say your parent pays one Satoshi per byte and your child pays let's say three Satoshi per byte and they're the same size then effectively the sum is four Satoshi and divide by two or something like that I probably got the math wrong but the bottom line is the average Satoshi per byte between the two is what matters and so yeah and in fact that would be two Satoshi per V byte across the two now the interesting use case here is that this is something the recipient can do or the sender can do let's say I pay my friend Bob and pay them with a simple normal transaction usually most transactions have one input two outputs so I've spent one of my inputs I've made a payment to Bob that's Bob's output and then there's another output which let's call it Andreas's change which is my change output now by creating a child that spends Bob's output Bob can create that child to bump the fee of the transaction I sent to Bob that hasn't been confirmed and get both of those confirmed faster so Bob can execute child pays for parent because Bob has an output that they can use to create a child transaction but I can also use child pays for parent because the change that's coming back to me is also an output that I can spend to create a child transaction that pays more fee and therefore bump the original transaction even if that original transaction did not use RBF I hope this is not too confusing RBF sender only signaling in advance that we may replace the transaction with a transaction with more fee child pays for parent taking advantage of the fact that transactions are considered as packages and if there is a parent a child a grandchild a great grandchild etc etc the average fee across all of them is taken into consideration so if you purposely create a child transaction a descendant transaction with a higher fee it increases the parent's opportunity to get confirmed as well and that's why the child is effectively paying for the parent there is a very interesting use case of this in the lightning network where you can create within a commitment transaction a payment output that is dust meaning that it's not a significant amount of satoshis but can be used as an input to make a child that bumps up the fee for the parent and that means that you don't have to overpay commitment transaction fees in advance to ensure that you can resolve protocol disputes and penalties but you can actually allow either party in a lightning payment channel to bump the commitment transaction by creating a child off one of the dust outputs which is one of the anyone can spend it's an interesting concept i believe those are called anchor payments it's a new proposal that's being implemented as part of the lightning protocol hi thanks for watching the video i'm andreas santanocles i'm the author of mastering bitcoin mastering ethereum and the internet of money series if you'd like to support my mission of bringing education about bitcoin and open blockchain to as many people as possible under open free creative commons licenses please consider subscribing to my channel and supporting me on patreon.com slash a a n t o n o p thank you