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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UPZvm-0007SG-Q7
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Apr 2013 14:53:54 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.54 as permitted sender)
client-ip=209.85.214.54; envelope-from=mh.in.england@gmail.com;
helo=mail-bk0-f54.google.com;
Received: from mail-bk0-f54.google.com ([209.85.214.54])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UPZvl-0002FE-Te
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Apr 2013 14:53:54 +0000
Received: by mail-bk0-f54.google.com with SMTP id q16so3719807bkw.27
for <bitcoin-development@lists.sourceforge.net>;
Tue, 09 Apr 2013 07:53:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.205.114.195 with SMTP id fb3mr2410036bkc.117.1365519227436;
Tue, 09 Apr 2013 07:53:47 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.204.38.8 with HTTP; Tue, 9 Apr 2013 07:53:47 -0700 (PDT)
In-Reply-To: <CA+8xBpdBDDxD46f9ugn-ueZGwMU6fnF4BheUGiiz1otOTdffEw@mail.gmail.com>
References: <CA+8xBpc5iV=prakWKkNFa0O+tgyhoHxJ9Xwz6ubhPRUBf_95KA@mail.gmail.com>
<CANEZrP1EKaHbpdC6X=9mvyJHC_cvW7u5p9nqM7EwkEypAg4Xmg@mail.gmail.com>
<CA+8xBpdBDDxD46f9ugn-ueZGwMU6fnF4BheUGiiz1otOTdffEw@mail.gmail.com>
Date: Tue, 9 Apr 2013 16:53:47 +0200
X-Google-Sender-Auth: 24j-a2hyHlTo3yOeU1mOmbOdmz0
Message-ID: <CANEZrP2B4CGwGp1BsPScyC_+DndLDMnHTzWhmhfUxQnE3bVuSA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=14dae94736937c732004d9eeb88d
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1UPZvl-0002FE-Te
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] On-going data spam
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: Tue, 09 Apr 2013 14:53:55 -0000
--14dae94736937c732004d9eeb88d
Content-Type: text/plain; charset=UTF-8
> However, there should be some metrics and heuristics that take care of
> this problem. Notably the dev consensus (sans you, Mike :)) seems to
> be that uneconomical outputs should be made non-standard.
I think that patch is ok as it doesn't really have any fixed concept of
what is uneconomical. But I haven't thought about it much. As Gavin says,
there's an obvious backwards compatibility problem there. It should
probably wait until the payment protocol work is done, so the major user of
micropayments-as-messages can migrate off them.
--14dae94736937c732004d9eeb88d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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">
However, there should be some metrics and heuristics that take care of<br>
this problem. =C2=A0Notably the dev consensus (sans you, Mike :)) seems to<=
br>
be that uneconomical outputs should be made non-standard.</blockquote><div>=
<br></div><div style>I think that patch is ok as it doesn't really have=
any fixed concept of what is uneconomical. But I haven't thought about=
it much. As Gavin says, there's an obvious backwards compatibility pro=
blem there. It should probably wait until the payment protocol work is done=
, so the major user of micropayments-as-messages =C2=A0can migrate off them=
.</div>
</div></div></div>
--14dae94736937c732004d9eeb88d--
|
