1. Both of them reduce transaction size which means :
- A block can contain more transaction, which can be seen as minor on-chain scaling
not true
the amount of utility of multisig is already low. so the benefits are not much. it just turns what would be a 2-2multisig bloated sig sitting in the witness areas appear as just 1 signature. basically bringing down the witness area from about 300kb to maybe 150kb
but what it does not do is do much for the baseblock scaling. paying into a multisig is the same as before. so no advantage of less inputs-outputs
but. with multisigs being used more (predicted) eventually there will be more people in the multisig, which when they finally want to get out will see alot more transactions of
bc1qmultisig 100btc -> bc1qsingleindependantusera 0.1btc
-> bc1qsingleindependantuserb 0.1btc
-> bc1qsingleindependantuserc 0.1btc
-> bc1qsingleindependantuserd 0.1btc
-> bc1qsingleindependantusere 0.1btc
-> bc1qsingleindependantuserf 0.1btc
-> bc1qsingleindependantuserg 0.1btc
and so on
(contract exits with hundreds of outputs) instead of currnt average of
3multisigtwooftwo 100btc -> 1singleindependantusera 50btc
-> 1singleindependantuserb 50btc
meaning that the base block sees transactions bloat up with multiple output transactions at contract exit than compared to todays scenario which is more just 2ins and 2outs average
the tx data per tx in the base for these higher used multisigs will be higher meaning less transactions per block.
the only appearance of gain is that length and complex scripts wont fill up the witness area to the same extent to cause even worse bloat
in short. if you can imagine a multisig script traditionally being say 3kb of bloat. yes in a legacy multisig that means under 300 transactions can sit in the baseblock with the legacy script.. but only IF there were any real examples of such bloatable scripts.. their werent so we never had that scenario/problem so we generally kept to a average tx count of ~2500
with segwit. the 3kb script sits outside the baseblock meaning 1000 scripts could sit outside the base block meaning only 1000 txdata can be inside the baseblock. thus segwit just mitigate the damage future scripts would cause to prevent transaction DECREASE issues if bloated scripts were added to legacy. thus instead of an average from ~2500 going down to ~300. segwit mitigated the damage to ~1000
which is still bad but not as bad as if legacy handled scripts
which if you do the numbers
with a witnss area filled with 1000 scripts of 3kb is the witness are filled. meaning if that was represented as a 2in 2out tx in baseblock txdata (300byte) is only 300kb inside the base block (30%filled) yes 30% filled base of just 1000tx but cant put more tx data inside the base block because the witness area is at its limit.
(300kb base 3mb witness: 30%fill, 100%fill) thus only as i said 1000 tx in the base
now with schnorr it allows 3kb script to end up being just a single short signature thus mitigating bloated scripts from causing this issue to the witness area. which means more scripts can go in the witness which means it prevents witness bloat from damaging the base block potential. thus bringing the average transaction data that can sit in the base block back to original average levels
but here is the thing...
the big thing people are missing the point of
the base block has always had the potential of upto 4200 transactions per block, averaging ~2500 most of the time of a complete fill
schnorr, segwit are NOT achieving anything that resembles allowing 40x more transactions in the base block by converting 3kb scripts into ~75byte script. instead its to prevent the bloated scripts from hitting witness area limits that would cause UNDER utility of the base block
its not scaling.. its early prevention of de-scaling transaction counts