multi signature – How does CoinJoin have an effect on the full transaction measurement?

0
46


Standing Quo

The CoinJoin transaction solely has a minimally decreased blockspace requirement compared to the unaggregated transactions:

Transaction sizes (instance is P2PKH) might be calculated by the next formulation:

 measurement = #inputs * 148 bytes + #outputs * 34 bytes + 10 bytes

By combining a number of transactions solely the ten bytes of the transaction overhead will probably be saved, the inputs and outputs would require the identical quantity of house as within the separate transactions earlier than.

The transaction measurement is proscribed by the blocksize, nevertheless transactions greater than 100kB are non-standard.

Outlook Schnorr Signatures

The latter will change with the deliberate introduction of Schnorr signatures and the next risk of signature aggregation. Schnorr signatures have the great characteristic that a number of signatures might be mixed into one.

Therefore, extra inputs on one transaction would scale back the blockspace requirement within the following style. Assuming the signature is about half of the enter measurement (it is 72 bytes of 148 for P2PKH) you’ll get:

inputSizeTotal(n inputs) = 1 * inputSize + (n - 1) * ยน/โ‚‚ * inputSize

With the variety of inputs going up (i.e. n โ†’ โˆž) you’d about halve the inputSizeTotal. ๐Ÿ˜‰


Replace 2023: Word that Cross-input signature aggregation was not shipped with the Taproot softfork, and if/when it is going to get shipped, it is going to require a brand new output sort since it’s incompatible with the foundations for P2TR. You’ll find extra details about the approximate financial savings in What block house financial savings would we get for coinjoins (and payjoins) if we had cross enter signature aggregation? and extra normal info by perusing matters tagged with .

LEAVE A REPLY

Please enter your comment!
Please enter your name here