<p>They will be distinguishable, but they will still be bech32 addresses.</p>
<p>The introduction of Schnorr signatures requires a new type of output. Segwit was designed with such extensibility in mind, and it defines 17 version numbers. Currently, only version 0 is used. Segwit v0 outputs with a 20-byte hash are known as P2WPKH outputs, and v0 outputs with a 32-byte hash are known as P2WSH outputs.</p>
<p>A new version number can be introduced, for example v1, and given semantics through a softfork. Schnorr signatures is one of the changes being considered for a proposal.</p>
<p>However, bech32 addresses literally encode a version number plus a payload, which maps directly to the various versions of segwit outputs.</p>
<p>The version number in Bitcoin bech32 addresses is in the 4th character. For all v0 outputs, that version character is 'q'. For v1 outputs it will be a 'p'.</p>
<p>EDIT June 2022: Taproot was introduced with a slightly different address format than bech32, named bech32m, described in <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="nofollow noreferrer">BIP350</a>. This was done to address a shortcoming in the bech32 checksum algorithm, as well as prevent misinterpretation of taproot addresses as P2WSH (which would lead to loss of funds).</p>

CC BY-SA 4.0
2019-03-01T23:22:18.197Z
Will existing wallets be able to send to version X scripts if they already support bech32 without any implementation changes?
nopara73
CC BY-SA 4.0
2019-04-23T15:26:44.427Z
That depends on the implementation. BIP 173 specifies how to decode a bech32 address to a segwit scriptPubkey which works for any segwit version. But in some implementations outputs with an unknown segwit version non-standard and not broadcasted. Bitcoin Core as of 0.17.3 is such an implementation but as far as I know the plan is to change that behavior. A Schnorr proposal could support P2SH-nested segwit version 1 programs which would allow sending from all notable wallets today.
nickler
CC BY-SA 4.0
2021-12-17T12:38:36.380Z
@nickler Is it possible to create a P2PKH output from a schnorr signature?
yzernik
CC BY-SA 4.0
2022-06-06T16:30:25.660Z
Since this question was answered bech32m addresses were used for SegWit v1 rather than bech32. More details here: https://bitcoinops.org/en/preparing-for-taproot/#bech32m-sending-support
Michael Folkson
CC BY-SA 4.0
2022-06-06T17:36:05.897Z
@MichaelFolkson Good point. Added a comment.
Pieter Wuille
CC BY-SA 4.0
2018-12-17T00:39:16.573Z
2022-06-06T17:35:53.277Z
2022-06-06T17:35:53.277Z
Pieter Wuille
<p>When we (hopefully) soft-fork to Schnorr signatures will the address be indistinguishable from bech32 addresses?</p>

<bech32-address><schnorr-signatures><bip350-bech32m>
Will a Schnorr soft-fork introduce a new address format (i.e. not bech32)
Bertram Lund
# Will a Schnorr soft-fork introduce a new address format (i.e. not bech32)

(Asked by: username_0 on 2018-12-17)

When we (hopefully) soft-fork to Schnorr signatures will the address be indistinguishable from bech32 addresses?

**Tags:** bech32-address, schnorr-signatures, bip350-bech32m


---

## 1 answers

### Answer by username_1 on 2018-12-17. Score: 16 | Accepted answer

They will be distinguishable, but they will still be bech32 addresses.

The introduction of Schnorr signatures requires a new type of output. Segwit was designed with such extensibility in mind, and it defines 17 version numbers. Currently, only version 0 is used. Segwit v0 outputs with a 20-byte hash are known as P2WPKH outputs, and v0 outputs with a 32-byte hash are known as P2WSH outputs.

A new version number can be introduced, for example v1, and given semantics through a softfork. Schnorr signatures is one of the changes being considered for a proposal.

However, bech32 addresses literally encode a version number plus a payload, which maps directly to the various versions of segwit outputs.

The version number in Bitcoin bech32 addresses is in the 4th character. For all v0 outputs, that version character is 'q'. For v1 outputs it will be a 'p'.

EDIT June 2022: Taproot was introduced with a slightly different address format than bech32, named bech32m, described in [BIP350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki). This was done to address a shortcoming in the bech32 checksum algorithm, as well as prevent misinterpretation of taproot addresses as P2WSH (which would lead to loss of funds).

> **Comments:**
> **username_2**: Will existing wallets be able to send to version X scripts if they already support bech32 without any implementation changes?  
> **username_3**: That depends on the implementation. BIP 173 specifies how to decode a bech32 address to a segwit scriptPubkey which works for any segwit version. But in some implementations outputs with an unknown segwit version non-standard and not broadcasted. Bitcoin Core as of 0.17.3 is such an implementation but as far as I know the plan is to change that behavior. A Schnorr proposal could support P2SH-nested segwit version 1 programs which would allow sending from all notable wallets today.  
> **username_4**: @username_3 Is it possible to create a P2PKH output from a schnorr signature?  
> **username_5**: Since this question was answered bech32m addresses were used for SegWit v1 rather than bech32. More details here: https://bitcoinops.org/en/preparing-for-taproot/#bech32m-sending-support  
> **username_1**: @MichaelFolkson Good point. Added a comment.  

---

