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

pull down to refresh

0 sats \ 5 replies \ @OT 9 Jan \ parent \ on: Save on-chain fees by merging transactions builders

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.