Quote from: Herbert2020 on December 19, 2018, 08:52:28 AM

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 !

not specifically that one, but there a are a few of that exact format so

the whole hype of scaling using LN is "be like VISA"
visa dont have multisig.. they just do straight peer-visa-peer. so using the peer-to peer and not the group-to peer
.. you know.. making transactions lean and simple peer to peer.
... deactivating BLOATING contracts
... deactivating transactions that use more bytes (even 'singlekey' segwit uses more hard drive bytes than legacy does by the way)
and going back to basics of lean peer-to-peer network

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

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

Quote from: DooMAD on December 19, 2018, 01:39:48 PM

If you had bothered to acknowledge the point made in the first post, you might have noticed concern has been expressed about the rate at which the total size of the blockchain is growing. Obviously you don't care, but others do. Understand your audience. Try just for a moment to appreciate that you are not the only user on this chain. If users want to run code that utilises scale witness factor, they can.

witness scalefactor does not stop spammers spamming should they wish. witness scale factor does not stop block sizes increasing. but the whole segwit+witnes scale factor does limit tx count growth and does mess with the bloat vs hard drive utility per tx count

my answer of

Quote from: Herbert2020 on December 19, 2018, 08:52:28 AM

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 !

the whole hyp of scaling is "be like VISA"
visa dont have multisig.. they just do straight peer via peer. so using the peer-to peer and not the group-to peer
.. you know.. making transactions lean and simple peer to peer.
... deactivating BLOATING contracts
... deactivating transactions that use more bytes (even 'singlekey' segwit uses more hard drive bytes than legacy does by the way)
and going back to basics of lean peer-to-peer network

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

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

would still apply
as going back to simple peer-to-peer.. AND being leaner them 230 transactions would fit in LESS than 2.3mb... so that 2.3mb would fit more than 230tx

i know you dont like me discussing things. but this is a discussion board. the ignore button is free