From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UF8Qx-0007Wk-Vz for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 19:30:56 +0000 Received: from mail-wg0-f47.google.com ([74.125.82.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UF8Qw-0003Fm-5x for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 19:30:55 +0000 Received: by mail-wg0-f47.google.com with SMTP id dr13so5200112wgb.2 for ; Mon, 11 Mar 2013 12:30:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xja67DEALz0z6VsweY1IqRMQZ83pEza3sP2WhuqIoOg=; b=KGiFU8vzlpUZz4tsG9GsqBisrqif1PLl1d+Ws/N3byjy5o3NVYGIOkM9ISAo9uJQJp InKtdSMQk7MytMjCTofI/EP6WBpB7e453kpnWBY4PZdBTTvIgB1hJuh6mPcxE1ZWG7uq njzHHO/BPLtaiWSgsu9YFnYe761LdVz5tbT8NV5/lUgI9KVTdFKoTlNxE5uLVPIIuINw uP0ouk7iWewtKQxOO/7GvVz8vGOCW/pZbxlo6O4UAGUnnD/SwV3qatHm9m/37x4H4T6F jNluCmBHhatP7J96/FDZ9fuH5UVC9B+BJf26FDMFoP49RiFzav+3vm9ndDL/sQFUawyL +g9A== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr14639695wib.33.1363028354342; Mon, 11 Mar 2013 11:59:14 -0700 (PDT) Received: by 10.194.165.195 with HTTP; Mon, 11 Mar 2013 11:59:14 -0700 (PDT) X-Originating-IP: [128.102.239.63] In-Reply-To: <75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net> References: <20130310043155.GA20020@savin> <75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net> Date: Mon, 11 Mar 2013 11:59:14 -0700 Message-ID: From: Mark Friedenbach To: Benjamin Lindner Content-Type: multipart/alternative; boundary=e89a8f3ba6e3e135e204d7aac43a X-Gm-Message-State: ALoCoQnBT02L9en8f+n9Kzi2OTzONaTk4byythSRIkJKOKKpiohObtJqDRr9pp+7lCI2XmEvpepQ X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1UF8Qw-0003Fm-5x Cc: Bitcoin Dev 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 19:30:56 -0000 --e89a8f3ba6e3e135e204d7aac43a Content-Type: text/plain; charset=UTF-8 On Mon, Mar 11, 2013 at 11:17 AM, Benjamin Lindner wrote: > > 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 > > You could delegate the decision to the user with a rule like: > > if (output 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 incentive to be spend. > If you think demurrage has a bad rep, wait until you see the response to escheatment (which is what's really being proposed here). UTXO growth over time is worst-case linear, while computational resources increase exponentially. Mike nailed it on the head: all of this is a solution in search of a problem. Mark --e89a8f3ba6e3e135e204d7aac43a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 11, 2013 at 11:17 AM, Benjamin Lindner <ben@benlabs.net> wrote:
> Ju= st activate a non-proportional
> demurrage (well, I won't complain if you j= ust turn bitcoin into
> freicoin, just think that non-proportional would be more acceptable by=
> most bitcoiners) that incentives old transactions to be moved

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

if (output<fee):
=C2=A0limit lifetime of the UTXO to 10 years.
if (output>fee):
=C2=A0unlimited 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 economi= c incentive to be spend.

If you think demurrage has a bad rep, wait until you see the = response to escheatment (which is what's really being proposed here).
UTXO growth over time is worst-case linear, while computational resourc= es increase exponentially. Mike nailed it on the head: all of this is a sol= ution in search of a problem.

Mark<= br>
--e89a8f3ba6e3e135e204d7aac43a--