My understanding of calculating a transaction size

Chris!

legendary

Activity: 1382

Merit: 1122

Quote from: pooya87 on April 24, 2017, 12:11:13 AM

Quote from: Chris! on April 23, 2017, 05:09:22 PM

So then the formulae I'm using are close enough that it shouldn't be off by 10% and should at the very least should be a good indication of what the fee should be, right? In the end that's all I'm looking for is an estimate.

as long as you don't have some crazy number of TX_In and TX_Out (something like 300) the fixed amount of bytes you add is 10 (4 version + 1 TxIn count + 1 TxOut count + 4 LockTime).

also as long as you are using a Pay To PubKey Hash and also use Compressed private keys (like the address you have in your profile which has a compressed private key) your formula is correct.

Great then it's good enough for me! I just have some paper wallets that I was wondering what the fees would be if I tried to sweep them some day. This helps a lot. Thanks everyone.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: Chris! on April 23, 2017, 05:09:22 PM

So then the formulae I'm using are close enough that it shouldn't be off by 10% and should at the very least should be a good indication of what the fee should be, right? In the end that's all I'm looking for is an estimate.

as long as you don't have some crazy number of TX_In and TX_Out (something like 300) the fixed amount of bytes you add is 10 (4 version + 1 TxIn count + 1 TxOut count + 4 LockTime).

also as long as you are using a Pay To PubKey Hash and also use Compressed private keys (like the address you have in your profile which has a compressed private key) your formula is correct.

Chris!

legendary

Activity: 1382

Merit: 1122

Quote from: pooya87 on April 20, 2017, 11:31:16 PM

The problem with "making up a formula" is that there are too many factors to consider. for example that 10 byte that we say is fixed, is not really a fixed 10 byte. it is the sum of the following:
4 (fixed) + 1 (variable) + 1 (variable) + 4 (fixed) = 10
although it is rare to have that many outputs to have that 2 bytes instead of 1.

or for example inside the transaction when you say 148 (or 147) * inputs that is if you are not using a multisig.

https://bitcoin.org/en/developer-reference#raw-transaction-format

Version (4 Bytes)
TxIn Count (1B) since you won't have that many outputs to spend

number of inputs *{
Outpoint (36B)
Script Length (1B) the most common cases
ScriptSig(~106-107 B)
Sequence (4B)
}

TxOut Count (1B) since you won't be having more than a couple

number of new outputs *{
Value (8B)
Script Length(1B) the most common cases
Script (25) the most common cases
}

LockTime (4B)

So then the formulae I'm using are close enough that it shouldn't be off by 10% and should at the very least should be a good indication of what the fee should be, right? In the end that's all I'm looking for is an estimate.

pooya87

legendary

Activity: 3472

Merit: 10611

The problem with "making up a formula" is that there are too many factors to consider. for example that 10 byte that we say is fixed, is not really a fixed 10 byte. it is the sum of the following:
4 (fixed) + 1 (variable) + 1 (variable) + 4 (fixed) = 10
although it is rare to have that many outputs to have that 2 bytes instead of 1.

or for example inside the transaction when you say 148 (or 147) * inputs that is if you are not using a multisig.

https://bitcoin.org/en/developer-reference#raw-transaction-format

Version (4 Bytes)
TxIn Count (1B) since you won't have that many outputs to spend

number of inputs *{
Outpoint (36B)
Script Length (1B) the most common cases
ScriptSig(~106-107 B)
Sequence (4B)
}

TxOut Count (1B) since you won't be having more than a couple

number of new outputs *{
Value (8B)
Script Length(1B) the most common cases
Script (25) the most common cases
}

LockTime (4B)

Chris!

legendary

Activity: 1382

Merit: 1122

Quote from: achow101 on April 19, 2017, 09:13:33 AM

Quote from: ?? on ??

Quote from: achow101 on April 18, 2017, 10:13:46 PM

It can vary as much as 4 bytes per input IIRC.

Everything I've seen has indicated that the signature data can vary + or - one byte. I'm not aware of any other variation. Are you sure about the extra 3 bytes of variation? If so, do you know where/why that variation occurs?

It seems I am mistaken.

Ok so if we were to write out the formula what would it be (understanding that of course there is a range)? The 10-26 bytes aren't multiplied by the number of inputs though, was that part still right?

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: ?? on ??

Quote from: achow101 on April 18, 2017, 10:13:46 PM

It can vary as much as 4 bytes per input IIRC.

Everything I've seen has indicated that the signature data can vary + or - one byte. I'm not aware of any other variation. Are you sure about the extra 3 bytes of variation? If so, do you know where/why that variation occurs?

It seems I am mistaken.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Chris! on April 18, 2017, 10:03:49 PM

Ok so after a little reading I think I've finally got this but I wanted to confirm with the experts.

If I have a compressed public key then my transaction size will be calculated:

Code:

148x(inputs) + 34x(outputs) + 10x(inputs)

But I also understand that there could be a 1 byte difference in the input sizes.

~~It can vary as much as 4 bytes per input IIRC.~~

Also, you do not need to do 10x(inputs). There is not an extra 10 bytes per input, rather that is a fixed 10 or so bytes (maximum is actually 26 bytes; depends on the number of inputs and number of outputs).

Quote from: Chris! on April 18, 2017, 10:03:49 PM

If you're using an uncompressed public key then your transaction size would be calculated:

Code:

180x(inputs) + 34x(outputs) + 10x(inputs)

Same comment about the 10x(inputs) as above.

Quote from: Chris! on April 18, 2017, 10:03:49 PM

Will this give me a fairly accurate fee?

It will tell you the size of your transaction fairly accurately, within a couple of bytes, and that won't really matter when it comes to the transaction fee. It's close enough.

Quote from: Chris! on April 18, 2017, 10:03:49 PM

I'm also not sure how to tell if my public key is compressed but I guess I could just check bitaddress.org address info.

A compressed public key will be 32 bytes long, uncompressed is 65. Compressed keys begin with 02 or 03 whereas uncompressed begin with 04.

Chris!

legendary

Activity: 1382

Merit: 1122

Ok so after a little reading I think I've finally got this but I wanted to confirm with the experts.

If I have a compressed public key then my transaction size will be calculated:

Code:

148x(inputs) + 34x(outputs) + 10x(inputs)

But I also understand that there could be a 1 byte difference in the input sizes.

If you're using an uncompressed public key then your transaction size would be calculated:

Code:

180x(inputs) + 34x(outputs) + 10x(inputs)

Will this give me a fairly accurate fee? I'm also not sure how to tell if my public key is compressed but I guess I could just check bitaddress.org address info.

If I'm wrong or missing something let me know.

Assuming I had a compressed public key with 10 inputs and 1 output it would be calculated:

Code:

148x10 +34x1 +10x10 = 1614 bytes

Then let's assume a nice round fee of 100 Satoshis/byte and my fee would be around 161400 Satoshis or 0.001614BTC.

Did I get that right?

Topic: My understanding of calculating a transaction size (Read 997 times)