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
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1UF9hE-0004U6-5j
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 20:51:48 +0000
X-ACL-Warn:
Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129]
helo=mail.ceptacle.com)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UF9hA-0000dm-9D for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 20:51:48 +0000
Received: from localhost (localhost [127.0.0.1])
by mail.ceptacle.com (Postfix) with ESMTP id 755F52B7DC23
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 21:36:08 +0100 (CET)
X-Virus-Scanned: amavisd-new at ceptacle.com
Received: from mail.ceptacle.com ([127.0.0.1])
by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new,
port 10024) with ESMTP id qVqw1M2iWKhh
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 21:36:06 +0100 (CET)
Received: from [10.0.1.67] (2508ds5-oebr.1.fullrate.dk [90.184.5.129])
by mail.ceptacle.com (Postfix) with ESMTPSA id 303102B7DC11
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 21:36:06 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Michael Gronager <gronager@ceptacle.com>
In-Reply-To: <CAH2=CKx-SWk17v9uGFAmk=-sbFrxeuvAvCFmECSvM7FEH-C0kw@mail.gmail.com>
Date: Mon, 11 Mar 2013 21:36:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE5395CC-46C4-4C24-AA8F-A4E22FD07693@ceptacle.com>
References: <20130310043155.GA20020@savin>
<CABOyFfp9Kd+y=SofWfq6TiR4+xeOhFL7VVHWjtrRn83HMsmPBA@mail.gmail.com>
<CAH2=CKx-SWk17v9uGFAmk=-sbFrxeuvAvCFmECSvM7FEH-C0kw@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
X-Mailer: Apple Mail (2.1499)
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: 1UF9hA-0000dm-9D
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 20:51:48 -0000
The point with UTXO is in the long run to be able to switch from a p2p =
network where everyone stores, validates and verifies everything to a =
DHT where the load of storing, validating and verifying can be shared.=20=
If we succeed with that then I don't see a problem in a growing set of =
UTXO, may that be due to abuse/misuse or just massive use. A properly =
designed DHT should be able to scale to this.
However, that being said, if you worry about the size of the UTXO set =
you should change the current coin choosing algorithm to simply get rid =
of dust.=20
The current algorithm (ApproximateBestSubset) tend to accumulate dust as =
dust tend to be on an other scale than a real transactions and hence it =
is never included.
Regarding the demurrage/escheatment road, I agree that this is for =
another project. However, if users/developers like this idea, they can =
just implement a coin choosing algorithm donating dust as miner fee and =
use it on their satoshi-dice polluted wallet ;)
/M
=20
On 11/03/2013, at 21:08, Rune Kj=E6r Svendsen <runesvend@gmail.com> =
wrote:
> On Mon, Mar 11, 2013 at 12:01 PM, 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.
> While the transactions pay fees, they should not be considered spam
> regardless of how little the quantities being moved are.
>=20
> Then your only concern are unspent outputs and comparing fees with
> values doesn't help in any way.
>=20
> =20
> 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 and
> destroys unspent transactions with small amounts that don't move to
> another address periodically. This has been proposed many times before
> too, and I think it makes a lot more sense.
>=20
> =46rom an economic point of view this *does* make sense, in my =
opinion. Storing an unspent transaction in the block chain costs money =
because we can't prune it. However, it would completely destroy =
confidence in Bitcoin, as far as I can see. It makes sense economically, =
but it isn't feasible if we want to maintain people's confidence in =
Bitcoin.
>=20
> I like Jeff's proposal of letting an alt-coin implement this. If it =
gets to the point where Bitcoin can't function without this =
functionality, it'll be a lot easier to make the transition, instead of =
now, when it's not really needed, and the trust in Bitcoin really isn't =
that great.
>=20
> /Rune
>=20
> =20
>=20
> =
--------------------------------------------------------------------------=
----
> 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
> =
--------------------------------------------------------------------------=
----
> Symantec Endpoint Protection 12 positioned as A LEADER in The =
Forrester =20
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in =
the =20
> endpoint security space. For insight on selecting the right partner to=20=
> tackle endpoint security challenges, access the full report.=20
> =
http://p.sf.net/sfu/symantec-dev2dev______________________________________=
_________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
