<p>Transaction fee is based on the number of bytes in your transaction. Segwit allows to move a significant part of the transaction to a new structure called <code>witness</code>. Bytes in the witness get a 75% discount (4 witness bytes count as 1). </p>

<p>How much you save depends on your transaction. If it involves a lot of signatures that can be moved to the witness you save more. For example with 1sat/byte fee and a 200 byte transaction out of which 120 bytes are signatures, you would pay 200 satoshis using legacy addresses but you would pay 80 + (120/4) = 110 satoshi with segwit.</p>

<blockquote>
  <p>How much cheaper than the "P2SH wrapped SegWit address"? (and why?)</p>
</blockquote>

<p>If you check the box you will get a P2WPKH address else you will get a P2SH-P2WPKH address. Both get the discount. If you want a legacy address you have to specify it via an RPC command or change a value in your config file.</p>

<blockquote>
  <p>Don't P2SH wrapped SegWit addresses include check-digits at the end?</p>
</blockquote>

<p>All legacy addresses include a 4-byte checksum which is good for detecting if there is an error or not.</p>

<p>Bech32 uses <a href="https://en.wikipedia.org/wiki/Error_detection_and_correction" rel="nofollow noreferrer">error-correcting codes</a> which are far superior. Instead of a binary output (correct/incorrect) they can find multiple errors, pinpoint the exact wrong character and even correct them automatically (up to a number of errors depending on the code length)</p>

CC BY-SA 4.0
2018-09-05T14:39:38.313Z
About the fee part: the question is about the size difference between P2SH-WP2PKH and native P2WPKH.
MCCCS
CC BY-SA 4.0
2018-09-06T03:13:34.653Z
"and even correct them automatically", no-- they don't correct them. If they did it would destroy the protection against sending funds to wrong places.
G. Maxwell
CC BY-SA 4.0
2018-09-06T10:08:28.363Z
The BIP even explicitly says not to perform the error correction. If your address is wrong, and you know it, you should go back to the receiver and ask for the correct address instead of trying to guess. It is allowed to suggest where the errors may be, though.
Pieter Wuille
CC BY-SA 4.0
2018-09-06T10:55:12.517Z
@G.Maxwell I didn't mean to suggest that you should do it, just that it is a capability of error-correcting codes in general.
Mike D
CC BY-SA 4.0
2018-09-05T14:36:30.180Z
2018-09-05T14:50:53.507Z
2018-09-05T14:50:53.507Z
Mike D
<p>A P2SH-P2WPKH input <a href="https://bitcoin.stackexchange.com/a/111393/5406">weighs</a> 363 WU (90.75 vbytes), and a P2WPKH input <a href="https://bitcoin.stackexchange.com/a/100160/5406">weighs</a> 271 WU (67.75 vbytes) assuming <a href="https://bitcoin.stackexchange.com/q/111660/5406">low-r grinding</a> on each. The outputs take 32 B and 31 B respectively. This means that a P2WPKH UTXO causes 24 vB less transaction weight across its lifecycle than a P2SH-P2WPKH UTXO. This amounts to a 19.55% transaction weight reduction (395 WU vs 491 WU).</p>
<p>Both P2SH-P2WPKH and P2WPKH move the signature and public key information to the witness section of the transaction. This causes that data to be discounted in the weight calculation compared to non-segwit P2PKH outputs which take 724 WU for output and low-r input in sum.</p>
<p>Both address formats use checksums, but as mentioned by other answers, bech32 is specifically designed to maximize error detection for likely transcription errors (a small count of insertions, omissions, and substitutions). Further, bech32 uses only lowercase symbols which removes the error source of mixing up the case of a letter.</p>

CC BY-SA 4.0
2022-12-29T20:05:43.647Z
2022-12-30T16:29:25.093Z
2022-12-30T16:29:25.093Z
Murch
<ol>
<li></li>
</ol>
<p>Native P2WPKH Unspent outputs save <strong>23</strong> bytes as their ScriptSigs are empty instead of <code>0x0014{20-byte-key-hash}</code>.</p>
<p>2)</p>
<p>Yes, there's already a checksum of the same length.</p>
<p>The newer checksum algorithm is</p>
<ul>
<li><p>Faster.</p>
</li>
<li><p><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#checksum-design" rel="nofollow noreferrer">Very high probability of detection guaranteed.</a>.</p>
</li>
<li><p>Can find where the errors are: <a href="http://bitcoin.sipa.be/bech32/demo/demo.html" rel="nofollow noreferrer">http://bitcoin.sipa.be/bech32/demo/demo.html</a> (Press &quot;address with errors&quot;)</p>
</li>
</ul>
<p>Also, you might be interested in the list of <a href="https://bitcoincore.org/en/segwit_wallet_dev/#why-and-how-to-use-native-bech32-p2wpkh-and-p2wsh" rel="nofollow noreferrer">Bech32 Advantages</a>.</p>

CC BY-SA 4.0
2018-09-05T15:16:46.133Z
2022-12-30T08:31:16.927Z
2022-12-30T08:31:16.927Z
MCCCS
<p>In Bitcoin core, when generating a new address for receiving a payment, you get this dialogue:</p>

<p><a href="https://i.sstatic.net/4nAqT.png" rel="noreferrer"><img src="https://i.sstatic.net/4nAqT.png" alt="Receive Address"></a></p>

<p>There is a tick-box for "Generate Bech32 address".</p>

