<p>It is important to understand that the transaction fee you have to pay to <em>make</em> a payment is based on how you <em>received</em> the funds you are using to make the payment. The outgoing payment (assuming it's only to one place) is always going to be the same size. So the 'out' part will always have two standard "pay to address" scripts. The size of the 'in' part will depend on how many outputs you have to claim, which depends on how you got the funds.</p>

<p>So I wouldn't suggest charging the transaction fee to the person withdrawing, because then you're billing the user based on parameters the user has no control over. The transaction fees depend on things like how many transaction outputs you have to gather to get the coins needed. That's completely dependent on how your funds are structured.</p>

<p>Imagine if you walk into a candy store and are told that a candy bar is 35 cents, but then when they rang you up, they tacked on a 15 cent fee. When you asked them what it was for, they explained that the previous customer had paid them all in pennies, and in order to give you your change, they'd have to count all those pennies, and that takes more time.</p>

<p>I think you'd be pissed because that fee has to do with how their funds are structured and has nothing to do with your transaction. You would expect them to either eat those costs or build them into their prices. You wouldn't expect them to figure out exactly how much it costs to sell you a candy bar based on their internal business configuration and charge you personally based on that.</p>

<p>Either charge a flat fee per withdrawal (.01 BTC is currently common) or cover the transaction fees yourself. And use <a href="https://bitcoin.stackexchange.com/questions/1188/what-strategies-can-an-e-wallet-use-in-order-to-reduce-transaction-fees/1191#1191">sensible strategies to reduce transaction fees</a>. But, in my opinion, you really don't want to pass on that kind of cost to a customer.</p>

CC BY-SA 3.0
2017-11-02T15:11:42.887Z
With the price of BTC at $7200, paying a fee of $72.00 for something small kinda sticks in the craw. .01 BTC/transaction is no longer a good idea.
Drew Wirkowski
CC BY-SA 3.0
2012-02-25T03:41:25.223Z
"So the 'out' part will always have two standard "pay to address" scripts" isn't true.  Sometimes you have the exact amount in a single coin and can avoid receiving change.  See http://blockexplorer.com/tx/ef3d028f328147af14e96b3d0ed3500118faf05081cfd6f533de6af44eb5b9aa#i4577701 for example, which I created with the official client.
Chris Moore
CC BY-SA 3.0
2011-09-22T05:22:33.380Z
2011-09-22T05:29:20.203Z
2017-04-13T12:47:32.940Z
David Schwartz
<p>Assuming all the inputs you are spending are from regular "pay to address" transactions, each input will contribute 180 (plus or minus 1) bytes to the transaction.  Each output adds 34 bytes to the transaction.  And there's a fixed extra 10 bytes which are always present.</p>

<p>The "plus or minus 1" comes from the fact that each input needs a signature to be claimed.  The signature contains two 32 byte values, but if either of the values has a first byte of <code>0x80</code> or more, it has a <code>0x00</code> byte prepended to it.  So I'm assuming one of the two is high and the other is low.  That way I'm off by at most one byte per input.</p>

<p>So if your transaction has <code>in</code> inputs and <code>out</code> outputs, the transaction size, in bytes will be:</p>

<pre><code>in*180 + out*34 + 10 plus or minus 'in'
</code></pre>

<p>For example, <a href="http://blockexplorer.com/tx/57488f3f8c3961dfa6e76b361aabb1f8e82fb08ea41746604ee6566dd52830de">this transaction</a> has 40 inputs and 16 outputs.  That gives us a transaction size of</p>

<pre><code>40*180 + 16*34 + 10 +- 40
</code></pre>

<p>i.e. <code>7754 +- 40</code> bytes.  The actual size is <code>7761</code> bytes.</p>

<p>If the inputs are from "pay to pubkey" transactions then the inputs are smaller than for "pay to address" transactions.  And this will be different also for "pay to script hash" inputs too, depending on how/if that's implemented.</p>

<p>Edit: <a href="http://blockexplorer.com/tx/d9804de366aa4c2a01565c3a3c8aa2ea20baafc276dc875f80b9044841205333">This transaction</a> was made with bitcoins stolen in <a href="http://arstechnica.com/business/news/2012/03/bitcoins-worth-228000-stolen-from-customers-of-hacked-webhost.ars?clicked=related_right">the Linode heist</a> and shows a transaction size of <a href="http://www.urbandictionary.com/define.php?term=1337">1337</a>, possibly a deliberate use of <a href="http://en.wikipedia.org/wiki/Leet">leetspeak</a> in the blockchain.</p>

<p>Edit2: Now that compressed public keys are commonplace, each input is 32 bytes shorter and so the transaction size is now:</p>

<pre><code>in*148 + out*34 + 10 plus or minus 'in'
</code></pre>

CC BY-SA 3.0
2014-04-01T09:45:34.713Z
Is the formula described in `Edit2` up to date with bitcoin v.0.9.0?
Doug Peters
CC BY-SA 3.0
2014-04-21T21:47:03.543Z
What about the size of P2SH ?
Farghaly
CC BY-SA 3.0
2017-07-06T18:57:02.347Z
How do you find out how many inputs and outputs there are?
Marc Alexander
CC BY-SA 4.0
2018-07-18T18:32:26.840Z
@MarcAlexander see `In-Counter` and `Out-Counter`: https://en.bitcoin.it/wiki/Transaction#Input
JBaczuk
CC BY-SA 3.0
2012-02-25T04:13:15.063Z
2013-02-04T23:13:12.140Z
2013-02-04T23:13:12.140Z
Chris Moore
<p>Here are some calculations based on the <a href="https://en.bitcoin.it/wiki/Protocol_documentation#tx" rel="nofollow noreferrer">Protocol Documentation</a>.</p>

<p>A Bitcoin Transaction is composed of the following:</p>

<ul>
<li>Version (4 Bytes)</li>
<li>TxIn Count (1 ~ 9B)</li>
<li>For each TxIn:

<ul>
<li>Outpoint (36B)</li>
<li>Script Length (1 ~ 9B)</li>
<li>ScriptSig(?)</li>
<li>Sequence (4B)</li>
</ul></li>
<li>TxOut Count (1 ~ 9B)</li>
<li>For each TxOut:

<ul>
<li>Value (8B)</li>
<li>Script Length(1 ~ 9B)*</li>
<li>Script (?)*</li>
</ul></li>
<li>LockTime (4B)</li>
</ul>

<p>Assuming a standard P2SH/P2PKH transaction is created, the script length marked in asterisk will be bound to 1byte as the Script Length is encoded as a variable integer; while the script size marked in asterisks will be bound to 24bytes as it will only contain a script hash.</p>

<p>So, in summary, we can assume that the maximum bound of each TxOut to be 34 
bytes if we are paying to a P2SH/P2PKH address, since there are 4 opcodes in each output script. A great breakdown can be found <a href="https://bitcoin.stackexchange.com/questions/32639/why-does-the-default-miner-implementation-use-pay-to-pubkey/32642#32642-">here</a>.</p>

<p>Assuming we are spending P2PKH outpoints for our TxIn. Our ScriptSig (composed of a 72byte DER Encoded Transaction Signature + 33byte Public Key) would be 146bytes in size and our script length will only consume 1byte as the size of the ScriptSig is less than 0xFD. </p>

<p>Therefore, a standard P2PKH/P2SH transaction spending a <strong>ONE</strong> UTXO redeemable with a basic ScriptSig paying to only <strong>ONE</strong> output is 189bytes. Otherwise, we can also further generalise this to:</p>

<p><code>in</code> marks the number of TxIns</p>

<p><code>out</code> marks the number of TxOuts</p>

<p>Assuming that <code>in</code> &lt; 254 and <code>out</code> &lt; 254. </p>

<p>Size of P2SH/P2PKH Transaction = <code>in</code> * 146 + <code>out</code> * 33 + 10</p>

<p>Computing the size of P2SH/P2PKH transaction that is being funded with complex inputs (i.e. UTXOs spendable with M-of-N signatures, hashed-timelocked contracts) is inherently difficult and is dependent on the complexity of the redeemScript used to produce the scriptHash of the prior P2SH transaction. </p>

CC BY-SA 4.0
2016-07-05T22:21:29.070Z
2018-08-13T12:27:57.983Z
2018-08-13T12:27:57.983Z
rny
<p>I know that I pay the transaction fee per kB, so how can I calculate how large the transaction will be before I send it via the RPC api. I run a site using bitcoins, and I cannot let the user's balance go negative, so I need to know if they have enough balance to cover the cost.</p>

<transaction-fees><p2sh><p2pkh><transaction-weight>
How to calculate transaction size before sending (Legacy Non-Segwit - P2PKH/P2SH)
macintosh264
# How to calculate transaction size before sending (Legacy Non-Segwit - P2PKH/P2SH)

(Asked by: username_0 on 2011-09-22)

I know that I pay the transaction fee per kB, so how can I calculate how large the transaction will be before I send it via the RPC api. I run a site using bitcoins, and I cannot let the user's balance go negative, so I need to know if they have enough balance to cover the cost.

**Tags:** transaction-fees, p2sh, p2pkh, transaction-weight


---

## 3 answers

### Answer by username_3 on 2012-02-25. Score: 66

Assuming all the inputs you are spending are from regular "pay to address" transactions, each input will contribute 180 (plus or minus 1) bytes to the transaction. Each output adds 34 bytes to the transaction. And there's a fixed extra 10 bytes which are always present.

The "plus or minus 1" comes from the fact that each input needs a signature to be claimed. The signature contains two 32 byte values, but if either of the values has a first byte of `0x80` or more, it has a `0x00` byte prepended to it. So I'm assuming one of the two is high and the other is low. That way I'm off by at most one byte per input.

So if your transaction has `in` inputs and `out` outputs, the transaction size, in bytes will be:

```
in*180 + out*34 + 10 plus or minus 'in'

```

For example, [this transaction](http://blockexplorer.com/tx/57488f3f8c3961dfa6e76b361aabb1f8e82fb08ea41746604ee6566dd52830de) has 40 inputs and 16 outputs. That gives us a transaction size of

```
40*180 + 16*34 + 10 +- 40

```

i.e. `7754 +- 40` bytes. The actual size is `7761` bytes.

If the inputs are from "pay to pubkey" transactions then the inputs are smaller than for "pay to address" transactions. And this will be different also for "pay to script hash" inputs too, depending on how/if that's implemented.

Edit: [This transaction](http://blockexplorer.com/tx/d9804de366aa4c2a01565c3a3c8aa2ea20baafc276dc875f80b9044841205333) was made with bitcoins stolen in [the Linode heist](http://arstechnica.com/business/news/2012/03/bitcoins-worth-228000-stolen-from-customers-of-hacked-webhost.ars?clicked=related_right) and shows a transaction size of [1337](http://www.urbandictionary.com/define.php?term=1337), possibly a deliberate use of [leetspeak](http://en.wikipedia.org/wiki/Leet) in the blockchain.

Edit2: Now that compressed public keys are commonplace, each input is 32 bytes shorter and so the transaction size is now:

```
in*148 + out*34 + 10 plus or minus 'in'

```

> **Comments:**
> **username_4**: Is the formula described in `Edit2` up to date with bitcoin v.0.9.0?  
> **username_5**: What about the size of P2SH ?  
> **username_6**: How do you find out how many inputs and outputs there are?  
> **username_7**: @username_6 see `In-Counter` and `Out-Counter`: https://en.bitcoin.it/wiki/Transaction#Input  

---

### Answer by username_8 on 2016-07-05. Score: 26

Here are some calculations based on the [Protocol Documentation](https://en.bitcoin.it/wiki/Protocol_documentation#tx).

A Bitcoin Transaction is composed of the following:

* Version (4 Bytes)
* TxIn Count (1 ~ 9B)
* For each TxIn:
  + Outpoint (36B)
  + Script Length (1 ~ 9B)
  + ScriptSig(?)
  + Sequence (4B)
* TxOut Count (1 ~ 9B)
* For each TxOut:
  + Value (8B)
  + Script Length(1 ~ 9B)\*
  + Script (?)\*
* LockTime (4B)

Assuming a standard P2SH/P2PKH transaction is created, the script length marked in asterisk will be bound to 1byte as the Script Length is encoded as a variable integer; while the script size marked in asterisks will be bound to 24bytes as it will only contain a script hash.

So, in summary, we can assume that the maximum bound of each TxOut to be 34
bytes if we are paying to a P2SH/P2PKH address, since there are 4 opcodes in each output script. A great breakdown can be found [here](https://bitcoin.stackexchange.com/questions/32639/why-does-the-default-miner-implementation-use-pay-to-pubkey/32642#32642-).

Assuming we are spending P2PKH outpoints for our TxIn. Our ScriptSig (composed of a 72byte DER Encoded Transaction Signature + 33byte Public Key) would be 146bytes in size and our script length will only consume 1byte as the size of the ScriptSig is less than 0xFD.

Therefore, a standard P2PKH/P2SH transaction spending a **ONE** UTXO redeemable with a basic ScriptSig paying to only **ONE** output is 189bytes. Otherwise, we can also further generalise this to:

`in` marks the number of TxIns

`out` marks the number of TxOuts

Assuming that `in` < 254 and `out` < 254.

Size of P2SH/P2PKH Transaction = `in` \* 146 + `out` \* 33 + 10

Computing the size of P2SH/P2PKH transaction that is being funded with complex inputs (i.e. UTXOs spendable with M-of-N signatures, hashed-timelocked contracts) is inherently difficult and is dependent on the complexity of the redeemScript used to produce the scriptHash of the prior P2SH transaction.


---

### Answer by username_1 on 2011-09-22. Score: 21

It is important to understand that the transaction fee you have to pay to *make* a payment is based on how you *received* the funds you are using to make the payment. The outgoing payment (assuming it's only to one place) is always going to be the same size. So the 'out' part will always have two standard "pay to address" scripts. The size of the 'in' part will depend on how many outputs you have to claim, which depends on how you got the funds.

So I wouldn't suggest charging the transaction fee to the person withdrawing, because then you're billing the user based on parameters the user has no control over. The transaction fees depend on things like how many transaction outputs you have to gather to get the coins needed. That's completely dependent on how your funds are structured.

Imagine if you walk into a candy store and are told that a candy bar is 35 cents, but then when they rang you up, they tacked on a 15 cent fee. When you asked them what it was for, they explained that the previous customer had paid them all in pennies, and in order to give you your change, they'd have to count all those pennies, and that takes more time.

I think you'd be pissed because that fee has to do with how their funds are structured and has nothing to do with your transaction. You would expect them to either eat those costs or build them into their prices. You wouldn't expect them to figure out exactly how much it costs to sell you a candy bar based on their internal business configuration and charge you personally based on that.

Either charge a flat fee per withdrawal (.01 BTC is currently common) or cover the transaction fees yourself. And use [sensible strategies to reduce transaction fees](https://bitcoin.stackexchange.com/questions/1188/what-strategies-can-an-e-wallet-use-in-order-to-reduce-transaction-fees/1191#1191). But, in my opinion, you really don't want to pass on that kind of cost to a customer.

> **Comments:**
> **username_3**: "So the 'out' part will always have two standard "pay to address" scripts" isn't true.  Sometimes you have the exact amount in a single coin and can avoid receiving change.  See http://blockexplorer.com/tx/ef3d028f328147af14e96b3d0ed3500118faf05081cfd6f533de6af44eb5b9aa#i4577701 for example, which I created with the official client.  
> **username_2**: With the price of BTC at $7200, paying a fee of $72.00 for something small kinda sticks in the craw. .01 BTC/transaction is no longer a good idea.  

---

