14

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 ...


7

Yes, they are referring to two different metrics: virtual size (vsize) and size. The size in [bytes] of a transaction refers to the raw byte length of its serialized format. It is used to measure the data footprint of transactions when relayed on the network or stored on disk. The vsize in [vbytes] refers to a transaction's weighted size under segwit rules. ...


6

For non-segwit transactions, vbytes = bytes. With the implementation of SegWit, we now see the weight of the block/transactions rather than seeing the absolute size on the wire. While calculating the weight of a transaction, we use a weight of four for the normal transaction components (ex signature) and weight of one for the witness components. Now vbyte ...


5

The transaction limit under segwit is derived solely from the transaction weight and the block weight limit of 4,000,000 weight units. Virtual transaction size was not used for the limit calculation because it is fractional when computed accurately. Bitcoin Core only uses integers in the consensus code and thus transitioned to transaction weight. Virtual ...


4

Block weight is defined in BIP 141 itself: Block weight is defined as Base size * 3 + Total size. (rationale[3]) Base size is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node. Total size is the block size in bytes with transactions serialized as described ...


4

Have a look: https://blockchair.com/bitcoin/block/0000000000000000000cbbceb342e07071f9621607e044ec909aa86fcdf88e8a Size = 1,158,038 bytes Weight units = 3,992,825 WU Now what does it mean? So the size is what you probably understand well – when you have a file on disk, its size is measured in bytes and this is exactly what the size means here. It is the ...


3

In general, Segwit v1 is cheaper than segwit v0 to spend but slightly more expensive to create. Segwit v1 output scripts as defined by the proposed taproot BIP will always be 35 bytes in length. However Segwit v0 output scripts are either 22 bytes (for the single key case) or 34 bytes (script hash case). This means that the person sending to segwit v1 will ...


3

The advantage of using vsize is that it is a smooth transition from size; every non-witness transaction has vsize equal to size. All code and infrastructure that used satoshi/byte before, will keep working when substituting size with vsize, and give consistent results. Switching to weight would be confusing - would we be talking about satoshi/weightbyte?


3

No. The block weight is only calculated from the bytes themselves, not the sigops. Accounting for the sigops would need a hard fork, as explained by the section above the example: It is not possible to solve this problem without either a hardfork, or substantially decreasing the block size. Since segwit can’t fix the problem, it settles on not making it ...


2

I assume that James is using "sat/kw", to refer to "satoshi per kiloweightunit" as a means to express the fee rate of a transaction. "Weight" here refers to what replaced "blocksize" as a blockspace limit in the protocol rules with the segwit softfork. I'm seeing "sat/kw" for the first time in this context. I've seen wu used before to refer to weightunits ...


2

It's a trick that increases the block size without breaking backwards compatibility with non-Segwit nodes. I found this article by Jimmy Song to be more helpful than trying to understand the BIP. The Segwit blocks are restricted by something called Block Weight. Block Weight is a new concept introduced in Segwit, and it’s calculated on a per-transaction ...


2

The standardness limit in all recent Bitcoin Core versions with SegWit support is 400000 weight.


2

Note that the scriptSig field is not just the ECDSA signature itself (65 bytes) but also the public key in the case of a P2PKH input, or the redeem script for a P2SH input, and a couple more bytes for sizes. Also, there is a scriptSig for every input, not just one per transaction. You are looking at the average transaction size, most of which contain ...


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-...


1

In Bitcoin Optech Newsletter #46, the costs are compared as follows: Overall, this makes the cost to create and spend a Taproot single-sig output about 5% more expensive than P2WPKH. Vbytes P2PKH P2WPKH Taproot scriptPubKey 25 22 35 scriptSig 107 0 0 witness 0 26.75 16.25 ...


1

The explicit block weight limit cannot be changed without a hard fork.


1

To calculate the block weight, you need to know the size in bytes of the non-witness data and the size in bytes of the witness data. With a P2SH-P2WSH input, your scriptSig will always be 35 bytes. This makes the size in bytes of the inputs to be 36 + 35 + 4 = 75. The witnesses contain your signatures and scripts, so the witness for that input will be 1+m*(...


Only top voted, non community-wiki answers of a minimum length are eligible