5

For transaction not spending SegWit outputs it's straightforward: if I have 1000 Satoshi fee set for 500 byte raw transaction, I end up with 2 s/b fee.

How about transaction containing witness data?

Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.

How accurate is it to say that current transaction fee is 1000 / 400 = 2.5 s/b?

11

Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.

That's not correct.

SegWit replaces the concept of size and maximum block size with weight. The weight of a transaction is defined as 3 times the stripped_size in bytes (excluding the witness) plus the total_size in bytes (including the witness). The maximum weight of all transactions in a block is 4000000. This is the only limit that matters. Due to the way the weight formula is constructed, it implies that the old rule (stripped_size <= 1000000) is always satisfied. Miners try to get as much fees out of the weight limit they have available, and as a result optimize for fee per weight.

So, transaction sizes don't matter anymore. What matters is their weight. Unfortunately, there is a factor 4 scaling between the two, so you can't easily convert feerates from before SegWit to after. For this reason, the concept of vsize (virtual size) was introduced. It's equal to weight/4. For non-SegWit transactions, their size and vsize are identical. The easiest way to express fees is now to see them as BTC per vbyte (vsize byte).

How accurate is it to say that current transaction fee is 1000 / 400 = 2.5 s/b?

In your example, the weight of your transaction is 3*400 + 500 = 1700. This means its vsize is 425 vbytes. As a result, its feerate is 1000 / 425 = 2.35 sat/vbyte, and it would compete with other transactions at that level.

  • As clear as it gets. Thx – Average Joe Jan 6 '18 at 11:37
  • @pieter-wuille Does Segwit embedded inside P2SH get the benefit of the new concept of size? The following question mentioned that using nested in a legacy P2SH has benefit (although less efficient). I want to understand the meaning. bitcoin.stackexchange.com/questions/62053/… – zono Jan 9 '18 at 4:12
  • Yes, it does, though to a lesser extent. I'll try to write an answer to that question. – Pieter Wuille Jan 9 '18 at 8:04
2
  • Legacy input size: 148 bytes (compressed)
  • Legacy output size: 34 bytes (compressed)

  • Segwit input size: 104 bytes

  • Segwit output size: 32 bytes

so if your transaction has two inputs and one output total size is ~ 246 Bytes, Don't forget about some more additional bytes for transaction header.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.