Topic: A common myth- Segwit Reduce Fees (Read 411 times)

Nice things to do when you have Segwit.

1. Batch as many transactions together as you can, if you can't (because some sites don't like different outputs in the same tx for the same account) then there's not much you can do but continue using segwit for the next tx.

2. If you run an exchange, give incentives to users who withdraw to native segwit addresses, such as lower fees or lower transaction fees, then also do batches. Those willing to wait a little bit will get lower fees and the exchange can do a batch withdrawal. A good idea would be to allow users to wait up to 10 minutes, so what will happen is a lot of other users will get included in this batch, and then they see their withdrawal after 10 minutes, everyone gets charged less. If a user says "wait longer so I pay even less", that depends on how the site is programmed then to do this kind of thing.

But obviously ScriptSig isn't covered by the signature, since the signature can't sign itself. But ScriptSig is still hashed as part of the TxID, and so this introduces a transaction malleability vulnerability. SegWit fixes this by moving scripts and signatures to the "witness" field and excluding it from being used to calculate the TxID.

You guys are really going overboard with his whole myth thing.    Let's not forget that this whole SegWit thing was part of a whole scaling war that was going on back then and the main talking point was how legacy Bitcoin was too slow and expensive.    --< Roger Ver choir >--

It does not matter if it was not developed to reduce transaction fees, because a indirect result of that was that spam attacks were becoming a non-issue with the introduction of SegWit and the fees went down. We all benefited as a result of this and we have a functional payment alternative now.  

you said this in reverse. in a transaction (assuming it is using SIGHASH_ALL flag, as is the case with majority of transactions) everything is signed since you want to ensure nothing in the tx changes. but to compute the transaction ID for legacy you hash everything but for a tx containing witness you hash everything except witness.

if a node changes anything from a transaction apart from signature (eg. changing locktime) the signature becomes invalid. the only thing they used to be able to change was certain formatting, ... that didn't affect anything. for example you could take the signature and change its DER encoding while still reporting the same r and s (same signature) hence changing the TX ID but not changing the signature.
there is a bunch of malleability fixes that have been happening for a long time even before SegWit, this was an example. not sure which one(s) SegWit solved though.

Not all the data in a transaction is covered by the signature when it is signed, but all the data in a transaction is used when hashing the transaction to get the transaction ID (TxID). This means that a malicious node or party could change some of the data which is not covered by the signature, which would therefore change the hash and change the TxID, whilst leaving the signature still valid. The transaction could still be confirmed as the signature was still valid, but it would be confirmed under a different TxID as some of the other data included in the hash had been changed.

What SegWit essentially does is move this malleable data to a new field know as the "witness", and excludes it from being used in the hash to calculate the TxID. This means that if anyone changes it, the TxID won't change.

Transaction malleability is an issue for chains of unconfirmed transactions. Let's say you make an transaction, say TxID 0, which is still unconfirmed. I see this unconfirmed transaction, and sign a new transaction using those unconfirmed inputs, let's call it TxID 1. In the meantime, you could change some of the data in TxID 0, which means the transaction would still complete, but would do so under a different hash. My TxID 1 would now be invalid, because the hash of TxID 0 on which it was based, had been changed.

Before you fund a channel on the Lightning Network, both parties involved are required to sign a commitment transaction which would return the funds to you in the case of the other party being uncooperative. If the other party was able to alter your malleable funding transaction, then it would still confirm but with a different TxID, and now the commitment transaction to return those funds to you would become invalid. The other party would then be able to just keep your funds, and your commitment transaction to return them - which is now based on the wrong TxID - wouldn't work. So for that reason, transaction malleability required fixing to allow Lightning to run smoothly.

I don't know exactly how this works, but segwit also fixed some problems related to malleability in the Bitcoin network.

Without segwit lightning network would not be possible. This is why bch doesn't have a solution like the lightning network (bch was against segwit implementation)
https://bitcointechtalk.com/transaction-malleability-explained-b7e240236fc7?gi=e618b3724819

Batching transactions will save on transaction fees whether or not you are using SegWit addresses, and the more inputs and/or outputs you batch in to a single transaction, the more fees will be saved. Batching legacy transactions will still save you money, but using SegWit will result in saving even more.

You don't need to batch to save money with SegWit though. Anyone can save by using SegWit transactions. Here is a standard 1-input-2-output transaction from a legacy address to a legacy address, with a legacy address as change: https://blockchair.com/bitcoin/transaction/e23802807b0f9f72a14a55f3858ccc1863b93745cc0d93e2369f87b80b0ed746. It has a weight of 904 units. They paid a fee of 6293 sats, which gave them a rate of 27.8 sats/vbyte.

And now here is a standard 1-input-2-output transaction, from the very same block, from a SegWit address to a legacy address, with a SegWit address as change: https://blockchair.com/bitcoin/transaction/9ec12a1bede7c073a7701cdd1169c0fa71ec717dce3297781778520658134243. It has a weight of only 576 units. They paid a fee of 4298 sats, which gave them a rate of 29.8 sats/vbyte.

So despite only paying 30% less in fees, the SegWit transaction still ended up with a higher fee per vbyte and so potentially could have confirmed faster than the legacy transaction.

