From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UF7j4-0005fD-P4 for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 18:45:34 +0000 Received: from mail-ie0-f180.google.com ([209.85.223.180]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UF7j2-0007XU-Ft for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 18:45:34 +0000 Received: by mail-ie0-f180.google.com with SMTP id bn7so5146716ieb.25 for ; Mon, 11 Mar 2013 11:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=eNTeQY9NkvXuhXU52tWpeBBDUxSpPe7jBjd9RbcRf+0=; b=Z/6INPyz5BBxqw61FNxTEI7t5RI8Svbi8v3QTa0eBRCylb+08wj1P77DxbONhu2nTi u8R3UD/7IhMxnmVK7a6AnPl9wVbotR3wHZ3yIDnNOFvakq4VO7JU+2m8HvfT2JSLesYS WEp2IYSu+zvzh9wSf7I+0lo89uWg+4rFe5hlS9X+7fvYmZK7mK2608EZS6XKR+lGxRCZ T/75MN25euGf53PC+H57HTMRccbTJ4E+kJA85WssJ6epT8Q+iq/PI5eqa1VqnKw/V0nK hJ4vCsvfmyNyUOr/wSmbK0dpv3P9lkVQoD2C6nB/3g0w2856jdWfDy+0pSxbImn+M2cc 1Csg== X-Received: by 10.42.88.145 with SMTP id c17mr9435360icm.47.1363025827718; Mon, 11 Mar 2013 11:17:07 -0700 (PDT) Received: from [10.78.21.24] (dyn19218817715.dz.ornl.gov. [192.188.177.15]) by mx.google.com with ESMTPS id xf4sm14170379igb.8.2013.03.11.11.17.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 11:17:06 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Benjamin Lindner In-Reply-To: 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> To: Bitcoin Dev X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmyGAg3td/Q38kWA98ysVbVRGbSmbSFGn+oXnRHSqQ2u3gWXxwPq5FNkcDf1Cv2L917tlPx X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1UF7j2-0007XU-Ft Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:45:34 -0000 On Mar 11, 2013, at 12:54 PM, Mike Hearn 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 = wrote: > On 3/10/13, Peter Todd 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 (outputfee): 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