Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Benjamin Lindner <ben@benlabs.net>
In-Reply-To: <CANEZrP0gsrd2W3ODfQRSc2k5V7GotJ0vzEAxcAjnaMtDHZ9_JA@mail.gmail.com>
Date: Mon, 11 Mar 2013 14:17:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net>
References: <20130310043155.GA20020@savin>
	<CABOyFfp9Kd+y=SofWfq6TiR4+xeOhFL7VVHWjtrRn83HMsmPBA@mail.gmail.com>
	<CABsx9T1rt+7BQHz1S=NVtL_YV7kfCapQ+3MEf+xyXT7pZOfq7w@mail.gmail.com>
	<CABOyFfrO9Xpc=Pdh_6AM1yoHRCeuHxzqL02F-ALkimmsGbheiA@mail.gmail.com>
	<CABOyFfqh_VixG7SQMaQUkxU40MGY1f9JO3=OqwitHa1YoT4chQ@mail.gmail.com>
	<CANEZrP0gsrd2W3ODfQRSc2k5V7GotJ0vzEAxcAjnaMtDHZ9_JA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Precedence: list


On Mar 11, 2013, at 12:54 PM, Mike Hearn <mike@plan99.net> wrote:
> With regards to trying to minimize the size of the UTXO set, this
> again feels like a solution in search of a problem. Even with SD
> abusing micropayments as messages, it's only a few hundred megabytes
> today. That fits in RAM, let alone disk. If one day people do get

The problem of UTXO in principal scales with the block size limit. Thus =
it should be fixed BEFORE you consider increasing the block size limit. =
Otherwise you just kick the can down the road, making it bigger.

> concerned about the working set size, miners can independently set
> their own policies for what they confirm, for instance maybe they just

Problem is the skewed incentive structure. Rational miners will always =
include dust output with fees, because the eternal cost of UTXO is payed =
by the network and future miners, not the current/individual miner.

On Mar 11, 2013, at 7:01 AM, 	Jorge Tim=F3n <jtimonmv@gmail.com> =
wrote:

> On 3/10/13, Peter Todd <pete@petertodd.org> wrote:
>> It's also been suggested multiple times to make transaction outputs =
with
>> a value less than the transaction fee non-standard, either with a =
fixed
>> constant or by some sort of measurement.
>=20
> As said on the bitcointalk thread, I think this is the wrong approach.
> This way you effectively disable legitimate use cases for payments
> that "are worth" less than the fees like smart property/colored coins.

this.

> Just activate a non-proportional
> demurrage (well, I won't complain if you just turn bitcoin into
> freicoin, just think that non-proportional would be more acceptable by
> most bitcoiners) that incentives old transactions to be moved=20

You could delegate the decision to the user with a rule like:

if (output<fee):
 limit lifetime of the UTXO to 10 years.
if (output>fee):
 unlimited lifetime

Then, when a user creates a transaction, he can decide whether he wants =
to have limited or unlimited lifetime. The rationale for limiting the =
lifetime for (output<fee) transactions is that they may have no inherent =
economic incentive to be spend.