Block weight - Revision history

Harding: Redirect to Weight units, to which most of the content has been moved with a more detailed introduction. Some content moved to Segregated Witness instead. Only intro sentence was not moved somewhere.

2018-01-17T19:25:58Z

Redirect to Weight units, to which most of the content has been moved with a more detailed introduction. Some content moved to Segregated Witness instead. Only intro sentence was not moved somewhere.

Show changes

Theymos at 05:31, 23 August 2017

2017-08-23T05:31:20Z

← Older revision		Revision as of 05:31, 23 August 2017
Line 1:		Line 1:
	Prior to [[SegWit]], there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block weight is 4MB.		Prior to [[SegWit]], there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block weight is 4MB.

			===Summary: "How do I get cheaper transactions?"===

			To get cheaper transactions, you have to:

			# Install a SegWit-supporting wallet.
			# Receive money on new SegWit addresses, which start with 3. You must generate new addresses; your old addresses will never be SegWit addresses. Note that not all addresses starting with 3 are SegWit addresses, and it is impossible to tell just from looking at an address whether it is a SegWit address.
			# Whenever you ''spend BTC which you have received via SegWit addresses'', you will receive the SegWit discount. If you send a transaction spending some BTC received via non-SegWit addresses and some BTC received via SegWit addresses, you will receive a partial discount. The destination address doesn't matter.

			There are no compatibility issues: non-SegWit wallets can send BTC to SegWit addresses, and SegWit wallets can send BTC to non-SegWit addresses.

	===Definition of block weight===		===Definition of block weight===
Line 5:		Line 15:
	Normally, each byte in a transaction counts as 4 bytes of block weight. However, if a byte is part of the SegWit witness area, then it receives a ''discount'', and only counts as 1 byte of block weight.		Normally, each byte in a transaction counts as 4 bytes of block weight. However, if a byte is part of the SegWit witness area, then it receives a ''discount'', and only counts as 1 byte of block weight.

	For example, let's say that you've previously received ~~0.5~~ BTC to SegWit address A, and ~~0.5~~ BTC to legacy address B. Now consider a transaction sending both of these amounts to some address C. The data unrelated to the transaction inputs are always non-witness data counted as 4 bytes/byte. In particular, address C doesn't matter, and can be SegWit, non-SegWit, or anything. The ~~input~~ data related to address A will, ~~except for a constant amount of overhead,~~ be ~~witness data~~ counted as 1 byte/byte. The ~~input~~ data related to address B is non-SegWit, and so will be counted as 4 bytes/byte. ~~When we say~~ "~~input~~ data"~~, we primarily mean~~ the ~~signatures and public keys~~ in ~~the~~ [[Transactions\|scriptSig]].		For example, let's say that you've previously received some BTC to SegWit address A, and some BTC to legacy address B. Now consider a transaction sending both of these amounts to some address C. The data unrelated to the transaction inputs are always non-witness data counted as 4 bytes/byte. In particular, address C doesn't matter, and can be SegWit, non-SegWit, or anything. The witness data related to address A will go in the SegWit witness area, and will be be counted as 1 byte/byte. The witness data related to address B is non-SegWit, and so will be counted as 4 bytes/byte.

			"Witness data" is more-or-less the data that would go in a legacy transaction's [[Transactions\|scriptSig]].

	===Conversion to real sizes===		===Conversion to real sizes===
Line 11:		Line 23:
	It is a common misconception that SegWit somehow makes transactions smaller, but this is incorrect. A 300-byte transaction is 300 bytes on-disk and on-wire. SegWit just ''counts'' those bytes differently toward the 4MB weight limit.		It is a common misconception that SegWit somehow makes transactions smaller, but this is incorrect. A 300-byte transaction is 300 bytes on-disk and on-wire. SegWit just ''counts'' those bytes differently toward the 4MB weight limit.

	The maximum size of a block is nearly equal to the max block weight, so currently 4MB. This is not somehow "made-up" size; the maximum block is '''really''' 4MB on-disk and on-wire. However, this maximum should not usually be ~~reached~~.		The maximum size of a block is nearly equal to the max block weight, so currently 4MB. This is not somehow "made-up" size; the maximum block is '''really''' 4MB on-disk and on-wire. However, this maximum can only be reached if the block is full of very weird transactions, so it should not usually be seen.

	The ''typical'' size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to about 2.3MB typical blocks if all transactions were SegWit transactions.		The ''typical'' size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to about 2.3MB typical blocks if all transactions were SegWit transactions.

Theymos: /* Detailed example */

2017-08-23T05:11:24Z

Detailed example

