<blockquote>
<p>I wonder that I'm unable to see how exactly BIP 0341 forbids v1+ segwit from using bech32.</p>
</blockquote>
<p>BIP341 has nothing to do with this; it specifies consensus validation rules, not address encoding.</p>
<p>BIP350 however specifies that Bech32m must be used for v1+ segwit, and Bech32 for v0 segwit. The older BIP173 specified that all witness outputs (v0 and v1+) use Bech32.</p>
<hr />
<blockquote>
<p>Does consensus allow combining v1+ segwit programs with the bech32 format?</p>
</blockquote>
<p>As far as consensus rules are concerned, addresses do not exist (only scripts do). Conversion from/to addresses is something done by wallets (and other user-facing software), and thus if such software follows BIP350, they'd use Bech32m for v1+ segwit outputs.</p>
<p>Old pre-BIP350 software however might use Bech32 for such outputs, meaning such software won't accept addresses created by BIP350-compliant wallets. This is deliberate (from BIP350):</p>
<blockquote>
<p>Experiments by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by breaking forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.</p>
</blockquote>
<hr />
<blockquote>
<p>Does consensus allow combining v0 segwit programs with the bech32m format?</p>
</blockquote>
<p>Again unrelated to consensus, but BIP350 does not allow this (and neither does BIP173).</p>

CC BY-SA 4.0
2023-08-22T19:26:16.267Z
2023-08-22T21:45:09.560Z
2023-08-22T21:45:09.560Z
Pieter Wuille
<p>I wonder that I'm unable to see how exactly <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP 0341</a> forbids v1+ segwit from using bech32.</p>
<p>Does consensus allow combining v1+ segwit programs with the bech32 format?</p>
<p>I could expect v0 segwit was maybe defined back in the day so to use bech32 in a somewhat hardwired fashion that allows for no tricks. But it obviously allows to hide the script behind a P2SH hash, so 'choices' exist.</p>
<p>Does consensus allow combining v0 segwit programs with the bech32m format?</p>

CC BY-SA 4.0
2023-08-22T19:28:33.423Z
You seem to be mixing two different things. bech32 and bech32m are address types. Taproot and segwit v0  wsh/wpkh are output formats for taproot and v0 spendings, respectively. Those are two different things, address is a common way to encode the actual script, but the network **only** sees scripts. You can use bech32m for v0, but this is not standard and hardly supported, but it's not consensus.
Davidson Souza
<segregated-witness><taproot><bech32-address><bip350-bech32m>
Are contrived combinations of address format and segwit version program possible?
Mercedes
# Are contrived combinations of address format and segwit version program possible?

(Asked by: username_0 on 2023-08-22)

I wonder that I'm unable to see how exactly [BIP 0341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) forbids v1+ segwit from using bech32.

Does consensus allow combining v1+ segwit programs with the bech32 format?

I could expect v0 segwit was maybe defined back in the day so to use bech32 in a somewhat hardwired fashion that allows for no tricks. But it obviously allows to hide the script behind a P2SH hash, so 'choices' exist.

Does consensus allow combining v0 segwit programs with the bech32m format?

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

> **Comments:**
> **username_1**: You seem to be mixing two different things. bech32 and bech32m are address types. Taproot and segwit v0  wsh/wpkh are output formats for taproot and v0 spendings, respectively. Those are two different things, address is a common way to encode the actual script, but the network **only** sees scripts. You can use bech32m for v0, but this is not standard and hardly supported, but it's not consensus.  

---

## 1 answers

### Answer by username_2 on 2023-08-22. Score: 4 | Accepted answer

> I wonder that I'm unable to see how exactly BIP 0341 forbids v1+ segwit from using bech32.

BIP341 has nothing to do with this; it specifies consensus validation rules, not address encoding.

BIP350 however specifies that Bech32m must be used for v1+ segwit, and Bech32 for v0 segwit. The older BIP173 specified that all witness outputs (v0 and v1+) use Bech32.

---

> Does consensus allow combining v1+ segwit programs with the bech32 format?

As far as consensus rules are concerned, addresses do not exist (only scripts do). Conversion from/to addresses is something done by wallets (and other user-facing software), and thus if such software follows BIP350, they'd use Bech32m for v1+ segwit outputs.

Old pre-BIP350 software however might use Bech32 for such outputs, meaning such software won't accept addresses created by BIP350-compliant wallets. This is deliberate (from BIP350):

> Experiments by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by breaking forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.

---

> Does consensus allow combining v0 segwit programs with the bech32m format?

Again unrelated to consensus, but BIP350 does not allow this (and neither does BIP173).


---

