<p>They are both just an encoding. The resulting tx could be exactly identical. In real life however people use bech32 just fur native segwit transactions, while p2sh is used as a wrapper around segwit. the tx is actually a tiny bit smaller when using p2sh.</p>

CC BY-SA 3.0
2017-12-26T23:24:52.507Z
Oh really? P2SH is actually smaller? What's the advantage of bech32 then?  I don't quite understand what "native" means in the context of "native segwit". By the way, do you have sources where we could read more about this / verify your answer?
B T
CC BY-SA 3.0
2017-12-31T23:56:05.783Z
The best source is always the actual source. bech32 have been proposed in bip173 which you can find here: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki It also has a section on how bech32 is better than different encodings. For the size there is no definite source without specifying what exactly you want to compare. bech32 is an encoding, p2sh is a type of transaction. For my comparison I assumed that bech32 is equivalent to native segwit.
blues
CC BY-SA 4.0
2021-04-10T18:19:32.143Z
This answer is false in multiple ways: 1. It's not just a different encoding, wrapped segwit and native segwit outputs are different output types. When funds are sent to a wrapped segwit address, they can only be spent in a wrapped segwit input, and vice versa for native segwit. 2. Wrapped segwit and native segwit transactions cannot be identical, even though they can have equivalent effect (at different fee costs). 3. Wrapped segwit transactions use more blockspace, than native segwit transactions.
Murch
CC BY-SA 3.0
2017-12-26T08:19:43.537Z
2017-12-26T08:19:43.537Z
blues
<p>bech32 produces smaller transactions than P2SH segwit transactions.</p>
<ul>
<li>one extra byte per output to create P2SH outputs than to create bech32 utxos (P2SH uses <code>OP_HASH160</code> and <code>OP_EQUAL</code> in addition to a 20 byte hash in its script, whereas bech32 just uses a fixed <code>00</code> byte in addition to a 20 byte hash), and</li>
<li>23 extra bytes per input to spend from P2SH utxos than from bech32 utxos (P2SH has to produce the script that was hashed when spending in the sigscript, which takes 23 bytes to encode - bech32 has no non-witness sigscript at all).</li>
</ul>
<p>Basically P2SH requires a script hash, native SegWit doesn't, and everything else is much the same. Native SegWit provides the script when the output is created, and P2SH provides it when the output is spent.</p>
<hr />
<p>If you want to know how much you saved (or can save) in each transaction, <a href="https://blockstream.info/" rel="nofollow noreferrer">Blockstream explorer</a> provides nice feature, where you can see the savings. For example for <a href="https://blockstream.info/tx/779af360d4a6a45fdfda824043fe3f1361ca760a29f912c27573624b26e75ca3" rel="nofollow noreferrer">this</a> transaction, can save extra 16% on fees</p>

