Skip to main content
added 104 characters in body
Source Link
Claris
  • 15.5k
  • 2
  • 28
  • 44

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.

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.

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.

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.

added 565 characters in body
Source Link
Claris
  • 15.5k
  • 2
  • 28
  • 44

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.

LotsSome 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.

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.

Lots of things become unpalatable in Bitcoin when you change the constants.

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.

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.

deleted 24 characters in body
Source Link
Claris
  • 15.5k
  • 2
  • 28
  • 44

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 script. 0000000000000000 00 for a total of nine bytesscriptPubKey. 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.

Lots of things become unpalatable in Bitcoin when you change the constants.

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, 0 length, null script. 0000000000000000 00 for a total of nine bytes. 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.

Lots of things become unpalatable in Bitcoin when you change the constants.

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.

Lots of things become unpalatable in Bitcoin when you change the constants.

added 80 characters in body
Source Link
Claris
  • 15.5k
  • 2
  • 28
  • 44
Loading
Source Link
Claris
  • 15.5k
  • 2
  • 28
  • 44
Loading