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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimonmv@gmail.com>) id 1UF7wh-0007nD-Jc
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 18:59:39 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.181 as permitted sender)
client-ip=209.85.216.181; envelope-from=jtimonmv@gmail.com;
helo=mail-qc0-f181.google.com;
Received: from mail-qc0-f181.google.com ([209.85.216.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UF7wf-0004cz-Pg
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 18:59:39 +0000
Received: by mail-qc0-f181.google.com with SMTP id a22so1644907qcs.26
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 11:59:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.69.76 with SMTP id y12mr4331177qci.123.1363028372235;
Mon, 11 Mar 2013 11:59:32 -0700 (PDT)
Received: by 10.49.11.140 with HTTP; Mon, 11 Mar 2013 11:59:32 -0700 (PDT)
In-Reply-To: <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>
<75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net>
Date: Mon, 11 Mar 2013 19:59:32 +0100
Message-ID: <CABOyFfqqtU-M4tQv7cvNjGTC83NH6Gwds8gjDmF+GBM==+dLew@mail.gmail.com>
From: =?ISO-8859-1?B?CUpvcmdlIFRpbfNu?= <jtimonmv@gmail.com>
To: Benjamin Lindner <ben@benlabs.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(jtimonmv[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UF7wf-0004cz-Pg
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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:59:39 -0000
That solution seems good enough to me.
Smartcoin users would just need to move their assets before 10 years,
totally acceptable.
And regular users don't need to think about it since they're probably
always sending more than they pay in fees.
On 3/11/13, Benjamin Lindner <ben@benlabs.net> wrote:
>
> 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 i=
t
> 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 wit=
h
>>> a value less than the transaction fee non-standard, either with a fixed
>>> constant or by some sort of measurement.
>>
>> 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
>
> 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 t=
o
> have limited or unlimited lifetime. The rationale for limiting the lifeti=
me
> for (output<fee) transactions is that they may have no inherent economic
> incentive to be spend.
>
>
> -------------------------------------------------------------------------=
-----
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--=20
Jorge Tim=F3n
http://freico.in/
http://archive.ripple-project.org/
|
