<p><strong>TL;DR:</strong><br />
A P2SH-P2WPKH input should be conservatively estimated with <strong>91.0 vbytes</strong>. Standard P2SH-P2WPKH inputs generally weigh 90.75 or 91.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding (which is highly recommended) will always produce 90.75 vbyte inputs. 91.0 vbytes is the conservative estimate allowing for high-r signatures.</p>
<h2>Composition of a P2SH-P2WPKH 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>P2SH inputs contain a redeemscript in their <em>scriptsig</em>. For a P2SH-P2WPKH input this is a v0 witness program that redirects the script evaluation to the witness stack by committing to the hash of a pubkey:</p>
<pre><code>SCRIPTSIG: length (1 byte)
  redeemscript length (1 byte)
  redeemscript (22 bytes)
</code></pre>
<p>Each transaction input has its own <em>sequence</em> number:</p>
<pre><code>sequence (4 bytes)
</code></pre>
<p>A P2SH-P2WPKH input requires a <em>witness stack</em> in the transaction's witness block:</p>
<pre><code>WITNESS: item count (1 byte)
  signature length (1 byte)
  signature (71 or 72 bytes)¹
  pubkey length (1 byte)
  pubkey (33 bytes)
</code></pre>
<h2>Conservative weight, vsize, and size estimate</h2>
<p>A P2SH-P2WPKH transaction input adds to a transactions…</p>
<p><strong>weight:</strong></p>
<pre><code>4 × (32 + 4 + 1 + 1 + 22 + 4) + 1 + 1 + 72 + 1 + 33 = 4×64 + 108 = 364 WU
</code></pre>
<p><strong>vsize:</strong></p>
<pre><code>32 + 4 + 1 + 1 + 22 + 4 + (1 + 1 + 72 + 1 + 33) / 4 = 91 vbytes
</code></pre>
<p><strong>serialized byte length:</strong></p>
<pre><code>32 + 4 + 1 + 1 + 22 + 4 + 1 + 1 + 72 + 1 + 33 = 172 bytes
</code></pre>
<p>If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing the signature to 71 bytes and the above maxima to 363 WU, 90.75 vbytes, and 171 bytes respectively.</p>
<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 count item for <strong>every input</strong>, which must be 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 item counts (1 WU × input count)
  witness stacks (variable weight)
locktime (4 bytes)
</code></pre>
<p>Mentioned for completeness, a P2SH-P2WPKH input that has a non-standard signature with both high-s and high-r weighs 365 WU, 91.25 vbytes, and 173 bytes accordingly.</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>

CC BY-SA 4.0
2021-12-21T17:50:12.417Z
What is signature grinding and why is it recommended?
Vojtěch Strnad
CC BY-SA 4.0
2021-12-21T18:27:12.197Z
The serialization format used for ECDSA signatures requires 33 bytes to encode an r-value that falls into the higher half of the range, but only 32 bytes to encode one falling into the lower half of the range. This means that by repeating the signing until you get an r-value in the lower range ("grinding the signature"), you can decrease the size of your signature by 1 byte. This takes an expected two attempts per signature and makes it easier to estimate the necessary fees for transactions before signing and reduces the blockspace footprint and fees for transactions.
Murch
CC BY-SA 4.0
2021-12-21T17:46:11.190Z
2021-12-21T17:46:11.190Z
Murch
<p>I'm looking for a detailed explanation of the exact weight, vsize and serialized length of a P2SH-P2WPKH (wrapped-segwit single-sig) 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>

<segregated-witness><transaction-input><transaction-weight>
What is the size and weight of a wrapped segwit single-sig input?
Murch
# What is the size and weight of a wrapped segwit single-sig input?

(Asked by: username_0 on 2021-12-21)

I'm looking for a detailed explanation of the exact weight, vsize and serialized length of a P2SH-P2WPKH (wrapped-segwit single-sig) input, in the same vein as [How big is the input of a P2PKH transaction?](https://bitcoin.stackexchange.com/q/48279/5406).

**Tags:** segregated-witness, transaction-input, transaction-weight


---

## 1 answers

### Answer by username_0 on 2021-12-21. Score: 3 | Accepted answer

**TL;DR:**  
A P2SH-P2WPKH input should be conservatively estimated with **91.0 vbytes**. Standard P2SH-P2WPKH inputs generally weigh 90.75 or 91.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding (which is highly recommended) will always produce 90.75 vbyte inputs. 91.0 vbytes is the conservative estimate allowing for high-r signatures.

## Composition of a P2SH-P2WPKH input

Each input commits to spending a specific UTXO by providing its *transaction outpoint*:

```
PREVOUT: hash (32 bytes)
         index (4 bytes)

```

P2SH inputs contain a redeemscript in their *scriptsig*. For a P2SH-P2WPKH input this is a v0 witness program that redirects the script evaluation to the witness stack by committing to the hash of a pubkey:

```
SCRIPTSIG: length (1 byte)
  redeemscript length (1 byte)
  redeemscript (22 bytes)

```

Each transaction input has its own *sequence* number:

```
sequence (4 bytes)

```

A P2SH-P2WPKH input requires a *witness stack* in the transaction's witness block:

```
WITNESS: item count (1 byte)
  signature length (1 byte)
  signature (71 or 72 bytes)¹
  pubkey length (1 byte)
  pubkey (33 bytes)

```

## Conservative weight, vsize, and size estimate

A P2SH-P2WPKH transaction input adds to a transactions…

**weight:**

```
4 × (32 + 4 + 1 + 1 + 22 + 4) + 1 + 1 + 72 + 1 + 33 = 4×64 + 108 = 364 WU

```

**vsize:**

```
32 + 4 + 1 + 1 + 22 + 4 + (1 + 1 + 72 + 1 + 33) / 4 = 91 vbytes

```

**serialized byte length:**

```
32 + 4 + 1 + 1 + 22 + 4 + 1 + 1 + 72 + 1 + 33 = 172 bytes

```

If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing the signature to 71 bytes and the above maxima to 363 WU, 90.75 vbytes, and 171 bytes respectively.

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 count item for **every input**, which must be 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 item counts (1 WU × input count)
  witness stacks (variable weight)
locktime (4 bytes)

```

Mentioned for completeness, a P2SH-P2WPKH input that has a non-standard signature with both high-s and high-r weighs 365 WU, 91.25 vbytes, and 173 bytes accordingly.

---

¹ also see [What is the maximum size of a DER encoded ECDSA signature?](https://bitcoin.stackexchange.com/a/77192/5406).

> **Comments:**
> **username_1**: What is signature grinding and why is it recommended?  
> **username_0**: The serialization format used for ECDSA signatures requires 33 bytes to encode an r-value that falls into the higher half of the range, but only 32 bytes to encode one falling into the lower half of the range. This means that by repeating the signing until you get an r-value in the lower range ("grinding the signature"), you can decrease the size of your signature by 1 byte. This takes an expected two attempts per signature and makes it easier to estimate the necessary fees for transactions before signing and reduces the blockspace footprint and fees for transactions.  

---

