summaryrefslogtreecommitdiff
path: root/60/98e1110976f90e1c67d2c8422d2d4ce415c631
blob: b7f0fadddb904579c20782a7ea08dd1345e84610 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1VnoRF-0005l0-PI
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 11:46:49 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.45 as permitted sender)
	client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f45.google.com; 
Received: from mail-oa0-f45.google.com ([209.85.219.45])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VnoRE-0006fR-S6
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 11:46:49 +0000
Received: by mail-oa0-f45.google.com with SMTP id o6so14767448oag.18
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 03 Dec 2013 03:46:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.138.136 with SMTP id qq8mr1357128oeb.59.1386071203479;
	Tue, 03 Dec 2013 03:46:43 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.3.134 with HTTP; Tue, 3 Dec 2013 03:46:43 -0800 (PST)
In-Reply-To: <CABsx9T2cs5Agzpbn7S1ppzDnFgLuMJoqFVFZjJzPU+RuSVrQPQ@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>
Date: Tue, 3 Dec 2013 12:46:43 +0100
X-Google-Sender-Auth: P01iVjhwBkJRjDh0pC1xY3MpH58
Message-ID: <CANEZrP1Ef7P_bvE_qY+CsXG02=jGx8f4DrDKweSo7AAXLjeWXQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b41ccf8b79b0204ec9fd91f
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: 1VnoRE-0006fR-S6
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 11:46:50 -0000

--047d7b41ccf8b79b0204ec9fd91f
Content-Type: text/plain; charset=UTF-8

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.


> RE: hiding or showing fees:  I pointed out to Peter that there doesn't
> have to be One True Answer.  Let wallets experiment with either hiding or
> exposing fees, and may the best user experience win.
>

Sure. I think there will be experimentation in this regard.

--047d7b41ccf8b79b0204ec9fd91f
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 T=
ue, Dec 3, 2013 at 12:41 PM, Gavin Andresen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.c=
om</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc 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>A merchant can always refuse t=
he payment and refund it if that&#39;s a practical problem. I doubt it woul=
d be though. If a user is trying to buy something from the merchant, they w=
ill want it to work, and it&#39;ll be up to the developers of the wallet th=
ey&#39;re using to ensure it never does anything obnoxious or unacceptable =
that would result in people hating to receive money from that app.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra">
<div class=3D"gmail_extra">RE: hiding or showing fees: =C2=A0I pointed out =
to Peter that there doesn&#39;t have to be One True Answer. =C2=A0Let walle=
ts experiment with either hiding or exposing fees, and may the best user ex=
perience win.<br>
</div></div></div></blockquote><div><br></div><div>Sure. I think there will=
 be experimentation in this regard.</div></div></div></div>

--047d7b41ccf8b79b0204ec9fd91f--