Author

Topic: Capping the rate of growth of the UTXO set (Read 1870 times)

legendary
Activity: 1232
Merit: 1094
I like the idea of penalizing (through fees) of transactions where txout is bigger than txin. doing this effectively caps the growth of bitcoin to 100 users per block, which is not desirable.

Right, as I said.  100 was just an example.  You could have it as an exponential growth over time.
legendary
Activity: 2058
Merit: 1452
I like the idea of penalizing (through fees) of transactions where txout is bigger than txin. doing this effectively caps the growth of bitcoin to 100 users per block, which is not desirable.
legendary
Activity: 1232
Merit: 1094
This came up in the thread about the new rule that transactions with very low outputs were not to be relayed.

What about a rule which directly restricts the growth of the UTXO set.  A simple rule is that for a block to be valid, the number of outputs can be no more than 100 greater than the number of inputs.  The sums up the number of outputs and inputs for all transactions in the block.

This would encourage people to try to keep the the UTXO set low.  A transaction with an equal number of inputs and outputs would automatically be ok to include.

On the other hand, transaction outputs are inherently linked to unique users.  The maximum number of unique users can't be greater than the UTXO set size.

If the limit is to low, then UTXO "slots" would suddenly have value in and of themselves.  When sending cash to a merchant, the merchant would have to provide a UTXO to receive the funds.

Input 0: Merchant's input (M)
Input 1: Customer's input
Input 2: Customer's input

Output 0: Merchant's output (M + purchase price)
Output 1: Customer change 1
Output 2: Customer change 2

This way the customer doesn't lose a UTXO slot.

It would act against privacy.  Ideally, UTXO should be sufficiently scare so as to prevent spam, but not so scarce that "real" users can't get their hands on them.

Another option would be to define the limit based on block number.  Something like A * pow(growth, block number), but getting the growth rate right is hard.
Jump to: