0

I know that the bitcoin fee is calculated based on the number of bytes in a transaction (i.e. satoshi per byte). But what bytes are calculated? The bytes of the encoded/serialized transaction or of the raw transaction?

For example, I have the transaction below. The size of the raw bytes is 192. The encoded(hex) is 384. I used a fee of "1" satoshi to generate it so that I can get a sample of what the size will be like. Would be safe to multiple satoshi with the raw size to get the fee and then re-make the transaction? (e.g. 1000 satoshi * 192 = 192000 satoshi fee).

0100000001433a94862b051af03d6ad033153c937d258f6d501edc35a57b61b855f0b691b022ddb2126b483045022100da9bd107a96990429498df53d963a6b5d26455b180f3742f87c2352805d1bd33022033071d16a9578b765b38d68b51d692c575b9b3ce48e9b93276784e33adfd5a1201210342b992de6ebd9f2d0d522f9559d3ff6388fcdb70095c0f0dfe75811c74437bd1ffffffff01ae130000000000001976a914fafb913a62cce4c017e986d07d9a1c25d30e2ace88ac00000000
Improve this question

2 Answers 2

Reset to default
1

One hexadecimal digit represents 4 bits which is half of a byte (8 bits). Therefore, the raw byte length of a transaction is half of the length of its hexadecimal representation.

In your case, there are 384 hexadecimal digits, and the raw byte length of the transaction is 192 bytes. Depending on whether the fee rate is given in [satoshi/byte], [satoshi/kilobyte] or [BTC/kilobyte], you need to apply the corresponding unit conversions. Note that Bitcoin uses kilobyte here for 1,000 bytes.

There are two more pitfalls here:

  1. Since the activation of segwit, fees are paid per weight, not raw byte length. In practice this means that transactions with segwit inputs require less fees than what would correspond to their raw byte length. I've explored the topic further here: Medium: PSA: Wrong fee rates on block explorers

  2. Signatures in Bitcoin have a variable length. It is therefore common that your fee estimate is off by a byte or two, especially if your transaction has few inputs. You can get around that by either using a slightly conservative estimate (which is for example how this is addressed in Bitcoin Core), or by repeating the signature for the transaction until the size fits your estimate.

Improve this answer
0

generally yes. I got this here from the forum (lost the link):

fee = (n_inputs * 148 + n_outputs * 34 + 10) * price_per_byte

SegWit slightly changes this, where instead of paying per byte, you pay per unit of weight: 1 byte of non witness data = 4 weight, 1 byte of witness data = 1 weight.

Improve this answer
2
  • I understand that size (raw bytes) may be deterministic but I would rather prefer to calculate it using the len(raw bytes) * price_per byte than other complicated calc like you mentioned (n_inputs * 148 + n_outputs * 34 + 10)
    – Books
    Jan 17, 2018 at 18:51
  • when assembling the raw tx, it is only afterwards the signatures come in. The signatures can be of different length (72, 73 or 74 bytes - I think Pieter last recently mentioned, only the last two appear in the wild), due to R- or S-Value corrections. So before sig, the formula would be a good approach for P2SH or P2PKH tx (SegWit have slight changes). To be absolutly sure, I think one would need to sign the tx, calculate the length, and then adopt the tx fees. But how would one present this to a user interface? And what if many inputs/outputs? At least the values are fixed length.
    – pebwindkraft
    Jan 17, 2018 at 19:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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