user5406: I'm looking for a detailed explanation of the weight, vsize and serialized length of a P2TR input, in the same vein as How big is the input of a P2PKH transaction?.

user5406: TL;DR:
A P2TR keypath input will weigh 57.5 vbytes. A P2TR scriptpath input will weigh a variable amount greater than that.
Composition of a P2TR 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 P2TR 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 (4 bytes)

A P2TR input requires a witness stack in the transaction's witness block. For a keypath spend, the witness stack will consist of:
WITNESS STACK: 
  item count (1 byte)
    signature length (1 byte)
    signature (64 bytes)

For a scriptpath spend, the witness stack will require zero or more script arguments (e.g. signatures), the leaf script, and a control block (CB):
WITNESS STACK: 
  item count (1 byte)
    script arguments (0–n)
      script argument length (1 byte)
      script argument (64 bytes for signatures, or variable)
    leaf script
      leaf script length (1 byte)
      leaf script (variable)
    Control Block
      CB length (1 byte)
      CB header (1 byte)
      hashing partners (32 bytes × CB depth)
      inner key (32 bytes)
  

Conservative weight, vsize, and size estimate
A P2TR keypath transaction input adds to a transactions…
weight:
4 × (32 + 4 + 1 + 4) + 1 + 1 + 64 = 230 WU (57.5 vB)

serialized byte length:
32 + 4 + 1 + 4 + 1 + 1 + 64 = 107 bytes

A simple P2TR scriptpath transaction input with a depth-0 control block and a <pubkey> OP_CHECKSIG leaf script would weigh
4 × (32 + 4 + 1 + 4) + 1 + (1 + 64) + (1 + 34) + (34) = 299 WU (74.75 vB)
 <Non-witness data> <items>  <sig>  <leafscript> <CB>

but most scriptpath spends would probably end up being much heavier than this.

Note that using at least one segwit input adds 2 witness bytes to the transaction header, the witness marker and witness flag. Also, when there is at least one segwit input, the witness block must have a witness stack for every input, which must consist of at least a witness item counter indicating that the stack is empty provided as a 0x00 byte for non-segwit inputs.
The overall transaction elements of a segwit transaction therefore are:
version (4 bytes)
witness marker (1 WU)
witness flag (1 WU)
input count (1 byte)
  inputs (variable size)
output count (1 byte)
  outputs (variable size)
witness stacks (as many as input count)
  witness item count (1 WU)
  witness items (0–n of variable weight)
locktime (4 bytes)


5406: <p>I'm looking for a detailed explanation of the weight, vsize and serialized length of a P2TR input, in the same vein as <a href="https://bitcoin.stackexchange.com/q/48279/5406">How big is the input of a P2PKH transaction?</a>.</p>
 5406: <p><strong>TL;DR:</strong><br />
A P2TR keypath input will weigh <strong>57.5 vbytes</strong>. A P2TR scriptpath input will weigh a variable amount greater than that.</p>
<h2>Composition of a P2TR 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 P2TR 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 (4 bytes)
</code></pre>
<p>A P2TR input requires a <em>witness stack</em> in the transaction's witness block. For a keypath spend, the witness stack will consist of:</p>
<pre><code>WITNESS STACK: 
  item count (1 byte)
    signature length (1 byte)
    signature (64 bytes)
</code></pre>
<p>For a scriptpath spend, the witness stack will require zero or more script arguments (e.g. signatures), the leaf script, and a control block (CB):</p>
<pre><code>WITNESS STACK: 
  item count (1 byte)
    script arguments (0–n)
      script argument length (1 byte)
      script argument (64 bytes for signatures, or variable)
    leaf script
      leaf script length (1 byte)
      leaf script (variable)
    Control Block
      CB length (1 byte)
      CB header (1 byte)
      hashing partners (32 bytes × CB depth)
      inner key (32 bytes)
  
</code></pre>
<h2>Conservative weight, vsize, and size estimate</h2>
<p>A P2TR keypath transaction input adds to a transactions…</p>
<p><strong>weight:</strong></p>
<pre><code>4 × (32 + 4 + 1 + 4) + 1 + 1 + 64 = 230 WU (57.5 vB)
</code></pre>
<p><strong>serialized byte length:</strong></p>
<pre><code>32 + 4 + 1 + 4 + 1 + 1 + 64 = 107 bytes
</code></pre>
<p>A simple P2TR scriptpath transaction input with a depth-0 control block and a <code>&lt;pubkey&gt; OP_CHECKSIG</code> leaf script would weigh</p>
<pre><code>4 × (32 + 4 + 1 + 4) + 1 + (1 + 64) + (1 + 34) + (34) = 299 WU (74.75 vB)
 &lt;Non-witness data&gt; &lt;items&gt;  &lt;sig&gt;  &lt;leafscript&gt; &lt;CB&gt;
</code></pre>
<p>but most scriptpath spends would probably end up being much heavier than this.</p>
<hr />
<p>Note that using at least one segwit input adds <strong>2 witness bytes</strong> to the transaction header, the <em>witness marker</em> and <em>witness flag</em>. Also, when there is at least one segwit input, the witness block must have a witness stack for <strong>every input</strong>, which must consist of at least a witness item counter indicating that the stack is empty provided as a <code>0x00</code> byte for non-segwit inputs.
The overall transaction elements of a segwit transaction therefore are:</p>
<pre><code>version (4 bytes)
witness marker (1 WU)
witness flag (1 WU)
input count (1 byte)
  inputs (variable size)
output count (1 byte)
  outputs (variable size)
witness stacks (as many as input count)
  witness item count (1 WU)
  witness items (0–n of variable weight)
locktime (4 bytes)
</code></pre>