← Older revision		Revision as of 05:11, 23 August 2017
Line 172:		Line 172:
	The transaction's '''real size on disk and over the network''' is 218 bytes, the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 bytes.		The transaction's '''real size on disk and over the network''' is 218 bytes, the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 bytes.

	It is not possible to create exactly-equivalent legacy transactions for SegWit transactions. If BTC is sent to a SegWit address, then it must be spent in a SegWit input. However, for comparison, a similar 1-input, 1-output legacy transaction would be about 191 bytes. The legacy transaction would consume 0.0191% of a 1MB legacy block, while this transaction consumes 0.0136% of a SegWit block, a reduction of 34%.		It is not possible to create exactly-equivalent legacy transactions for SegWit transactions. If BTC is sent to a SegWit address, then it must be spent in a SegWit input. However, for comparison, a similar 1-input, 1-output legacy transaction would be about 191 bytes. The legacy transaction would consume 0.0191% of a 1MB legacy block, while this transaction consumes 0.0136% of a SegWit block, a reduction of 34%. Different transaction types can have much greater reductions.

	You may notice that the transaction size has increased a little -- 218 bytes vs 191 bytes -- but most/all of the overhead is redundant data which could be removed. For example, if you have the witness, then you can compute the 23-byte P2SH script. If necessary, this data could be removed before transmitting the transactions: this would be a change to the P2P protocol which wouldn't even require a softfork.		You may notice that the transaction size has increased a little -- 218 bytes vs 191 bytes -- but most/all of the overhead is redundant data which could be removed. For example, if you have the witness, then you can compute the 23-byte P2SH script. If necessary, this data could be removed before transmitting the transactions: this would be a change to the P2P protocol which wouldn't even require a softfork.

	[[Category:Technical]]		[[Category:Technical]]

Theymos: Created page with "Prior to SegWit, there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block w..."

2017-08-23T04:58:43Z

Created page with "Prior to SegWit, there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block w..."

New page

Prior to [[SegWit]], there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block weight is 4MB.

===Definition of block weight===

Normally, each byte in a transaction counts as 4 bytes of block weight. However, if a byte is part of the SegWit witness area, then it receives a ''discount'', and only counts as 1 byte of block weight.

For example, let's say that you've previously received 0.5 BTC to SegWit address A, and 0.5 BTC to legacy address B. Now consider a transaction sending both of these amounts to some address C. The data unrelated to the transaction inputs are always non-witness data counted as 4 bytes/byte. In particular, address C doesn't matter, and can be SegWit, non-SegWit, or anything. The input data related to address A will, except for a constant amount of overhead, be witness data counted as 1 byte/byte. The input data related to address B is non-SegWit, and so will be counted as 4 bytes/byte. When we say "input data", we primarily mean the signatures and public keys in the [[Transactions|scriptSig]].

===Conversion to real sizes===

It is a common misconception that SegWit somehow makes transactions smaller, but this is incorrect. A 300-byte transaction is 300 bytes on-disk and on-wire. SegWit just ''counts'' those bytes differently toward the 4MB weight limit.

The maximum size of a block is nearly equal to the max block weight, so currently 4MB. This is not somehow "made-up" size; the maximum block is '''really''' 4MB on-disk and on-wire. However, this maximum should not usually be reached.

The ''typical'' size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to about 2.3MB typical blocks if all transactions were SegWit transactions.

===Detailed example===

Consider this transaction:

<pre>0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8
11072f85603000000171600141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b928ffff
ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92
888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1
f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001
c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242
b20af3425990ac00000000</pre>

{|
|-
! Data
! Description
! Raw byte count
! Type (multiplier)
! Section total weight
! Running total weight
|-
| <tt>01000000</tt>
| Version 1
| 4
| Non-witness (4x)
| 16
| 16
|-
| <tt>00</tt>
| SegWit marker
| 1
| Witness (1x)
| 1
| 17
|-
| <tt>01</tt>
| SegWit flag
| 1
| Witness (1x)
| 1
| 18
|-
| <tt>01</tt>
| Number of inputs (1)
| 1
| Non-witness (4x)
| 4
| 22
|-
| <tt>15..56</tt>
| Previous output hash
| 32
| Non-witness (4x)
| 128
| 150
|-
| <tt>03000000</tt>
| Previous output index (3)
| 4
| Non-witness (4x)
| 16
| 166
|-
|<tt>17</tt>
| Script length (23 bytes)
| 1
| Non-witness (4x)
| 4
| 170
|-
|<tt>16..28</tt>
| Script: P2SH-enclosed P2WPKH witness program
| 23
| Non-witness (4x)
| 92
| 262
|-
|<tt>ffffffff</tt>
| Sequence
| 4
| Non-witness (4x)
| 16
| 278
|-
|<tt>01</tt>
| Output count (1)
| 1
| Non-witness (4x)
| 4
| 282
|-
|<tt>9caef50500000000</tt>
| Output value (0.99987100 BTC)
| 8
| Non-witness (4x)
| 32
| 314
|-
|<tt>19</tt>
| Output script size (25)
| 1
| Non-witness (4x)
| 4
| 318
|-
|<tt>76..ac</tt>
| Script: DUP HASH160 0x1d7c... EQUALVERIFY CHECKSIG
| 25
| Non-witness (4x)
| 100
| 418
|-
|<tt>02</tt>
| Number of stack items for input 0 (2)
| 1
| Witness (1x)
| 1
| 419
|-
|<tt>48</tt>
| Size of stack item 0 (72)
| 1
| Witness (1x)
| 1
| 420
|-
|<tt>304...ab01</tt>
| Stack item 0, signature
| 72
| Witness (1x)
| 72
| 492
|-
|<tt>21</tt>
| Size of stack item 1 (33)
| 1
| Witness (1x)
| 1
| 493
|-
|<tt>03..ac</tt>
| Stack item 1, pubkey
| 33
| Witness (1x)
| 33
| 526
|-
|<tt>00000000</tt>
| Locktime (0)
| 4
| Non-witness (4x)
| 16
| 542
|}

The transaction's '''real size on disk and over the network''' is 218 bytes, the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 bytes.

It is not possible to create exactly-equivalent legacy transactions for SegWit transactions. If BTC is sent to a SegWit address, then it must be spent in a SegWit input. However, for comparison, a similar 1-input, 1-output legacy transaction would be about 191 bytes. The legacy transaction would consume 0.0191% of a 1MB legacy block, while this transaction consumes 0.0136% of a SegWit block, a reduction of 34%.

You may notice that the transaction size has increased a little -- 218 bytes vs 191 bytes -- but most/all of the overhead is redundant data which could be removed. For example, if you have the witness, then you can compute the 23-byte P2SH script. If necessary, this data could be removed before transmitting the transactions: this would be a change to the P2P protocol which wouldn't even require a softfork.

[[Category:Technical]]