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

pull down to refresh

Save on-chain fees by merging transactions

655 sats \ 10 comments \ @hynek 8 Jan builders

Send a transaction, and the recipient uses the coin for another payment. You then merge these two transactions together and save on fees. 🔥

https://github.com/user-attachments/assets/c113b688-d144-4f6f-9986-c7873656ba4f

If you have a Trezor, you can try this out on: https://coiner-mu.vercel.app/ _newest version is not yet deployed, but the code is ready on github: https://github.com/hynek-jina/coiner But be cautious. This is a hobby project without any guarantee.

https://github.com/user-attachments/assets/36412edb-9c62-4c5f-8f82-b41c118a3aa6

How does it work?

Connect Trezor, enter the passphrase, and select an account.
The application display your coins, pending transactions, and descendant transactions.
Then app shows you how much you can save by merging all transactions and removing duplicate information.
Finally, you can sign and broadcast this more efficient transaction

view all related items

157 sats \ 7 replies \ @OT 8 Jan

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.

17 sats \ 6 replies \ @hynek OP 9 Jan

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?

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.

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.

reply on another page

189 sats \ 1 reply \ @ama 8 Jan

Or you can use PayJoin, see also.

120 sats \ 0 replies \ @hynek OP 9 Jan

Thanks, Payjoin is cool. Here is the difference, that users don't need to actively communicate, but mempool is used as a "marketplace" or communication platform → which is not optimal but sometimes might be handy.

And just like Payjoin this is creating aliby for chain analysis...