user5406: I'm proofreading an article mentioning the cost reduction of P2TR for Lightning channels in comparison to P2WSH. To that end, I'm looking for the precise weight, vsize and serialized length of a 2-of-2 P2WSH input.

user5406: TL;DR:
A 2-of-2 P2WSH input should be conservatively estimated with 96 vbytes. Standard 2-of-2 P2WSH inputs generally weigh 95.5, 95.75 or 96.0 vbytes, depending on whether the r-values in the signatures are low or high. A wallet using signature grinding (which is highly recommended) will always produce 95.5 vbyte inputs. 96.0 vbytes is the conservative estimate allowing for high-r signatures.
Composition of a P2WSH input
Each input commits to spending a specific UTXO by providing its transaction outpoint:
PREVOUT: hash (32 bytes)
         index (4 bytes)

The scriptSig for a P2WSH input is empty, however, the scriptSig length must be provided as 0:
SCRIPTSIG: length (1 byte)
           <no content>

Each transaction input has its own sequence number:
SEQUENCE: nSequence (4 bytes)

A 2-of-2 P2WSH input requires a witness stack in the transaction's witness block. The witness stack has four elements: the witness script, the two signatures, and the dummy element that OP_CHECKMULTISIG additionally pops from the stack but never uses. The dummy element is provided in the form of a length 0 push, just like the scriptSig in the non-witness part of the input.
WITNESS: item count (1 byte)
         dummy element length (1 byte)
         <no content>
         1st signature length (1 byte)
         1st signature (71 or 72 bytes)¹
         2nd signature length (1 byte)
         2nd signature (71 or 72 bytes)¹
         witness script length (1 byte)
           signature count (OP_2, 1 byte)
           1st pubkey length (1 byte)
           1st pubkey (33 bytes)
           2nd pubkey length (1 byte)
           1nd pubkey (33 bytes)
           pubkey count (OP_2, 1 byte)
           OP_CHECKMULTISIG (1 byte)

Conservative weight, vsize, and size estimate
A P2WPKH transaction input adds to a transactions…
weight:
non-witness data: 4 × (32 + 4 + 1 + 4) = 164 WU
witness script: 1 + 1 + 33 + 1 + 33 + 1 + 1 = 71 WU
entire witness: 1 + (1 + 0) + (1 + 72) + (1 + 72) + (1 + witness script) = 220 WU
non-witness + witness = 164 + 220 = 384 WU

vsize:
32 + 4 + 1 + 4 + [1 + (1 + 0) + (1 + 72) + (1 + 72) + (1 + 71)] / 4 = 96 vbytes

serialized byte length:
32 + 4 + 1 + 4 + [1 + (1 + 0) + (1 + 72) + (1 + 72) + (1 + 71)] = 261 bytes

If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing a signature to 71 bytes and the above maxima to 382 WU, 95.5 vbytes, and 259 bytes respectively.

¹ also see What is the maximum size of a DER encoded ECDSA signature?.

5406: <p>I'm proofreading an article mentioning the cost reduction of P2TR for Lightning channels in comparison to P2WSH. To that end, I'm looking for the precise weight, vsize and serialized length of a 2-of-2 P2WSH input.</p>
 5406: <p><strong>TL;DR:</strong><br />
A 2-of-2 P2WSH input should be conservatively estimated with <strong>96 vbytes</strong>. Standard 2-of-2 P2WSH inputs generally weigh 95.5, 95.75 or 96.0 vbytes, depending on whether the r-values in the signatures are low or high. A wallet using signature grinding (which is highly recommended) will always produce 95.5 vbyte inputs. 96.0 vbytes is the conservative estimate allowing for high-r signatures.</p>
<h2>Composition of a P2WSH input</h2>
<p>Each input commits to spending a specific UTXO by providing its <em>transaction outpoint</em>:</p>
<pre><code>PREVOUT: hash (32 bytes)
         index (4 bytes)
</code></pre>
<p>The <em>scriptSig</em> for a P2WSH input is empty, however, the scriptSig length must be provided as <code>0</code>:</p>
<pre><code>SCRIPTSIG: length (1 byte)
           &lt;no content&gt;
</code></pre>
<p>Each transaction input has its own <em>sequence</em> number:</p>
<pre><code>SEQUENCE: nSequence (4 bytes)
</code></pre>
<p>A 2-of-2 P2WSH input requires a <em>witness stack</em> in the transaction's witness block. The witness stack has <em>four</em> elements: the witness script, the two signatures, and the dummy element that <code>OP_CHECKMULTISIG</code> <a href="https://bitcoin.stackexchange.com/q/54789/5406">additionally pops from the stack but never uses</a>. The dummy element is provided in the form of a length 0 push, just like the <code>scriptSig</code> in the non-witness part of the input.</p>
<pre><code>WITNESS: item count (1 byte)
         dummy element length (1 byte)
         &lt;no content&gt;
         1st signature length (1 byte)
         1st signature (71 or 72 bytes)¹
         2nd signature length (1 byte)
         2nd signature (71 or 72 bytes)¹
         witness script length (1 byte)
           signature count (OP_2, 1 byte)
           1st pubkey length (1 byte)
           1st pubkey (33 bytes)
           2nd pubkey length (1 byte)
           1nd pubkey (33 bytes)
           pubkey count (OP_2, 1 byte)
           OP_CHECKMULTISIG (1 byte)
</code></pre>
<h2>Conservative weight, vsize, and size estimate</h2>
<p>A P2WPKH transaction input adds to a transactions…</p>
<p><strong>weight:</strong></p>
<pre><code>non-witness data: 4 × (32 + 4 + 1 + 4) = 164 WU
witness script: 1 + 1 + 33 + 1 + 33 + 1 + 1 = 71 WU
entire witness: 1 + (1 + 0) + (1 + 72) + (1 + 72) + (1 + witness script) = 220 WU
non-witness + witness = 164 + 220 = 384 WU
</code></pre>
<p><strong>vsize:</strong></p>
<pre><code>32 + 4 + 1 + 4 + [1 + (1 + 0) + (1 + 72) + (1 + 72) + (1 + 71)] / 4 = 96 vbytes
</code></pre>
<p><strong>serialized byte length:</strong></p>
<pre><code>32 + 4 + 1 + 4 + [1 + (1 + 0) + (1 + 72) + (1 + 72) + (1 + 71)] = 261 bytes
</code></pre>
<p>If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing a signature to 71 bytes and the above maxima to 382 WU, 95.5 vbytes, and 259 bytes respectively.</p>
<hr />
<p><sup>¹ also see <a href="https://bitcoin.stackexchange.com/a/77192/5406">What is the maximum size of a DER encoded ECDSA signature?</a>.</sup></p>
