From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> From: Drak Date: Tue, 3 Dec 2013 12:05:21 +0000 Message-ID: To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen 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
On 3= December 2013 11:46, Mike Hearn <mike@plan99.net> wrote:
<= 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">
On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen <gavin= andresen@gmail.com> wrote:
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.

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.

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

This kind of situation needs to be avoided at all costs= .=C2=A0
--f46d04428e3a89001604eca01d10--