1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
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 <ben@benlabs.net>) 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 <bitcoin-development@lists.sourceforge.net>;
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 <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>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 18:45:34 -0000
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.
|
