<p>There is no limit on the size of the UTXO other than the block size as you've described, but your reasoning isn't correct. There is no minimum size of a transaction output, nor maximum number of outputs per transaction. The bulk is limited by the Bitcoin block size of 1MB, or about 50GB per year total additions if the only thing being added was spam outputs. </p>

<p>Volume of outputs is another matter entirely. The smallest possible output is 0 BTC (8 bytes), 0 length (1 byte), null scriptPubKey. If we make a maximum sized transaction (1MB) of these it will have somewhere in realm of 110,000 outputs, with some loss included for inputs and structure. 6 blocks per hour, 24 hours gives 15.8M outputs per day. Note this does not include any indexing overhead, which would be non-negligible for this many entries. </p>

<p>Some of the proposed solutions include expiring unspent outputs after a particular amount of time, or significantly moving the cost towards creation and incentivising removal of entries. Changes in core operation like this however aren't fast to implement or uncontroversial, and are not a complete solution against an attacker. </p>

<p>It's one of the drawbacks of the system as implemented and something that needs to be seriously considered before making alterations which could make the problem even worse.  Lots of things become unpalatable in Bitcoin when you change the constants, this is one which is already pretty terrible to begin with. </p>

CC BY-SA 3.0
2015-11-04T06:12:13.703Z
I'm not suggesting there's minimum/maximum transaction size. My question is about at which rate utxo can grow?
vi.su.
CC BY-SA 3.0
2015-11-04T06:50:59.267Z
The rate is bounded by how much you can grow it per block, so most efficient ways of bloating the database is completely what you want to be looking at. There's no other limit. Put directly, 50GB per year + indexing overhead if every transaction is intended to bloat it.
Claris
CC BY-SA 3.0
2015-10-31T09:35:49.947Z
2015-11-04T06:18:18.653Z
2015-11-04T06:18:18.653Z
Claris
<p>Now bitcoin unspent transaction output growth rate (not total size) can be, 260k utxo/day (3×60×60×24). With 8MB blocks, that's 2.8 million.</p>

<p>Single 1 bitcoin output can be split into 1000 x 1 mBTC outputs, within 100 minutes (10 blocks). Then, those 1000 outputs can be moved individually, as required..</p>

<p>Does this kind of utxo bloat attack work? Anything wrong with my calculations?</p>

CC BY-SA 3.0
2015-10-31T09:02:03.210Z
https://statoshi.info/dashboard/db/unspent-transaction-output-set
amaclin
CC BY-SA 3.0
2015-10-31T09:11:36.687Z
@amaclin, sorry, I was not clear. I wanted to know maximum possible rate at which utxo can grow, and whether that can be turned into an attack..
vi.su.
<blockchain><security><utxo>
What's the maximum possible utxo growth rate now? Can that be turned into an attack?
vi.su.
# What's the maximum possible utxo growth rate now? Can that be turned into an attack?

(Asked by: username_0 on 2015-10-31)

Now bitcoin unspent transaction output growth rate (not total size) can be, 260k utxo/day (3×60×60×24). With 8MB blocks, that's 2.8 million.

Single 1 bitcoin output can be split into 1000 x 1 mBTC outputs, within 100 minutes (10 blocks). Then, those 1000 outputs can be moved individually, as required..

Does this kind of utxo bloat attack work? Anything wrong with my calculations?

**Tags:** blockchain, security, utxo

> **Comments:**
> **username_1**: https://statoshi.info/dashboard/db/unspent-transaction-output-set  
> **username_0**: @username_1, sorry, I was not clear. I wanted to know maximum possible rate at which utxo can grow, and whether that can be turned into an attack..  

---

## 1 answers

### Answer by username_2 on 2015-10-31. Score: 3

There is no limit on the size of the UTXO other than the block size as you've described, but your reasoning isn't correct. There is no minimum size of a transaction output, nor maximum number of outputs per transaction. The bulk is limited by the Bitcoin block size of 1MB, or about 50GB per year total additions if the only thing being added was spam outputs.

Volume of outputs is another matter entirely. The smallest possible output is 0 BTC (8 bytes), 0 length (1 byte), null scriptPubKey. If we make a maximum sized transaction (1MB) of these it will have somewhere in realm of 110,000 outputs, with some loss included for inputs and structure. 6 blocks per hour, 24 hours gives 15.8M outputs per day. Note this does not include any indexing overhead, which would be non-negligible for this many entries.

Some of the proposed solutions include expiring unspent outputs after a particular amount of time, or significantly moving the cost towards creation and incentivising removal of entries. Changes in core operation like this however aren't fast to implement or uncontroversial, and are not a complete solution against an attacker.

It's one of the drawbacks of the system as implemented and something that needs to be seriously considered before making alterations which could make the problem even worse. Lots of things become unpalatable in Bitcoin when you change the constants, this is one which is already pretty terrible to begin with.

> **Comments:**
> **username_0**: I'm not suggesting there's minimum/maximum transaction size. My question is about at which rate utxo can grow?  
> **username_2**: The rate is bounded by how much you can grow it per block, so most efficient ways of bloating the database is completely what you want to be looking at. There's no other limit. Put directly, 50GB per year + indexing overhead if every transaction is intended to bloat it.  

---