Isn't it working like transaction grouping when effect of reducing size can be felt by full?
I mean it lowers fee a lot but only to big sites like exchanges that can batch many transactions together reducing size by much (lower fees)?

It's not 4 MB (byte unit), but 4 million weight (Weight unit). Block size (in byte unit) highly depends on how many SegWit transaction in a block.


But since bitcoin hashrate increasing most of the times, actual average/mean block time is somewhere between 9.4 to 9.6 minutes.

On average. It is designed to give us 2016 blocks every 2 weeks.

Not really. As I said in the thread you linked to, SegWit was initially designed to fix the transaction malleability bug, not to reduce transaction size.

The transaction is the same size in bytes, it is just counted differently so has a smaller weight. The data also isn't removed, just moved. Legacy transactions and non witness data weigh 4 units per byte, but witness data (the part which has been moved) only weighs 1 unit per byte. So the transaction is more or less the same size in bytes, but is smaller in terms of weight units.

Since everything has already been explained regarding SegWit, we may also break the misconception that a new block can only be created every 10 minutes. This is just the average time that is usually added when talking about new blocks, but the time between 2 blocks can be only 1 minute (maybe even less?), or 30+ minutes sometimes.

Often new users do not understand why this is happening, but the time between blocks is really random and this should be accepted. What should always be emphasized is that before each transaction is sent, the mempool size should be checked and accordingly to that the fee should be adjusted.


https://www.blockchain.com/btc/blocks

Not only that, the biggest positive benefit can be achieved if the majority of the users started to use SegWit addresses instead of Legacy.

I made a visual representation of this (not indicating the actual block size, etc.):


As you can see, the more SegWit data, the more transactions we can fit in a block.

Legacy data was represented by linked 4 purple dots because its virtual size is 4byte(weight)/byte;
While SegWit Data was represented by 1 green dot because its virtual size is 1byte(weight)/byte.
So, if there's more transactions can be processed, incidents like "mempool clogging" will be minimized;
thus, another way of "lowering tx fees".

You can check the stats by looking at the current block size (not virtual), higher block size means that there's more SegWit data in that particular block.
Or just check blockchain.com's charts: n-transactions-per-block and/or avg-block-size as both spiked after SegWit implementation and block size above 1mb was introduced.

THIS is the misconception about SegWit! the reality is that:
* SegWit does not reduce transaction size.
* SegWit does not remove anything from transaction.
* The percentage also doesn't make sense to me.

what Segregated Witness does, is that it first changed the way sizes are calculated from "size" to "weight", then introduced a new transaction format that contained a new field called "the witness". this new transaction format has a smaller weight compared to the legacy format and since the new fees are calculated based on this virtual size, you end up paying a lower fee.
otherwise SegWit transaction sizes are either the same as legacy with same number of input/output or they are bigger.


you may want to see how the transactions look. a simplified look of a legacy transaction is like the following, you have your fixed fields such as version and locktime and you have your signature, txin (outpoint+signature) and txouts (amount+scriptpub).
[version][outpoint][signature][txout][locktime]
assuming you change the input (txin) from a legacy (eg. P2PKH) input to a SegWit input (P2WPKH) your transaction structure would change to this second line below:

[version]      [outpoint][signature][txout]         [locktime] <-- P2PKH
[version][flag][outpoint]  [0x00]   [txout][witness][locktime] <-- P2WPKH

as you can see your "SegWit" transaction has extra data that is increasing its size. first is the "flag" (that is 2 bytes), then there is the 1 byte leftover to fill the [signature] (ie. scriptsig) then there is the witness field which has the signature (assume same size) but with an additional byte indicating the item count. so the total actual size in bytes is bigger.
(2+1+1 = 4 bytes extra).

now if the input was a P2SH-P2WPKH (SegWit address starting with 3 aka nested SegWit) the [signature] (ie. scriptsig) would also include an additional script hence an additional size

[version]      [outpoint][signature][txout]         [locktime]
[version][flag][outpoint] [script]  [txout][witness][locktime]

(2+1+1+~20=~24)

This is very much confusing to most of the people. I was wrong until I read the post from o_e_l_e_o

For most of us, Segwit has been implemented to reduce the fee. But it's not implemented for reducing fee.

Let me explain-
We get one block each 10 minutes on bitcoin blockchain and the maximum size of the each block is 1 MB (megabyte), that's mean, miners can only includes transactions with a sum of 1 MB. As a result, when a lot of transaction happens, most of them get stuck because miners can't include each transaction they want, they are limited to 1 block each 10 minutes which will only be a total size of 1 MB.
That's why Segwit was implemented, Segwit, in reality, reduce the transaction size by removing some data from the transaction. It reduces 65% of the data, which on the other hand, increases the block size into almost 4 MB. As a result, it's possible to include a lot of transactions into one single block.

So, what's the fee reducing with Segwit?
Before understating that, you must have to have a little idea on how to calculate transaction size and fee.
Transaction fee depends on the transaction size, if you transaction size is higher, you have to pay more fee. So, if you are using Segwit, your transaction size is likely to be lower than using legacy. As a result, the fee will also be low.

Segwit has indirect affect on the fee but Segwit doesn't mean it's for reducing fee.