<p>I understand that this is a relatively new feature not yet supported by all wallets. The tooltip help claims that </p>

<blockquote>
  <p>Bech32 addresses ... are cheaper to spend from and offer better protection against typos"</p>
</blockquote>

<ul>
<li>How much cheaper than the "P2SH wrapped SegWit address"? (and why?)</li>
<li>Don't P2SH wrapped SegWit addresses include check-digits at the end?</li>
</ul>

<p>I did find a 52-minute Youtube video where someone with a familiar name was giving a presentation on Bech32 but I'm hoping that it can be explained simply and concisely for the non-technical end-user wondering whether to click that check-box or not.</p>

<bech32-address><transaction-weight><address-format>
Benefits of Bech32 addresses?
RedGrittyBrick
# Benefits of Bech32 addresses?

(Asked by: username_0 on 2018-09-05)

In Bitcoin core, when generating a new address for receiving a payment, you get this dialogue:

[![Receive Address](https://i.sstatic.net/4nAqT.png)](https://i.sstatic.net/4nAqT.png)

There is a tick-box for "Generate Bech32 address".

I understand that this is a relatively new feature not yet supported by all wallets. The tooltip help claims that

> Bech32 addresses ... are cheaper to spend from and offer better protection against typos"

* How much cheaper than the "P2SH wrapped SegWit address"? (and why?)
* Don't P2SH wrapped SegWit addresses include check-digits at the end?

I did find a 52-minute Youtube video where someone with a familiar name was giving a presentation on Bech32 but I'm hoping that it can be explained simply and concisely for the non-technical end-user wondering whether to click that check-box or not.

**Tags:** bech32-address, transaction-weight, address-format


---

## 3 answers

### Answer by username_2 on 2018-09-05. Score: 5 | Accepted answer

Native P2WPKH Unspent outputs save **23** bytes as their ScriptSigs are empty instead of `0x0014{20-byte-key-hash}`.

2)

Yes, there's already a checksum of the same length.

The newer checksum algorithm is

* Faster.
* [Very high probability of detection guaranteed.](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#checksum-design).
* Can find where the errors are: <http://bitcoin.sipa.be/bech32/demo/demo.html> (Press "address with errors")

Also, you might be interested in the list of [Bech32 Advantages](https://bitcoincore.org/en/segwit_wallet_dev/#why-and-how-to-use-native-bech32-p2wpkh-and-p2wsh).


---

### Answer by username_1 on 2018-09-05. Score: 2

Transaction fee is based on the number of bytes in your transaction. Segwit allows to move a significant part of the transaction to a new structure called `witness`. Bytes in the witness get a 75% discount (4 witness bytes count as 1).

How much you save depends on your transaction. If it involves a lot of signatures that can be moved to the witness you save more. For example with 1sat/byte fee and a 200 byte transaction out of which 120 bytes are signatures, you would pay 200 satoshis using legacy addresses but you would pay 80 + (120/4) = 110 satoshi with segwit.

> How much cheaper than the "P2SH wrapped SegWit address"? (and why?)

If you check the box you will get a P2WPKH address else you will get a P2SH-P2WPKH address. Both get the discount. If you want a legacy address you have to specify it via an RPC command or change a value in your config file.

> Don't P2SH wrapped SegWit addresses include check-digits at the end?

All legacy addresses include a 4-byte checksum which is good for detecting if there is an error or not.

Bech32 uses [error-correcting codes](https://en.wikipedia.org/wiki/Error_detection_and_correction) which are far superior. Instead of a binary output (correct/incorrect) they can find multiple errors, pinpoint the exact wrong character and even correct them automatically (up to a number of errors depending on the code length)

> **Comments:**
> **username_2**: About the fee part: the question is about the size difference between P2SH-WP2PKH and native P2WPKH.  
> **username_3**: "and even correct them automatically", no-- they don't correct them. If they did it would destroy the protection against sending funds to wrong places.  
> **username_4**: The BIP even explicitly says not to perform the error correction. If your address is wrong, and you know it, you should go back to the receiver and ask for the correct address instead of trying to guess. It is allowed to suggest where the errors may be, though.  
> **username_1**: @G.username_3 I didn't mean to suggest that you should do it, just that it is a capability of error-correcting codes in general.  

---

### Answer by username_5 on 2022-12-29. Score: 2

A P2SH-P2WPKH input [weighs](https://bitcoin.stackexchange.com/a/111393/5406) 363 WU (90.75 vbytes), and a P2WPKH input [weighs](https://bitcoin.stackexchange.com/a/100160/5406) 271 WU (67.75 vbytes) assuming [low-r grinding](https://bitcoin.stackexchange.com/q/111660/5406) on each. The outputs take 32 B and 31 B respectively. This means that a P2WPKH UTXO causes 24 vB less transaction weight across its lifecycle than a P2SH-P2WPKH UTXO. This amounts to a 19.55% transaction weight reduction (395 WU vs 491 WU).

Both P2SH-P2WPKH and P2WPKH move the signature and public key information to the witness section of the transaction. This causes that data to be discounted in the weight calculation compared to non-segwit P2PKH outputs which take 724 WU for output and low-r input in sum.

Both address formats use checksums, but as mentioned by other answers, bech32 is specifically designed to maximize error detection for likely transcription errors (a small count of insertions, omissions, and substitutions). Further, bech32 uses only lowercase symbols which removes the error source of mixing up the case of a letter.


---

