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?.

1 Answer 1


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…


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


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?.

  • What is signature grinding and why is it recommended? Dec 21, 2021 at 17:50
  • 1
    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
    Dec 21, 2021 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.