<p>Sending bitcoins means to lock funds to a specific output script. The output script determines how the funds can later be spent. E.g. if funds were sent to a P2WPKH (Pay to Witness Public Key Hash) address, they can later be spent using a P2WPKH input script. If funds were sent to a P2PKH (Pay to Public Key Hash) address, they have to be spent using a P2PKH input script instead.</p>
<p>The (native segwit) P2WPKH input script has less weight than the P2PKH input script, so receiving funds to P2WPKH addresses will save you fees when you later spend those funds. The output scripts for both are similar in size.</p>
<p><a href="https://i.sstatic.net/XGdY9.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XGdY9.png" alt="enter image description here" /></a></p>
<p>Funds of any type of input can be assigned to outputs of any type in a transaction. You can even mix: spending a native segwit and a non-segwit input, and sending to a non-segwit and a native segwit output in one transaction works fine.<br />
However, as you say, some wallets may not support sending to native segwit addresses. In that case, the receiver should fall back to providing a backwards compatible P2SH-wrapped segwit address which is still cheaper than non-segwit but can be sent to by almost all wallets. You can track native segwit adoption on <a href="https://bitcoinops.org/en/compatibility/#segwit-addresses" rel="nofollow noreferrer">Bitcoin Optech's Compatibility Matrix</a> or <a href="https://whensegwit.com" rel="nofollow noreferrer">whensegwit.com</a>.</p>
<blockquote>
<p>My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?</p>
</blockquote>
<p>Correct. A wallet that does not know how to interpret native segwit addresses would not be able to spend funds received from a native segwit address. This is not a problem in practice, because the receiver provides the spender with the invoice address they want to receive the funds to. The receivers wallet will not generate a native segwit address, when it is unaware of native segwit.</p>

CC BY-SA 4.0
2020-10-23T14:45:13.383Z
2020-10-23T14:51:51.757Z
2020-10-23T14:51:51.757Z
Murch
<p>I have a question regarding Native Segwit addresses. I understand that those addresses are more efficient and that you save on fees when you send BTC from them. However, does it matter which type of address (legacy, segwit, Native Segwit) the recipient uses? Will I get the same fee reduction benefits no matter what?</p>
<p>Also, I often read that many wallets don't properly support Native Segwit addresses. My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?</p>

<address><segregated-witness>
Compatibility questions regarding Native Segwit addresses
Pascal Bergeron
# Compatibility questions regarding Native Segwit addresses

(Asked by: username_0 on 2020-10-23)

I have a question regarding Native Segwit addresses. I understand that those addresses are more efficient and that you save on fees when you send BTC from them. However, does it matter which type of address (legacy, segwit, Native Segwit) the recipient uses? Will I get the same fee reduction benefits no matter what?

Also, I often read that many wallets don't properly support Native Segwit addresses. My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

**Tags:** address, segregated-witness


---

## 1 answers

### Answer by username_1 on 2020-10-23. Score: 3 | Accepted answer

Sending bitcoins means to lock funds to a specific output script. The output script determines how the funds can later be spent. E.g. if funds were sent to a P2WPKH (Pay to Witness Public Key Hash) address, they can later be spent using a P2WPKH input script. If funds were sent to a P2PKH (Pay to Public Key Hash) address, they have to be spent using a P2PKH input script instead.

The (native segwit) P2WPKH input script has less weight than the P2PKH input script, so receiving funds to P2WPKH addresses will save you fees when you later spend those funds. The output scripts for both are similar in size.

[![enter image description here](https://i.sstatic.net/XGdY9.png)](https://i.sstatic.net/XGdY9.png)

Funds of any type of input can be assigned to outputs of any type in a transaction. You can even mix: spending a native segwit and a non-segwit input, and sending to a non-segwit and a native segwit output in one transaction works fine.  
However, as you say, some wallets may not support sending to native segwit addresses. In that case, the receiver should fall back to providing a backwards compatible P2SH-wrapped segwit address which is still cheaper than non-segwit but can be sent to by almost all wallets. You can track native segwit adoption on [Bitcoin Optech's Compatibility Matrix](https://bitcoinops.org/en/compatibility/#segwit-addresses) or [whensegwit.com](https://whensegwit.com).

> My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

Correct. A wallet that does not know how to interpret native segwit addresses would not be able to spend funds received from a native segwit address. This is not a problem in practice, because the receiver provides the spender with the invoice address they want to receive the funds to. The receivers wallet will not generate a native segwit address, when it is unaware of native segwit.


---

