3

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?

2

1 Answer 1

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.

2
  • I'm not suggesting there's minimum/maximum transaction size. My question is about at which rate utxo can grow?
    – vi.su.
    Commented Nov 4, 2015 at 6:12
  • 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
    Commented Nov 4, 2015 at 6:50

Your Answer

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

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