CC BY-SA 3.0
2018-02-26T13:57:45.193Z
See discussion here: https://www.reddit.com/r/Bitcoin/comments/80a4zl/bitcoin_utxo_has_been_reduced_by_10_in_one_month/duu91c9/
Chris Moore
CC BY-SA 3.0
2018-02-26T14:47:29.107Z
https://bitcoincore.org/en/segwit_wallet_dev/#why-and-how-to-use-native-p2wpkh-and-p2wsh says "Comparing with the P2SH versions, the transaction vsize of native versions is smaller in most cases".
Chris Moore
CC BY-SA 4.0
2020-05-25T12:34:08.670Z
Here is an [example](https://blockstream.info/tx/779af360d4a6a45fdfda824043fe3f1361ca760a29f912c27573624b26e75ca3): SegWit => 30% savings. Native SegWit => extra 16% saving
MCCCS
CC BY-SA 4.0
2018-02-26T13:57:19.933Z
2021-05-12T13:51:38.587Z
2021-05-12T13:51:38.587Z
Chris Moore
<p>Bech32 (starts with bc1) and P2SH (starts with 3) can both be used for segwit transactions. I know bech32 is supposed to create smaller transactions, but I'd like to know how much smaller (than P2SH). How do transactions coming from a normal single-key address compare?</p>

CC BY-SA 4.0
2020-11-30T17:55:10.647Z
Related: [What is the size of different Bitcoin transaction types?](https://bitcoin.stackexchange.com/a/75124/5406)
Murch
<transactions><p2sh><bech32-address>
How do bech32 addresses compare to P2SH addresses in transaction size?
B T
# How do bech32 addresses compare to P2SH addresses in transaction size?

(Asked by: username_0 on 2017-12-19)

Bech32 (starts with bc1) and P2SH (starts with 3) can both be used for segwit transactions. I know bech32 is supposed to create smaller transactions, but I'd like to know how much smaller (than P2SH). How do transactions coming from a normal single-key address compare?

**Tags:** transactions, p2sh, bech32-address

> **Comments:**
> **username_1**: Related: [What is the size of different Bitcoin transaction types?](https://bitcoin.stackexchange.com/a/75124/5406)  

---

## 2 answers

### Answer by username_3 on 2018-02-26. Score: 13 | Accepted answer

bech32 produces smaller transactions than P2SH segwit transactions.

* one extra byte per output to create P2SH outputs than to create bech32 utxos (P2SH uses `OP_HASH160` and `OP_EQUAL` in addition to a 20 byte hash in its script, whereas bech32 just uses a fixed `00` byte in addition to a 20 byte hash), and
* 23 extra bytes per input to spend from P2SH utxos than from bech32 utxos (P2SH has to produce the script that was hashed when spending in the sigscript, which takes 23 bytes to encode - bech32 has no non-witness sigscript at all).

Basically P2SH requires a script hash, native SegWit doesn't, and everything else is much the same. Native SegWit provides the script when the output is created, and P2SH provides it when the output is spent.

---

If you want to know how much you saved (or can save) in each transaction, [Blockstream explorer](https://blockstream.info/) provides nice feature, where you can see the savings. For example for [this](https://blockstream.info/tx/779af360d4a6a45fdfda824043fe3f1361ca760a29f912c27573624b26e75ca3) transaction, can save extra 16% on fees

> **Comments:**
> **username_3**: See discussion here: https://www.reddit.com/r/Bitcoin/comments/80a4zl/bitcoin_utxo_has_been_reduced_by_10_in_one_month/duu91c9/  
> **username_3**: https://bitcoincore.org/en/segwit_wallet_dev/#why-and-how-to-use-native-p2wpkh-and-p2wsh says "Comparing with the P2SH versions, the transaction vsize of native versions is smaller in most cases".  
> **username_4**: Here is an [example](https://blockstream.info/tx/779af360d4a6a45fdfda824043fe3f1361ca760a29f912c27573624b26e75ca3): SegWit => 30% savings. Native SegWit => extra 16% saving  

---

### Answer by username_2 on 2017-12-26. Score: 0

They are both just an encoding. The resulting tx could be exactly identical. In real life however people use bech32 just fur native segwit transactions, while p2sh is used as a wrapper around segwit. the tx is actually a tiny bit smaller when using p2sh.

> **Comments:**
> **username_0**: Oh really? P2SH is actually smaller? What's the advantage of bech32 then?  I don't quite understand what "native" means in the context of "native segwit". By the way, do you have sources where we could read more about this / verify your answer?  
> **username_2**: The best source is always the actual source. bech32 have been proposed in bip173 which you can find here: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki It also has a section on how bech32 is better than different encodings. For the size there is no definite source without specifying what exactly you want to compare. bech32 is an encoding, p2sh is a type of transaction. For my comparison I assumed that bech32 is equivalent to native segwit.  
> **username_1**: This answer is false in multiple ways: 1. It's not just a different encoding, wrapped segwit and native segwit outputs are different output types. When funds are sent to a wrapped segwit address, they can only be spent in a wrapped segwit input, and vice versa for native segwit. 2. Wrapped segwit and native segwit transactions cannot be identical, even though they can have equivalent effect (at different fee costs). 3. Wrapped segwit transactions use more blockspace, than native segwit transactions.  

---

