reply on: Save on-chain fees by merging transactions \ stacker news ~builders

pull down to refresh

17 sats \ 6 replies \ @hynek OP 9 Jan \ parent \ on: Save on-chain fees by merging transactions builders

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?

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.

16 sats \ 4 replies \ @hynek OP 9 Jan

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...

0 sats \ 3 replies \ @OT 9 Jan

Is it using CPFP?

0 sats \ 2 replies \ @hynek OP 9 Jan

Yes. It's CPFP - ancestors and descendant merged into one transaction... And all your pending transactions too..

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?

0 sats \ 0 replies \ @hynek OP 9 Jan

You are paying for data stored. Which is basically inputs, outputs, and headers.

Please have a look on the schema above. Output B (of original TX) is the same as input B (of CPFP TX). When you remove them you save on fees. Both are redundant. And you don't need even the second TX header since it will be one transaction now.