<p>Each customer's transaction will use the same number of output bytes regardless of whether it pays a public key that was already seen on the network or a new public key, and when you go to spend the outputs, it will take the same number of input bytes to spend them whether they paid different public keys or not.</p>

<p>For that reason, it makes sense to use different receiving public keys to differentiate between customers rather than appending an additional output with an OP_RETURN.</p>

<p>To reduce transaction fee as much as possible, you should reduce the byte size of a transaction as much as possible.  Here are a few things you might be doing already but which (if you aren't doing them) can help:</p>

<ul>
<li><p>Ensure you use compressed public keys (33 bytes) rather than uncompressed public keys (65 bytes).</p></li>
<li><p>If you don't need users to pay addresses but can instead get them to pay arbitrary scripts (e.g. you're using custom software or the BIP70 payment protocol), consider accepting payments using pay-to-pubkey (P2PK) rather than pay-to-pubkey-hash (P2PKH); this will <a href="https://bitcoin.stackexchange.com/questions/32639/why-does-the-default-miner-implementation-use-pay-to-pubkey/32642#32642">save about 24 bytes</a> for each payment.</p></li>
<li><p>When segwit becomes available, switch to using it as miners will be able to fit more segwit transactions in a block than they can fit traditional transactions, so they will likely charge you less fee.</p></li>
<li><p>Combine multiple payments if possible.  If you can get multiple customers to pay you in the same transaction (using something like coinjoin) or if you can pay multiple customers at the same time, you'll produce smaller transactions because you won't need to repeat some fields in a transaction (such as transaction version or locktime).  When paying to your customers, you can save quite a lot because you'll only have one change output no matter how many <em>n</em> customers you pay.</p></li>
</ul>

CC BY-SA 3.0
2016-11-07T08:33:57.870Z
Thanks for this awesome answer. I had to read multiple times your first paragraph to get your point and now I understand how my "design" was totally useless! Your hints about how to reduce fees seems really relevant and are much appreciated!
onepix
CC BY-SA 3.0
2016-11-06T13:01:06.227Z
2016-11-06T13:01:06.227Z
2017-04-13T12:47:33.283Z
David A. Harding
<p>I would like to simulate through "offchain" transactions micro payment. To do so, user will need at the beginning to depose some amount as a "credit". 
My goal is to compress transaction fee as much as possible and the only constraint is a "big" transaction per month to deduce user credit accordingly to their actions.</p>

<p>My thought was to use only one bitcoin private key per month to reduce from n utxo to one in order to compress size from the "input side".
To differentiate user deposit, I was wondering about providing a specific token to user and "asking him" to store it into the OP_RETURN field of his transaction.</p>

<p><a href="https://i.sstatic.net/QXvDM.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/QXvDM.png" alt="enter image description here"></a></p>

<p>It is worth to try or should I use HD wallet as recommanded even if it will increase the "input size" inevitably ?</p>

<transaction-fees>
How to compress transaction fee as much as possible?
onepix
# How to compress transaction fee as much as possible?

(Asked by: username_0 on 2016-11-06)

I would like to simulate through "offchain" transactions micro payment. To do so, user will need at the beginning to depose some amount as a "credit".
My goal is to compress transaction fee as much as possible and the only constraint is a "big" transaction per month to deduce user credit accordingly to their actions.

My thought was to use only one bitcoin private key per month to reduce from n utxo to one in order to compress size from the "input side".
To differentiate user deposit, I was wondering about providing a specific token to user and "asking him" to store it into the OP\_RETURN field of his transaction.

[![enter image description here](https://i.sstatic.net/QXvDM.png)](https://i.sstatic.net/QXvDM.png)

It is worth to try or should I use HD wallet as recommanded even if it will increase the "input size" inevitably ?

**Tags:** transaction-fees


---

## 1 answers

### Answer by username_1 on 2016-11-06. Score: 3 | Accepted answer

Each customer's transaction will use the same number of output bytes regardless of whether it pays a public key that was already seen on the network or a new public key, and when you go to spend the outputs, it will take the same number of input bytes to spend them whether they paid different public keys or not.

For that reason, it makes sense to use different receiving public keys to differentiate between customers rather than appending an additional output with an OP\_RETURN.

To reduce transaction fee as much as possible, you should reduce the byte size of a transaction as much as possible. Here are a few things you might be doing already but which (if you aren't doing them) can help:

* Ensure you use compressed public keys (33 bytes) rather than uncompressed public keys (65 bytes).
* If you don't need users to pay addresses but can instead get them to pay arbitrary scripts (e.g. you're using custom software or the BIP70 payment protocol), consider accepting payments using pay-to-pubkey (P2PK) rather than pay-to-pubkey-hash (P2PKH); this will [save about 24 bytes](https://bitcoin.stackexchange.com/questions/32639/why-does-the-default-miner-implementation-use-pay-to-pubkey/32642#32642) for each payment.
* When segwit becomes available, switch to using it as miners will be able to fit more segwit transactions in a block than they can fit traditional transactions, so they will likely charge you less fee.
* Combine multiple payments if possible. If you can get multiple customers to pay you in the same transaction (using something like coinjoin) or if you can pay multiple customers at the same time, you'll produce smaller transactions because you won't need to repeat some fields in a transaction (such as transaction version or locktime). When paying to your customers, you can save quite a lot because you'll only have one change output no matter how many *n* customers you pay.

> **Comments:**
> **username_0**: Thanks for this awesome answer. I had to read multiple times your first paragraph to get your point and now I understand how my "design" was totally useless! Your hints about how to reduce fees seems really relevant and are much appreciated!  

---

