Understanding the differences between SegWit and Native SegWit addresses regarding transaction fees

These days, picking SegWit instead of Legacy for our transactions is a no-brainer since everyone wants cheaper and faster options. But this thread is not about Legacy; it’s about the two types of addresses: SegWit and Native SegWit. When we compare SegWit and Native SegWit addresses, a lot of articles only talk about the basic differences, often skipping some crucial details. They mainly focus on how the transaction data is stored on the blockchain, but I’m really looking to understand the technical aspects behind both, if there are any. SegWit was introduced to tackle transaction malleability and boost transaction capacity by increasing block size. This was achieved by separating the transaction data from its signature data, so only the transaction data is used to calculate the transaction ID. In the images I found from a Mycelium wallet, Bech32 represents a Native SegWit address, while P2SH is for a SegWit address. I looked into Bech32 and found out it’s just an encoding method for the characters in Native SegWit addresses. SegWit addresses, or P2WPKH, utilize the P2SH script function. But honestly, this info doesn’t really explain why Native SegWit addresses have lower transaction fees.

Just because P2SH pushes more data on-chain. Native Segwit: bc1qspfmyevfh5apy66gqptg62h0c64pdyt8wdxx75 1. On-chain push in legacy output: 00149248e4c6f4ead8800bce8d27362d02d1b72be56d 2. On-chain push in legacy input: none needed, it is empty 3. On-chain push in witness space: 3.1. Signature: 304402201e50aca2e04654bdc7d66338de9ff3a1e675c1ccec4201166603eb2c8a3ff9700220415 d4adcea50222e804b9a32a25b38ef3aae1ea7631d32cb0a716e3caa07c2c001 3.2. Public key: 0291faef8450b7f98d5bf16a1296af64bfdb90bbba792ebb2f2b1e82c366e103bb P2SH: 34XMxmELaDfXqevFWAM444WiCjrvA9sQXi 1. On-chain push in legacy output: a9141f14f1e0f2e741fed164960c8aaa673d24f87c0c87 2. On-chain push in legacy input: 16001442a62f734aa294c1aed7896d04d3bc979c77461c 3. On-chain push in witness space: 3.1. Signature: 30450221009498e0b0f30c2d9fded463eb81f9959d6de6dd9dbf3f623128f9ba13b9a5457602207 422b6b8f2416b41a5f5bcea13a87da38b4ecd15e52160015cf5cb2ba48240f001 3.2. Public key: 03ec6b23e5dce9b97bb35355d3376c5e89393f759c5db0eaf18b779ee3f3491d59 See? Native Segwit leaves no pushes in legacy input part (point 2), while P2SH always do so. And the consequence is simple: if you push more data, then you pay more fees.

Using words like "separate" or "remove" in this context is misleading and has led to a lot of confusion in the past 7 years. Signature is not separated from the transaction, it is just moved from inputs (after outpoint) to witness (before locktime). It is still part of the transaction. BTW the way new txid is calculated is only addressing malleability not scalability. SegWit introduced a way to increase capacity in a backward compatible way by using this new witness field which stores the signatures and other scripts that used to be in scriptsig. This helps blocks to be bigger than previous cap of 1 MB. It also introduced a new way of calculating size through a new concept called weight. When you use SegWit, your transaction weight can be smaller than legacy transactions. Which means you pay a lower fee because of that. You are basically using this extra size (the additional 3 MB) that wasn't possible before, so you get a discount. That's for native SegWit (like P2WPKH) but when you use the wrapped SegWit (like P2WPKH-P2SH) you are using a workaround that is a combination of SegWit and legacy so the weight value is between the two as well as the fee. So the fee is going to be like this if the script types are similar (eg. not comparing a single sig with multi sig)

Very forward and easy to understand. Now everything is beginning to make sense. Correction noted. I have seen something like wrapped SegWit before, but was wondering how it fits in. You've just explained a scenerio of its application. So good to learn this.

In my understanding, their difference is from signature that helps to reduce transaction size and transaction fee with Native Segwit bech32 because it is more weight efficient in witness data. How is the size of a Bitcoin transaction calculated? Different min transaction values for Bitcoin dust transactions Bitcoin address types compared. The Reference chart at the end has interesting information on changes and trend of different address type usage, existence. Because of cheaper transaction fee, Bech32 and Bech32m address types are increasingly used. Determining the size of the minimum-input of an UTXO. Figure 9. Generic transaction structure. and Table 3. Minimum-input size summary.