pull down to refresh

REXEARCH : Virtual Size of Onchain Transaction

22.3k sats \ 10 comments \ @Rexdentron 8 Oct bitcoin_beginners

LORE

Stumble across Bitcoin, heard about it's P2P aspect
Initially thought fees are calculated in proportion to the payment amount
Quickly learned about UTXOs, TX input + output etc
Confused as to why some TXs have cheaper or more expensive TX fee even though they looked similar from quick glance
Learned script types, tryna find out how each script type are weighted and found these 1, 2 tools
Interested to know more & want to verify the information by myself
Conduct my own investigation
Results found, decided to share it on SN
Am i cooking ?

CLASSIFICATION & CORE ASPECTS

Script Type	Other
P2PK	Coinbase	Input-only (can't spend to Coinbase)
P2PKH	OP_Return	Output-only (can't spend from OP_Return)
P2MS	P2QRH	Still in the proposal-phase, add it anyway
P2SH	P2A	Haven't learned much of it, add it anyway
P2WPKH	Non-standard
P2WSH
P2TR

	Pre-SegWit	Post-SegWit
Overhead	nVersion	nVersion
	Input Count	Input Count
	Output Count	Output Count
	nLocktime	nLocktime
		Mark & Flag
Input Field	Outpoint	Outpoint
	scriptSig Length	scriptSig Length
	scriptSig	nSequence
	nSequence	Witness Items
Output Field	nValue	nValue
	scriptPubkey length	scriptPubkey Length
	scriptPubkey	scriptPubkey
Block Size/Weight ¹	1 Megabyte	4 Million Weight Units
		4 Mega Virtual Bytes

RESULTS

	Overhead	Input VSize	Output VSize
Coinbase		≥ 48 ?
OP_Returm			≥ 34 ?
P2PK	10	113 ~ 115	76
P2PK (Raw)	10	114	44
P2PKH	10	147 ~ 149	34
P2PKH	10	179 ~ 181	34
P2MS 1-of-1	10	113 ~ 115	46 or 78
P2MS 1-of-1	10	148 ~ 154	46
P2MS 1-of-2	10	114 ~ 116	80 or 112 or 144
P2MS 2-of-2	10	187 ~ 189	80 or 144
P2MS 1-of-3	10	114 ~ 115	114 or 146
P2MS 2-of-3	10	186 ~ 189	114 or 210
P2MS 3-of-3	10	258	114 or 210
P2SH 1-of-1	10	79 or 153	32
P2SH 1-of-1	10	184 ~ 186	32
P2SH 1-of-2	10	186 ~ 188	32
P2SH 1-of-2	10	252	32
P2SH 2-of-2	10	260 ~ 261	32
P2SH 2-of-2	10	326 ~ 328	32
P2SH 2-of-3	10	293 ~ 298	32
P2SH 2-of-3	10	329	32
P2SH 2-of-4	10	331	32
P2SH 3-of-4	10	530 ~ 534	32
P2SH 2-of-5	10	364	32
P2SH 3-of-5	10	436 ~ 438	32
P2SH 8-of-9	10	936 ~ 939	32
P2SH-P2WPKH	10.5	90.75 ~ 91	32
P2SH-P2WSH 1-of-1	10.5	104	32
P2SH-P2WSH 2-of-2	10.5	130.75 ~ 131	32
P2SH-P2WSH 2-of-3	10.5	139 ~ 139.25	32
P2WPKH	10.5	67.5 ~ 68	31
P2WSH 1-of-1	10.5	69.25	43
P2WSH 2-of-2	10.5	95.75 ~ 96	43
P2WSH 2-of-3	10.5	104 ~ 104.5	43
P2WSH 3-of-5	10.5	139.25 ~ 139.75	43
P2WSH 11-of-15	10.5	397.25 ~ 398.75	43
P2TR	10.5	57.5 ~ 57.75	43

EXAMPLES

Part	Size	Transactions Example
P2PK input	113	1, 2, 3, 4
	114	1, 2, 3
	115	1, 2
Raw P2PK input	114	1, 2
Raw P2PK output	44	1, 2
P2PKH input	147	1, 2, 3, 4
	148	1 (2nd), 2 (except 1st), 3 (1st), 4 (all)
	149	1, 2, 3, 4 (1st)
	179	1, 2, 3 (2nd), 4 (2nd)
	180	1, 2, 3, 4
	181	1, 2, 3 (all), 4 (1st)
P2MS 1-of-1 input	113	1
	115	1
	148	1
	154	1
P2MS 1-of-1 output	46	1, 2, 3, 4
	78	1
P2MS 1-of-2 input	114	1, 2, 3, 4
	115	1, 2, 3, 4
	116	1
P2MS 1-of-2 output	80	1, 2, 3, 4
	112	1, 2, 3
	144	1
P2MS 2-of-2 input	187	1, 2 (2nd)
	188	1, 2 (1st), 3 (2nd), 4 (2nd)
	189	1, 2, 3 (1st), 4
P2MS 2-of-2 output	80	1, 2, 3
	144	1, 2, 3, 4
P2MS 1-of-3 input	114	1 (1st), 2 (2nd), 3 (2nd)
	115	1 (3rd), 2 (2nd)
P2MS 1-of-3 output	114	1, 2, 3 (3rd), 4
	146	1, 2, 3, 4
P2MS 2-of-3 input	186	1, 2
	187	1, 2, 3, 4
	188	1, 2, 3, 4
	189	1
P2MS 2-of-3 output	114	1, 2, 3
	210	1, 2, 3, 4
P2MS 3-of-3 input	258	1
P2MS 3-of-3 output	114	1
	210	1
P2SH 1-of-1 input	79	1
	153	1
	184	1
	185	1, 2 (all)
	186	1, 2
P2SH 1-of-2 input	186	1, 2
	187	1, 2 (3rd), 3, 4
	188	1, 2
	252	1
P2SH 2-of-2 input	260	1, 2
	261	1
	326	1, 2
	327	1, 2
	328	1
P2SH 2-of-3 input	293	1 (1st), 2
	296	1, 2 (4th), 3
	297	1 (all), 2
	298	1 (5th), 2
	329	1
P2SH 2-of-4 input	331	1
P2SH 3-of-4 input	530	1 (1st)
	531	1 (2nd), 2, 3 (1st)
	533	1 (2nd)
	534	1 (3rd)
P2SH 2-of-5 input	364	1
P2SH 3-of-5 inout	436	1, 2
	437	1, 2
	438	1
P2SH 8-of-9 input	936	1 (3rd)
	938	1, 2 (2nd)
	939	1 (1nd)
P2SH-P2WPKH input	90.75	1 (2nd), 2
	91	1 (1st), 2, 3, 4
P2SH-P2WSH 1-of-1 input	104	1
P2SH-P2WSH 2-of-2 input	130.75	1, 2
	131	1 (1st)
P2SH-P2WSH 2-of-3 input	139	1
	139.25	1, 2, 3, 4
P2WPKH input	67.75	1 (1st & 4th), 2, 3, 4
	68	1, 2 (2nd & 3rd), 3, 4
P2WSH 1-of-1 input	69.25	1
P2WSH 2-of-2 input	95.75	1, 2, 3 (1st), 4 (1st)
	96	1 (2nd)
P2WSH 2-of-3 input	104	1, 2, 3, 4
	104.25	1, 2
	104.5	1
P2WSH 3-of-5 input	139.25	1, 2
	139.5	1 (all), 2
	139.75	1
P2WSH 11-of-15 input	397.25	1 (3rd)
	397.5	1, 2
	397.75	1, 2 (2nd), 3, 4
	398	1, 2, 3 (all), 4
	398.25	1, 2, 3, 4
	398.5	1 (1st), 2, 3, 4
	398.75	1
P2TR input	57.5	1, 2, 3, 4
	57.75	1 (all), 2, 3, 4

CLOSING BIT

Tools used :

Aight, i can't get any example of Pay-to-Anchor TX on mainnet yet. But who's gonna stop me from mentioning it ? Here are several examples of P2A TX on Testnet4 :

As output (receiver side)	As input (spender side)
1	1
2	2

Now, if the law of TX size calculation on Testnet4 is the same as Mainnet, then a P2A script would have 13 vb output size or 41 vb input size. CMIIW tho, i only sampled one address i found here.

Historically, we've gotten a new address type every 4 years (P2SH 2012, SegWit 2017, Taproot 2021), but given the slow adaptation of P2TR and long process of development, we are not gonna get P2QRH next year. Read the documentation here.

https://bitcoin.stackexchange.com/questions/98810/whats-the-blocksize-limit-after-segwit-and-how-do-legacy-nodes-deal-with-segwit ↩

view all related items

2 replies \ @Murch 8 Oct

Kudos for your efforts. Most of this looks good, but there are a few mistakes here and there. I’m prepping for the Optech Recap, so I’ll have to get back to this later, but I wanted to point out that a lot of the same information is compiled in topics tagged "transaction-weight" on Bitcoin Stack Exchange: https://bitcoin.stackexchange.com/questions/tagged/transaction-weight?tab=Frequent, e.g. https://bitcoin.stackexchange.com/a/75124/5406, https://bitcoin.stackexchange.com/questions/100159/what-is-the-size-and-weight-of-a-p2wpkh-input

172 sats \ 1 reply \ @Rexdentron OP 8 Oct

few mistakes here and there

Damn i wronged the P2PK output size, the compressed one should've been 44 vB and the uncompressed one should've been 76 vB

Pay to Witness Script Hash (P2WSH). Input¹: variable (2-of-3: 105 vBytes)

I can't find any example of it with 105 vB input size yet

Pay to Taproot (P2TR). Scriptpath 2-of-3²: 82.75 vB–115.5 vB

This is out of my knowledge, for now i only know about keypath and 2-of-2 P2TR, interested to find these example i haven't found before but i have no tools to automate this (i do it manually)

Null Data (OP_RETURN). Output: x ≤ 83 + 11(?) bytes

Now that is something arbitrary lol, i decided to just write "≥ 34" as it is the simplest example of OP_Return output i can find

If i had found these 1, 2 post before it would make my life so much easier. Much grateful for your contribution to the community🫡

266 sats \ 0 replies \ @Murch 8 Oct

I can't find any example of it with 105 vB input size yet

It’s really 418 weight units, which would translate to 104.5 vB, but the way vsize is defined, it’s supposed to be rounded up to the next integer. To be fair, I think I’ve been inconsistent on that one in the past years.

Pay to Taproot (P2TR). Scriptpath 2-of-3²: 82.75 vB–115.5 vB

This is out of my knowledge, for now i only know about keypath and 2-of-2 P2TR, interested to find these example i haven't found before but i have no tools to automate this (i do it manually)

Check out https://murch.one/posts/2-of-3-using-p2tr/

I think the shortest nulldata output is 11 B.

1234 sats \ 6 replies \ @Murch 8 Oct

Okay, now I have a little more time.

The "Script Type" table was a bit confusing to me.

I assume that the third column only refers to the second column and the first column is independent. At first I was reading the table as rows, and that didn’t make sense to me.

Regarding the transaction components:

minor typo: it’s "Marker" and "Flag"
The two columns seem to represent legacy inputs and native segwit inputs, but there is also a transitory mix of the two: wrapped segwit where inputs can have both an input script and witness items.
Also given that you reference serialization artifacts like the script length, it should maybe be pointed out that in the serialization the witness structure is separate from the input and output sections.

You may be interested in my opinionated BIP draft for transaction terminology here: https://github.com/murchandamus/bips/pull/1 (I really need to pick that up again!)

Regarding the block size/weight: given that unfortunately megabyte can both refer to 1000² bytes and 1024² bytes, to be clear the block size limit was 1,000,000 bytes which corresponds to just 1,000,000 vB, not 4,000,000 vB (see e.g. https://bitcoin.stackexchange.com/a/53626/5406).

Regarding Results:

As mentioned in my other comment, the smallest possible OP_RETURN output should come in as 11 bytes.
Regarding the multisig stuff, I think that some of them are off by a byte or so, e.g.:
- P2SH 2-of-3 should be 293–297 (see https://bitcoin.stackexchange.com/a/114254/5406), unless you are allowing high-s?
- P2SH-P2WSH 2-of-3 should be 139–139.5

Regarding P2A, the 13 vB output would always be the same across all anchors, since it’s a standard template.

Thanks for sharing your research, very cool!

0 sats \ 5 replies \ @Rexdentron OP 8 Oct

I assume that the third column only refers to the second column and the first column is independent

Correct

minor typo: it’s "Marker" and "Flag"

Noted

wrapped segwit where inputs can have both an input script and witness items.

Is this about Nested P2WPKH & P2WSH ? I might have to redo this part again to fix this

it should maybe be pointed out that in the serialization the witness structure is separate from the input and output sections.

Yes, i'm using the same TX structuring as what currently used by Bitcoin Optech Calculator. I don't mind separating the witness part with dedicated space though

megabyte can both refer to 1000² bytes and 1024² bytes

I always have this confusion, other people might have this too. Will specifically fix this in the future

the smallest possible OP_RETURN output should come in as 11 bytes.

Noted

P2SH 2-of-3 should be 293–297

Now that is confusing, i still don't understand how can the same address have different scriptSig (what could possibly caused that ?)

Here for example : https://mempool.space/tx/c7d8845045a4f3bd998bc1dbe63928f1e22029e5b056c00a56c2e478a2a08960?mode=details The 5th input has :

TX ID + Vout = 36 + 4
scriptSig length = 3
scriptSg = 255
Total = 298

And not just once, the second example also behaves the same

This one example has even bigger input size :

TX ID + Vout = 36 + 4
scriptSig length = 3
scriptSig = 286
Total = 329, is this a non-standard example ?

P2SH-P2WSH 2-of-3 should be 139–139.5

For input size 139 vB & 139.25 vB i can find example of that, but haven't found any example of 139.5 vB input size

output would always be the same across all anchors, since it’s a standard template.

Yeah, there is barely any debate about output size since it's standardized already

Thanks for sharing your research, very cool!

Thanks, may i ask a favor for one or two mainnet example of P2TR 2-of-3 scriptpath tho, it's for research purpose i promise

64 sats \ 4 replies \ @Murch 8 Oct

wrapped segwit where inputs can have both an input script and witness items.

Is this about Nested P2WPKH & P2WSH ? I might have to redo this part again to fix this

Yeah, that’s right. Nested P2WPKH/P2WSH is another term for Wrapped P2WPKH/P2WSH.

it should maybe be pointed out that in the serialization the witness structure is separate from the input and output sections.

Yes, i'm using the same TX structuring as what currently used by Bitcoin Optech Calculator. I don't mind separating the witness part with dedicated space though

Yeah, we did not make that distinction in the calculator, because the weight of the witness stack directly is dictated by the input type. However, as soon as one input has a witness stack, you need a witness structure, and a witness structure must contain a witness stack for every single input. For non-segwit inputs the witness stack consists simply of a witness item counter that is 0, but this means that the weight of non-segwit inputs goes up by one weight unit when they are combined with segwit inputs.

You can see the separate witness structure for example in the yogh.io explorer that nicely visualizes the transaction serialization (I picked a 2-of-3 wrapped segwit example from your list above): https://yogh.io/tx/23e2e8453fd9d00fc38833e996e042c35d60f5ac2196a2462a44930323694c17/

P2SH 2-of-3 should be 293–297

Now that is confusing, i still don't understand how can the same address have different scriptSig (what could possibly caused that ?)

Here for example : https://mempool.space/tx/c7d8845045a4f3bd998bc1dbe63928f1e22029e5b056c00a56c2e478a2a08960?mode=details The 5th input has :

TX ID + Vout = 36 + 4

scriptSig length = 3

scriptSg = 255

Total = 298

And not just once, the second example also behaves the same

This one example has even bigger input size :

TX ID + Vout = 36 + 4

scriptSig length = 3

scriptSig = 286

Total = 329, is this a non-standard example ?

Ah, fair point. I haven’t verified, but given the date of the transaction I can still suggest a possible explanation. ECDSA signatures are not fixed in size, among other things, the r and s component of the signature varies in size depending on whether the value falls in the upper half or lower half of the value range. High-s signatures became non-standard after 2014, given that your example is from 2012, I expect that some of the signatures are high-s.

P2SH-P2WSH 2-of-3 should be 139–139.5

For input size 139 vB & 139.25 vB i can find example of that, but haven't found any example of 139.5 vB input size

b426792a6f8f78e59172c1a65db1da4b60797162f9081b6f7a8b31665597d537 should fit the bill.

Thanks, may i ask a favor for one or two mainnet example of P2TR 2-of-3 scriptpath tho, it's for research purpose i promise

Sorry, I don’t have one on hand from the top of my head, but I will think about how to find one.

64 sats \ 2 replies \ @Murch 8 Oct

I can offer this 2-of-2 P2TR transaction meanwhile, if that is of help: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530

0 sats \ 1 reply \ @Rexdentron OP 8 Oct

https://yogh.io/tx/23e2e8453fd9d00fc38833e996e042c35d60f5ac2196a2462a44930323694c17/

That was beautiful ngl, not quite the same but Greg Walker also made something similar with his explorer

ECDSA signatures are not fixed in size. High-s signatures became non-standard after 2014

LOL, are Schnorr (for P2TR) & FALCON (for upcoming P2QRH) safe from this ?

b426792a6f8f78e59172c1a65db1da4b60797162f9081b6f7a8b31665597d537 should fit the bill.

TX ID + VOUT + scriptSig length + scriptSig + nSequence = 32 + 4 + 1 + 35 + 4 = 76 Witness = 63.5 Total = 139.5 (yeay, finally)

I can offer this 2-of-2 P2TR transaction meanwhile, if that is of help: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530

TX ID + VOUT + scriptSig length + nSequence = 32 + 4 + 1 + 4 = 41 Witness = 66.75 Total = 107.75 (that's new to me)

0 sats \ 0 replies \ @Murch 8 Oct

https://yogh.io/tx/23e2e8453fd9d00fc38833e996e042c35d60f5ac2196a2462a44930323694c17/

That was beautiful ngl, not quite the same but Greg Walker also made something similar with his explorer

Oh cool, I hadn’t seen that addition to Greg’s site yet.

ECDSA signatures are not fixed in size. High-s signatures became non-standard after 2014

LOL, are Schnorr (for P2TR) & FALCON (for upcoming P2QRH) safe from this ?

Yeah, ECDSA signatures used a weird encoding, but the schnorr signatures have a fixed size encoding. No idea about P2QRH, that seems a bit far out still.

0 sats \ 0 replies \ @Murch 9 Oct

Oh, I missed that 329 byte input last time. I would suspect that an uncompressed pubkey was in play.

LORE

CLASSIFICATION & CORE ASPECTS

RESULTS

EXAMPLES

CLOSING BIT

Footnotes