The main aim of segwit was to actually increase the transaction speed
Technically transaction confirmation speed depends on the block intervals which is not changed by SegWit. What you meant to say is that SegWit increased the block capacity which then helped reduce mempool congestion hence emptying up the mempool helping txs not get stuck for long waiting for confirmation.~
are you sure about this? from what I remember, the hash-wrapped version of segwit and the bech32 encoded version (i.e. native) have different sizes as inputs and as outputs when compared to each other, as well as those measurements being different to those of the previous standard (compressed-key P2PKH), and that's also in terms of literal bytes, not just the witness-discounted (i.e. "virtual") bytes.
In raw bytes the SegWit transactions have the potential to be slightly bigger because we are adding extra bytes to the transactions containing witnesses. are you sure about this? from what I remember, the hash-wrapped version of segwit and the bech32 encoded version (i.e. native) have different sizes as inputs and as outputs when compared to each other, as well as those measurements being different to those of the previous standard (compressed-key P2PKH), and that's also in terms of literal bytes, not just the witness-discounted (i.e. "virtual") bytes.
If we compare a transaction spending P2PKH with P2WPKH the later has 3 extra bytes (assuming signature and public key sizes are the same):
- 2 bytes for the flag (0x0001)
- 1 byte for the witness count (0x02)
If we compare P2PKH with P2SH-P2WPKH (wrapped) then there is another additional size which is the redeem script and it is extra 22 bytes (25 bytes bigger in total).
If we only compare outputs, then a P2PKH output script is 25 bytes while P2WPKH is 22 bytes.
This means the net total size of creating P2WPKH and spending them (3 bytes less output, 3 extra input bytes) is zero.
