7
2
This video explains that the signature is moved out of the input section and moved to the new one called the witness. From what I can tell, the witness signature is still contained in this transaction - how would a simple reordering of information magically create more space?
I've perused other articles and videos and none of them seem to address this "magic".
12
TL;DR:
SegWit does not reduce the transaction size, if you're referring to the raw byte length of transactions. Instead it introduces block weight as a new metric that does not directly correspond to the raw byte length of transactions, but treats witness data as having less weight than other parts of the transaction.
The limit for Bitcoin blocks has been changed with the activation of segwit. Blocks used to be limited to 1,000,000 bytes (1MB). Since segwit they are limited to 4,000,000 weight units.
In calculating the weight of a transaction, bytes are weighed differenty depending on whether they are part of the witness or not:
This has the effect that a non-segwit transaction contributes exactly the same portion of the limit as before. E.g. the raw bytelength of a P2PKH transaction with one input und two outputs is 222 bytes, and it therefore weighs 888 WU, i.e. 222B / 1,000,000 B = 888 WU / 4,000,000 WU. This means that for non-segwit transactions, the block weight limit has exactly the same effect as the blocksize limit had before, and it is backwards compatible.
However, for segwit transactions the weight is not a quadruple of the raw transaction size. E.g. the raw bytelength of a P2SH-P2WSH 2-of-3 multisig transaction with one input and two outputs is 409 bytes, but its weight 868 WU as a large portion of the transaction input is witness data. A segwit transaction will therefore take a smaller portion of the weight limit than its raw bytelength would suggest.
To allow easier comparison to legacy fee rates, the block weight is often expressed as "virtual size" in "virtual bytes" or "vbytes". The virtual size is calculated by dividing the weight of a transaction by four and rounding up to the full integer. For non-segwit transactions, the raw bytelength and virtual size are equal.
In conclusion, the raw byte length of blocks can now exceed 1,000,000B, but the virtual size cannot exceed 1,000,000vB.
2
segwit IS a block size limit increase. No magic.
The segwit mechanism enforces a limit on a weighted data size calculated by counting the non-sig part of a transaction as base data (weight=4) and to count the sig data at a discounted rate (weight=1). The total of the block's weighted transaction sizes (called the 'block weight') is limited to 4MB. Non-upgraded clients will only see the base data and will apply the old 1MB limit as before.
So now you can see the block size increase. If the transactions all have (almost) zero base data and mostly signature data then the actual block size can be up to 4MB. If the transactions have mostly base data and zero signature data then the block size can only be up to 1MB. The actual case will always be somewhere in between - hence an increase in block space.
So weight must be an abstraction layer, cause when I have a block, that I want to store on disk, it consumes BYTES. Or when I transfer the block over net, the same Bytes are calculated. Would a maximum SegWit block transfer 4Megabytes? I was wondering, if the "weight" is only relevant for the fee calculation? – pebwindkraft – 2018-01-01T22:25:21.990
@pebwindkraft: I think 3.7MB is the maximum size that can be achieved as it's impossible to put all data into the witness. I don't know what you mean with "abstraction layer" but the block capacity is defined in weight. It's from that blockweight limit that the weight's relevance for the fee rate derives.
– Murch – 2018-01-02T04:40:35.713yup, thx, the block capacity is this "abstraction layer" (maybe not the right word, as I am not a native speaker). I was really thinking of bits and bytes, which are stored on disk (or are also transferred through the network connections). So block capacity ("weight") and disk capacity are something different. That was the confusing part. Sipa mentioned here (https://bitcoin.stackexchange.com/questions/58018/how-does-segwit-achieve-backwards-comtability-in-terms-of-the-block-size#comment66188_58018), blocksize would increase. As he is "godfather of segwit", I trust him :-) Segwit rocks!
– pebwindkraft – 2018-01-02T08:58:54.560@pebwindkraft: The virtual size of transactions is strictly smaller or equal to the raw transaction size, since part of the raw size is discounted. Hence with the virtual size limit being equal to the previous blocksize limit, the actual storage footprint can exceed the previous blocksize limit. A fact also observable in the lowest chart here: http://segwit.party/charts/
– Murch – 2018-01-02T09:44:45.7633The short answer to the question in the title is simply that SegWit does not reduce transaction size (when size means bytes). What it does is define a new concept as 'size', which no longer directly corresponds to disk size. In this new size, the witness is discounted, and so - for all intents and purposes - transactions become 'smaller'. – Pieter Wuille – 2018-01-03T15:17:56.597
@PieterWuille: Thanks, I added a TL;DR, inspired by this comment. – Murch – 2018-01-04T00:25:08.747