pull down to refresh

Interesting.
Why would the recipient use this? What's the advantage?
Maybe I'm not understanding in full but the part B would have to be the same amount for both parties. This is rare because few merchants have a fixed price in sats for their product.
Why would the recipient use this? What's the advantage?
Recipients transaction will be boosted because fee rate increases.
the part B would have to be the same amount for both parties
There's no need to use same amounts. Or how do you mean it?
reply
0 sats \ 5 replies \ @OT 9 Jan
If the fee rate increases then no one will save on fees. It will just get into a block faster or I guess you could aim for a low priority transaction and expect it to be fast.
I might have to look at it a bit more with a real world situation or use case. Payjoin I get as it's similar but obfuscates the change.
reply
Fee rate has to be increased a bit to motivate nodes to broadcast the new transaction. But total fee can be still lower. See the schema where I'm removing B output, B input, and one header. Or the example from app print-screen is real case where I save 16% even with increased fee rate.
The bigger fees the bigger saving...
reply
0 sats \ 3 replies \ @OT 9 Jan
Is it using CPFP?
reply
Yes. It's CPFP - ancestors and descendant merged into one transaction... And all your pending transactions too..
reply
0 sats \ 1 reply \ @OT 9 Jan
In that case don't both the original TX fees and the CPFP TX both need to be paid? How would that save fees for A?