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?
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.
Legacy output size: 34 bytes (compressed)
Segwit input size: 104 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.
