pull down to refresh
1234 sats \ 6 replies \ @Murch 8 Oct \ on: REXEARCH : Virtual Size of Onchain Transaction bitcoin_beginners
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!
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
reply
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–297Now 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 sameThis 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.5For 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.
reply
I can offer this 2-of-2 P2TR transaction meanwhile, if that is of help: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530
reply
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)
reply
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 2014LOL, 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.
reply