Quote from: franky1 on December 19, 2018, 08:17:17 AM

Quote from: Herbert2020 on December 19, 2018, 06:19:18 AM

so what are you trying to suggest here?

the number of transactions in that block is 230 because people (services) have been batching transactions and reusing addresses which has led to creating bigger transactions hence taking up bigger space in a block hence a block being able to contain lesser number of them.

this has been the case from day 1 and will be with or without SegWit or even with having a hard fork to a block size 2 MB.

what you notice is that the bloated "batch" tx's are using segwit smart contracts which batched up 200 inputs and 1 output
with a 65kb bloat per tx

if an exchange used 200 legacy addresses
in*180 + out*34 + 10
200*180 +1*34 +10=36044

so using segwit. actual hard drive bytes are 65kb.. vs legacy would have been 36kb per tx..
meaning less actual hard drive bytes would have been used by that block 230 txs.

now imagine it was legacy, and no witness scale factor and the legacy cap was 2.3mb(to keep the block the same hard drive bytes used limit as the block exampled).. more than 230 tx's would have fit in

now imagine 4mb legacy cap without the segwit witness scale factor to make the 4mb weight fully utilisable. even more transactions would have fit into a block..

it aint rocket science

if this (bb7f7a0988e96f9939d0a39effc969ff5c1c18be9fe667ddde65c290dd8ae2d0) is the transaction you have in mind (which has 200 inputs) then it is not single key SegWit which you are comparing with a single key legacy transaction! it is a multi signature SegWit with 2 signatures in it (2 of 3) so each output is increased by 2 additional pubkeys (2*32 byte + 1 byte size + 4 byte op codes) which has nothing to do with SegWit!

as for scriptsig in this type of transaction it is there because they are using a workaround for using SegWit instead of using SegWit itself (workaround being nested in p2sh). if you use direct SegWit instead scriptsig would be empty !