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
|
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 <drak@zikula.org>) id 1Vnojd-0001pF-9t
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 12:05:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of zikula.org
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=drak@zikula.org;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vnojb-0006r9-Ii
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 12:05:49 +0000
Received: by mail-wg0-f41.google.com with SMTP id y10so5529245wgg.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Dec 2013 04:05:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=8CZATZvi/JGzmYlCWrNd/6cLN3+MjS8cMtapskQf/wo=;
b=Pfw/skGxjrmhjRQQROeuf64gem26slQqbI4FHa8EB+3mxaYSJZJ7nzD0gXWdM56b47
0nO1V8IlT/mvpuzx00E0dHMKVZ/qUXtBBjaWB0Bt5VKs88S3jPPd7oyf5FvoE3VTlJis
qPZD/Pe/XulamrLRqsXcxVyxFmgr6GJL+SWFjvHwhmIHmQXF4Yzx4Ub+VBVCGSlpuzfY
jS5l5xwIsDsRPEw17vseH5NHYi5npUFzkKTgiYMJXkBn0KaqW5fK1l9yKppq/4Oa/e6M
kI3JmsQK2omYUBOKdHyBQFDkTGMps8b75B2Y5sppD8Yd/ZiV36OXSh/xlOZZlsI69S+C
OFGw==
X-Gm-Message-State: ALoCoQkKzycXT0EzFl70rZ3NMDBlfk6xk4KLWK2iPZp1vI4nUSuZRjnNwGDB0PCHLAwJCh3RX3xH
X-Received: by 10.180.103.193 with SMTP id fy1mr2232576wib.10.1386072341275;
Tue, 03 Dec 2013 04:05:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Tue, 3 Dec 2013 04:05:21 -0800 (PST)
In-Reply-To: <CANEZrP1Ef7P_bvE_qY+CsXG02=jGx8f4DrDKweSo7AAXLjeWXQ@mail.gmail.com>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
<l7f97u$jdg$1@ger.gmane.org>
<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
<l7fpbn$hf6$1@ger.gmane.org>
<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
<CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>
<CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com>
<CAJHLa0P_uzEQ2OG2FTXyD2Zw4RzujNBxKbKD04CSS1sLNpLUUQ@mail.gmail.com>
<CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.gmail.com>
<CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
<CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com>
<CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
<CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
<CABsx9T2cs5Agzpbn7S1ppzDnFgLuMJoqFVFZjJzPU+RuSVrQPQ@mail.gmail.com>
<CANEZrP1Ef7P_bvE_qY+CsXG02=jGx8f4DrDKweSo7AAXLjeWXQ@mail.gmail.com>
From: Drak <drak@zikula.org>
Date: Tue, 3 Dec 2013 12:05:21 +0000
Message-ID: <CANAnSg0s-fo=+SmzZpv+5Yv32jXP3ptnjbV8DxexC8tvW5wtDg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d04428e3a89001604eca01d10
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 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: plan99.net]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Vnojb-0006r9-Ii
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
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, 03 Dec 2013 12:05:49 -0000
--f46d04428e3a89001604eca01d10
Content-Type: text/plain; charset=UTF-8
On 3 December 2013 11:46, Mike Hearn <mike@plan99.net> wrote:
> On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>>
>> If users want to pay with a huge transaction then it seems to me the user
>> should cover that cost. Allowing users to pay merchants with 100K
>> transactions full of dust and expecting them to eat the cost seems like a
>> great way to enable bleed-the-merchant-dry attacks.
>>
>
> A merchant can always refuse the payment and refund it if that's a
> practical problem. I doubt it would be though. If a user is trying to buy
> something from the merchant, they will want it to work, and it'll be up to
> the developers of the wallet they're using to ensure it never does anything
> obnoxious or unacceptable that would result in people hating to receive
> money from that app.
>
Refunds in this circumstance would be problematic because someone is going
to lose because they have to pay the fee. If the sender's money is refunded
minus the fee, they will be unhappy. And the merchant will be unhappy about
having had an unacceptable transaction they have to send back, and eat a
fee for the privilege.
This kind of situation needs to be avoided at all costs.
--f46d04428e3a89001604eca01d10
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3=
December 2013 11:46, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mi=
ke@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
class=3D"im">On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen <span dir=3D"=
ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavin=
andresen@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_extra">If u=
sers want to pay with a huge transaction then it seems to me the user shoul=
d cover that cost. Allowing users to pay merchants with 100K transactions f=
ull of dust and expecting them to eat the cost seems like a great way to en=
able bleed-the-merchant-dry attacks.</div>
</div></div></blockquote><div><br></div></div><div>A merchant can always re=
fuse the payment and refund it if that's a practical problem. I doubt i=
t would be though. If a user is trying to buy something from the merchant, =
they will want it to work, and it'll be up to the developers of the wal=
let they're using to ensure it never does anything obnoxious or unaccep=
table that would result in people hating to receive money from that app.</d=
iv>
</div></div></div></blockquote><div><br></div><div>Refunds in this circumst=
ance would be problematic because someone is going to lose because they hav=
e to pay the fee. If the sender's money is refunded minus the fee, they=
will be unhappy. And the merchant will be unhappy about having had an unac=
ceptable transaction they have to send back, and eat a fee for the privileg=
e.=C2=A0</div>
<div><br></div><div>This kind of situation needs to be avoided at all costs=
.=C2=A0</div></div></div></div>
--f46d04428e3a89001604eca01d10--
|
