Bitcoin Forum
July 23, 2024, 08:27:20 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Low tx fees - Technical difference between SegWit and Native SegWit addresses?  (Read 100 times)
Felicity_Tide (OP)
Member
**
Offline Offline

Activity: 98
Merit: 121

cout << "Bitcoin";


View Profile
June 16, 2024, 04:32:59 AM
Merited by vjudeu (1)
 #1

Choosing SegWit over Legacy for most(if not every) of our transactions is no longer a decision to contemplate on as everyone seeks cheaper and fast transactions these days. Though, this thread have nothing to do with Legacy, but focuses on two addresses: SegWit and Native SegWit.

When we look at the difference between SegWit and Native SegWit addresses, most articles prefer to publish only the primary (basic) difference between them, with a possibility of leaving out some of the key points. They only tend to focus on the difference between how their transaction data are stored on the Blockchain. but my primary aim here is to understand the technicalities behind both, if there is.

The introduction of SegWit was intended to fix transaction malleability and increase transaction capacity for the purpose of increasing block size. This could only be done by separating transaction data from its corresponding signature data, leaving just the transaction data as the only means of calculating the transaction ID.


Image from a mycelium wallet

From the two images above, Bech32 is enclosed in parentheses representing a Native SegWit address, while P2SH is also enclosed in parentheses representing a SegWit address. Upon checking the meaning of Bech32, I discovered that it is just an encoding scheme that governs the set of characters found in every Native SegWit address. SegWit addresses which are also known as P2WPKH, make use of the P2SH script function. These observations are literally not enough to explain the technical difference to why native segWit address have a lower tx fee compare to a compatible segWit as most online articles would speculate.

My Question:
1. Apart from the basic differences between these two, what do you think could be the technical factor to why Native SegWit address have lower tx fee than SegWit?.



Please note that I haven't observed this personally, but just asking based on general speculation.


I am 100% open to correction as I still see myself as a learner. Pardon any of my error and share your personal opinion. You might want to also DOYR after reading this.
vjudeu
Hero Member
*****
Offline Offline

Activity: 782
Merit: 1876



View Profile
June 16, 2024, 05:05:31 AM
Merited by ABCbits (5), NeuroticFish (4), pooya87 (4), hosseinimr93 (4), Felicity_Tide (2), HeRetiK (1), nc50lc (1)
 #2

Quote
what do you think could be the technical factor to why Native SegWit address have lower tx fee than SegWit?
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.

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
pooya87
Legendary
*
Offline Offline

Activity: 3514
Merit: 10715



View Profile
June 16, 2024, 05:08:57 AM
Merited by NeuroticFish (4), ABCbits (4), hosseinimr93 (4), Felicity_Tide (1)
 #3

The introduction of SegWit was intended to fix transaction malleability and increase transaction capacity for the purpose of increasing block size. This could only be done by separating transaction data from its corresponding signature data, leaving just the transaction data as the only means of calculating the transaction ID.
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.

Quote
1. Apart from the basic differences between these two, what do you think could be the technical factor to why Native SegWit address have lower tx fee than SegWit?.
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)
Code:
Legacy > Wrapped SegWit > Native SegWit

P2PKH > P2WPKH-P2SH > P2WPKH

█████████████████████████
████████▀▀████▀▀█▀▀██████
█████▀████▄▄▄▄████████
███▀███▄███████████████
██▀█████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
██▄███████████████▀▀▄▄███
███▄███▀████████▀███▄████
█████▄████▀▀▀▀████▄██████
████████▄▄████▄▄█████████
█████████████████████████
 
 BitList 
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
REAL-TIME DATA TRACKING
CURATED BY THE COMMUNITY

.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
 
  List #kycfree Websites   
Felicity_Tide (OP)
Member
**
Offline Offline

Activity: 98
Merit: 121

cout << "Bitcoin";


View Profile
June 16, 2024, 08:52:26 AM
 #4

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.

Very forward and easy to understand. Now everything is beginning to make sense.

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.

Correction noted.

Quote
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)
Code:
Legacy > Wrapped SegWit > Native SegWit

P2PKH > P2WPKH-P2SH > P2WPKH

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.
MusaMohamed
Sr. Member
****
Offline Offline

Activity: 966
Merit: 303



View Profile
June 17, 2024, 02:59:09 AM
Last edit: June 17, 2024, 03:16:53 AM by MusaMohamed
 #5

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!