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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimonmv@gmail.com>) id 1UF5qm-00011S-J1
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 16:45:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.128.47 as permitted sender)
client-ip=209.85.128.47; envelope-from=jtimonmv@gmail.com;
helo=mail-qe0-f47.google.com;
Received: from mail-qe0-f47.google.com ([209.85.128.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UF5qi-0003tv-SD
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 16:45:24 +0000
Received: by mail-qe0-f47.google.com with SMTP id q19so2372325qeb.20
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 09:45:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.32.9 with SMTP id a9mr17843909qad.87.1363020315333; Mon,
11 Mar 2013 09:45:15 -0700 (PDT)
Received: by 10.49.11.140 with HTTP; Mon, 11 Mar 2013 09:45:15 -0700 (PDT)
In-Reply-To: <CABsx9T1rt+7BQHz1S=NVtL_YV7kfCapQ+3MEf+xyXT7pZOfq7w@mail.gmail.com>
References: <20130310043155.GA20020@savin>
<CABOyFfp9Kd+y=SofWfq6TiR4+xeOhFL7VVHWjtrRn83HMsmPBA@mail.gmail.com>
<CABsx9T1rt+7BQHz1S=NVtL_YV7kfCapQ+3MEf+xyXT7pZOfq7w@mail.gmail.com>
Date: Mon, 11 Mar 2013 17:45:15 +0100
Message-ID: <CABOyFfrO9Xpc=Pdh_6AM1yoHRCeuHxzqL02F-ALkimmsGbheiA@mail.gmail.com>
From: =?ISO-8859-1?B?CUpvcmdlIFRpbfNu?= <jtimonmv@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
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: 1UF5qi-0003tv-SD
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 16:45:24 -0000
"The Bitcoin network will destroy your coins IF you don't move your coins"
Is pretty different. By the way, doesn't have to destroy them, can
just give them to miners.
In any case, what's wrong with my reasoning?
Smart property/colored coins are not spam transactions because they pay fee=
s.
The problem for the network are not transactions that move less coins
than they pay fees, but old UNSPENT OUTPUTS. So why don't you focus on
that instead of a formula to check what transactions make "economic
sense"?
I even prefer the sudden "destruction" (or re-generation by miners) of
the account after the X period (killerstorm's proposal) instead of
just rejecting great potential use cases for the chain.
I mean, I still prefer a small fixed demurrage fee after those X
blocks without moving them, but since this community is demurrage
allergic and that possibility cannot even be considered (doesn't
matter what reflects better the costs for miners/the network I guess),
I'll go with the second best option IMO.
This would be just a fee for a resource that users are enjoying and
has real costs for the network. Why would constant demurrage fees
after a free storage period would be perceived so different from
transaction fees?
I haven't heard anyone complaining about "the bitcoin developers are
destroying part of YOUR coins every time you move them!!"
On 3/11/13, Gavin Andresen <gavinandresen@gmail.com> wrote:
>> Just activate a non-proportional demurrage
>
> demurrage of any kind will never, ever happen, just give up on that idea.
>
> The negative publicity of "the bitcoin developers are destroying YOUR
> coins!" would be devastating.
>
> --
> --
> Gavin Andresen
>
--=20
Jorge Tim=F3n
http://freico.in/
http://archive.ripple-project.org/
|
