<p><strong>TL;DR: Native segwit refers to segwit outputs without P2SH-wrapper. Bech32 is the address format used to represent native segwit-v0 locking scripts.</strong></p>
<h2>Wrapped segwit vs native segwit</h2>
<p>When segwit activated, it introduced the zeroth generation of segwit, segwit-v0. The corresponding locking scripts came in two flavors:</p>
<ol>
<li>The forward-compatible &quot;wrapped segwit&quot; or &quot;nested segwit&quot; output types wrap the witness program in a <em>Pay to Script Hash (P2SH)</em> output. There are two variants, <em>P2SH-P2WPKH</em> for single-sig, and  <em>P2SH-P2WSH</em> for arbitrary scripts including multisig.
As all <a href="https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki" rel="nofollow noreferrer">P2SH addresses</a>, wrapped segwit outputs get encoded using <em>Base58Check</em>. The wrapping allows any P2SH-enabled wallets to send to wrapped segwit addresses.</li>
<li>The compatibility-breaking &quot;native segwit&quot; output types which can only be paid to by segwit-enabled wallets. Native segwit outputs are <a href="https://bitcoin.stackexchange.com/a/84006/5406">more blockspace efficient</a> because they avoid the additional data necessary for the P2SH-wrapper by resolving the witness program directly. Native segwit locking scripts get encoded using the newly introduced <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">bech32 address format (BIP-173)</a> (for v0 native segwit outputs).</li>
</ol>
<h2>Other uses of Bech32</h2>
<p>Bech32 is also used for other purposes such as e.g. <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#encoding-overview" rel="nofollow noreferrer">encoding Lightning invoices</a>. Originally, it was planned to use Bech32 for later native segwit output versions as well. However, after a <a href="https://bitcoinops.org/en/newsletters/2019/12/28/#bech32-mutability" rel="nofollow noreferrer">mutability weakness</a> was discovered, and surveys found that many wallets did not properly handle sending to higher segwit versions, an amended version of Bech32 is in discussion. This amended version of Bech32 would use a different checksum constant to explicitly break forward-compatibility, i.e. require wallets to upgrade to create segwit-v1 outputs. Breaking forward-compatibility protects wallets from burning funds by incorrectly downgrading segwit-v1 addresses to segwit-v0 addresses, and allows the mutability weakness to be fixed.</p>
<h2>Native segwit-v1 to use Bech32m</h2>
<p>The proposed Taproot soft fork introduces the native segwit-v1 output type, <em>Pay to Taproot (P2TR)</em>, which would be the first native segwit output type to use this amended Bech32 address format, called &quot;Bech32m&quot; proposed by <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="nofollow noreferrer">BIP-350</a>.</p>

CC BY-SA 4.0
2020-12-07T22:40:25.703Z
2021-12-23T14:50:19.540Z
2021-12-23T14:50:19.540Z
Murch
<p>People seem to be using &quot;native segwit&quot; and &quot;bech32&quot; interchangeably. Are they really the same thing?</p>

<segregated-witness><terminology><bech32-address><bip350-bech32m>
What is the difference between "native segwit" and "bech32"?
Murch
# What is the difference between "native segwit" and "bech32"?

(Asked by: username_0 on 2020-12-07)

People seem to be using "native segwit" and "bech32" interchangeably. Are they really the same thing?

**Tags:** segregated-witness, terminology, bech32-address, bip350-bech32m


---

## 1 answers

### Answer by username_0 on 2020-12-07. Score: 12 | Accepted answer

**TL;DR: Native segwit refers to segwit outputs without P2SH-wrapper. Bech32 is the address format used to represent native segwit-v0 locking scripts.**

## Wrapped segwit vs native segwit

When segwit activated, it introduced the zeroth generation of segwit, segwit-v0. The corresponding locking scripts came in two flavors:

1. The forward-compatible "wrapped segwit" or "nested segwit" output types wrap the witness program in a *Pay to Script Hash (P2SH)* output. There are two variants, *P2SH-P2WPKH* for single-sig, and *P2SH-P2WSH* for arbitrary scripts including multisig.
   As all [P2SH addresses](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki), wrapped segwit outputs get encoded using *Base58Check*. The wrapping allows any P2SH-enabled wallets to send to wrapped segwit addresses.
2. The compatibility-breaking "native segwit" output types which can only be paid to by segwit-enabled wallets. Native segwit outputs are [more blockspace efficient](https://bitcoin.stackexchange.com/a/84006/5406) because they avoid the additional data necessary for the P2SH-wrapper by resolving the witness program directly. Native segwit locking scripts get encoded using the newly introduced [bech32 address format (BIP-173)](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) (for v0 native segwit outputs).

## Other uses of Bech32

Bech32 is also used for other purposes such as e.g. [encoding Lightning invoices](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#encoding-overview). Originally, it was planned to use Bech32 for later native segwit output versions as well. However, after a [mutability weakness](https://bitcoinops.org/en/newsletters/2019/12/28/#bech32-mutability) was discovered, and surveys found that many wallets did not properly handle sending to higher segwit versions, an amended version of Bech32 is in discussion. This amended version of Bech32 would use a different checksum constant to explicitly break forward-compatibility, i.e. require wallets to upgrade to create segwit-v1 outputs. Breaking forward-compatibility protects wallets from burning funds by incorrectly downgrading segwit-v1 addresses to segwit-v0 addresses, and allows the mutability weakness to be fixed.

## Native segwit-v1 to use Bech32m

The proposed Taproot soft fork introduces the native segwit-v1 output type, *Pay to Taproot (P2TR)*, which would be the first native segwit output type to use this amended Bech32 address format, called "Bech32m" proposed by [BIP-350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki).


---

