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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
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 <runesvend@gmail.com>) id 1UF91S-0001qd-Ls
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 20:08:38 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.54 as permitted sender)
client-ip=74.125.82.54; envelope-from=runesvend@gmail.com;
helo=mail-wg0-f54.google.com;
Received: from mail-wg0-f54.google.com ([74.125.82.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UF91Q-0005nl-OU
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 20:08:38 +0000
Received: by mail-wg0-f54.google.com with SMTP id fm10so5248256wgb.21
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 13:08:30 -0700 (PDT)
X-Received: by 10.180.98.232 with SMTP id el8mr15276019wib.22.1363032510412;
Mon, 11 Mar 2013 13:08:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.44.132 with HTTP; Mon, 11 Mar 2013 13:08:10 -0700 (PDT)
In-Reply-To: <CABOyFfp9Kd+y=SofWfq6TiR4+xeOhFL7VVHWjtrRn83HMsmPBA@mail.gmail.com>
References: <20130310043155.GA20020@savin>
<CABOyFfp9Kd+y=SofWfq6TiR4+xeOhFL7VVHWjtrRn83HMsmPBA@mail.gmail.com>
From: =?ISO-8859-1?Q?Rune_Kj=E6r_Svendsen?= <runesvend@gmail.com>
Date: Mon, 11 Mar 2013 21:08:10 +0100
Message-ID: <CAH2=CKx-SWk17v9uGFAmk=-sbFrxeuvAvCFmECSvM7FEH-C0kw@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=f46d0442885e99bfa804d7abbcc0
X-Spam-Score: -0.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
(runesvend[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1UF91Q-0005nl-OU
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:08:38 -0000
--f46d0442885e99bfa804d7abbcc0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 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.
> While the transactions pay fees, they should not be considered spam
> regardless of how little the quantities being moved are.
>
> Then your only concern are unspent outputs and comparing fees with
> values doesn't help in any way.
> 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.
>
From 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.
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.
/Rune
>
>
> -------------------------------------------------------------------------=
-----
> 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
>
--f46d0442885e99bfa804d7abbcc0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Mar 11, 2013 at 12:01 PM, Jorge Tim=F3n <span dir=
=3D"ltr"><<a href=3D"mailto:jtimonmv@gmail.com" target=3D"_blank">jtimon=
mv@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 3/10/13, Peter Todd <=
;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br=
>
> It's also been suggested multiple times to make transaction output=
s with<br>
> a value less than the transaction fee non-standard, either with a fixe=
d<br>
> constant or by some sort of measurement.<br>
<br>
</div>As said on the bitcointalk thread, I think this is the wrong approach=
.<br>
This way you effectively disable legitimate use cases for payments<br>
that "are worth" less than the fees like smart property/colored c=
oins.<br>
While the transactions pay fees, they should not be considered spam<br>
regardless of how little the quantities being moved are.<br>
<br>
Then your only concern are unspent outputs and comparing fees with<br>
values doesn't help in any way.</blockquote><div><br></div><div>=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Just activate a non-proportional<br>
demurrage (well, I won't complain if you just turn bitcoin into<br>
freicoin, just think that non-proportional would be more acceptable by<br>
most bitcoiners) that incentives old transactions to be moved and<br>
destroys unspent transactions with small amounts that don't move to<br>
another address periodically. This has been proposed many times before<br>
too, and I think it makes a lot more sense.<br></blockquote><div><br></div>=
<div style>From an economic point of view this *does* make sense, in my opi=
nion. 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 =A0isn=
9;t feasible if we want to maintain people's confidence in Bitcoin.</di=
v>
<div style><br></div><div style>I like Jeff's proposal of letting an al=
t-coin implement this. If it gets to the point where Bitcoin can't func=
tion without this functionality, it'll be a lot easier to make the tran=
sition, instead of now, when it's not really needed, and the trust in B=
itcoin really isn't that great.</div>
<div style><br></div><div style>/Rune</div><div style><br></div><div>=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<br>
---------------------------------------------------------------------------=
---<br>
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester<br>
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" =
in the<br>
endpoint security space. For insight on selecting the right partner to<br>
tackle endpoint security challenges, access the full report.<br>
<a href=3D"http://p.sf.net/sfu/symantec-dev2dev" target=3D"_blank">http://p=
.sf.net/sfu/symantec-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>
--f46d0442885e99bfa804d7abbcc0--
|
