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 :
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.
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🫡
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)
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.
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.:
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 ?)
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.
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
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.