Why isn't every block filled with a few GIANT many-to-many transactions
1237 sats \ 7 comments \ @moel 1 Jun 2023 bitcoin
What if walletes could merge or batch transactions into a bigger Taproot transaction? And then post this smaller taproot transaction to be mined?
Advantages:
  • basically a PayJoin, so improved privacy for everyone.
  • lower fees because Taproot MuSig transactions do not grow bigger when more inputs or outputs are given.
See also: https://payjoin.substack.com/p/may-payjoin-update
write
preview
related posts
431 sats \ 0 replies \ @rhombus 1 Jun 2023
We'll need trustless coordination servers to achieve this. As fees increase there will be more incentive to move in this direction.
reply
209 sats \ 0 replies \ @scottathan 1 Jun 2023
We will most likely end up there eventually. For now I think it's just that large batching of transactions takes enough coordination that adoption for it is coming on slowly.
reply
0 sats \ 0 replies \ @shibe 2 Jun 2023
lower fees because Taproot MuSig transactions do not grow bigger when more inputs or outputs are given.
This is not accurate. What MuSig is is an algorithm to construct a multisig Taproot address from multiple public keys securely, and which only requires one (aggregated) signature to spend. So such an output is identical to a singlesig Taproot address.
What you were thinking of was likely Cross-Input Signature Aggregation, which allows you to provide only one signature for all of your inputs. Unfortunately, this is not implemented in Bitcoin yet because it would most probably require a soft-fork (which would come with its own tradeoffs).
Hypothetically if such a feature came to Bitcoin, then large coinjoins would be around 15% cheaper than they are currently. Thus the incentives for batching transactions would be much stronger.
reply
0 sats \ 0 replies \ @sudonaka 2 Jun 2023
because it's still so early
reply
0 sats \ 2 replies \ @anon1 1 Jun 2023
I think this will happen, its just that the fee saving incentive is not really there yet but will continue to grow over time.
Another idea I have thought about is imagine you have a UTXO that you would like to completely send to a large custodian (100% of the UTXO value).
Traditionally you would just spend the UTXO to the address the custodian gives you. What could be done to save some fees but add a little time is you actually send the custodian the private key of the address of the UTXO. Then the custodian would spend your UTXO the next time it has to make a payment, crediting you after it has successfully spent it.
reply
10 sats \ 1 reply \ @shibe 2 Jun 2023
It'd be impossible to prevent you from spending the funds until the custodian decides to spend it themselves (which could be days from when you first "send" it).
IMO a more interesting proposal is using PayJoins for such things. Imagine you're depositing funds to an exchange, and at that time the exchange has some withdrawals queued up. They could use PayJoin to have you pay the people they owe money to instead of the exchange itself leading to better blockspace usage.
reply
0 sats \ 0 replies \ @anon1 3 Jun 2023
Yes, I meant that the custodian would only credit you after they successfully spend your UTXO meaning its in a transaction with 1+ confirmations.
Your idea is much better. Both ways use the same method to save fees but your way does not require sharing the private key which is definitely an improvement.
reply