pull down to refresh

64 sats \ 4 replies \ @Murch 8 Oct \ parent \ on: REXEARCH : Virtual Size of Onchain Transaction bitcoin_beginners
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.
write
preview
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
reply
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)
reply
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.
reply
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.
reply