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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimonmv@gmail.com>) id 1UF0Tn-0005v1-C7
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 11:01:19 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.49 as permitted sender)
client-ip=209.85.216.49; envelope-from=jtimonmv@gmail.com;
helo=mail-qa0-f49.google.com;
Received: from mail-qa0-f49.google.com ([209.85.216.49])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UF0Tj-0003rJ-5e
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 11:01:19 +0000
Received: by mail-qa0-f49.google.com with SMTP id o13so874714qaj.8
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 04:01:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.213.134 with SMTP id gw6mr16492313qab.72.1362999669687;
Mon, 11 Mar 2013 04:01:09 -0700 (PDT)
Received: by 10.49.11.140 with HTTP; Mon, 11 Mar 2013 04:01:09 -0700 (PDT)
In-Reply-To: <20130310043155.GA20020@savin>
References: <20130310043155.GA20020@savin>
Date: Mon, 11 Mar 2013 12:01:09 +0100
Message-ID: <CABOyFfp9Kd+y=SofWfq6TiR4+xeOhFL7VVHWjtrRn83HMsmPBA@mail.gmail.com>
From: =?ISO-8859-1?B?CUpvcmdlIFRpbfNu?= <jtimonmv@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
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: 1UF0Tj-0003rJ-5e
Cc: 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 11:01:19 -0000
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.
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.
|
