Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <mh.in.england@gmail.com>) id 1WTVsa-0001fW-Sl for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 12:27:24 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.46 as permitted sender) client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f46.google.com; Received: from mail-oa0-f46.google.com ([209.85.219.46]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTVsa-0002fK-3z for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 12:27:24 +0000 Received: by mail-oa0-f46.google.com with SMTP id i7so5868043oag.5 for <bitcoin-development@lists.sourceforge.net>; Fri, 28 Mar 2014 05:27:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.44.42 with SMTP id b10mr85310oem.70.1396009638654; Fri, 28 Mar 2014 05:27:18 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Fri, 28 Mar 2014 05:27:18 -0700 (PDT) In-Reply-To: <48ED312A-A1F9-4081-9718-04DD45804313@bitsofproof.com> References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com> <lh3m7i$v18$1@ger.gmane.org> <CA+s+GJCf9o6VEky=JXgrG8v39hyQtPz71yuftF_jyp0bX9WHsA@mail.gmail.com> <122FC5AD-2117-4CAF-817F-45B00F57D549@bitsofproof.com> <CANEZrP30UsWsBJ-pzb=LQP-MB+PDE0buRdRbuUiOJxANLF9cpw@mail.gmail.com> <48ED312A-A1F9-4081-9718-04DD45804313@bitsofproof.com> Date: Fri, 28 Mar 2014 13:27:18 +0100 X-Google-Sender-Auth: 8-r5ujEzuUR8FmXbcCqzswdGRFE Message-ID: <CANEZrP3mEWq-kfZb_HdW53K=gAhY=660mRq6+unGV4XppVQimw@mail.gmail.com> From: Mike Hearn <mike@plan99.net> To: Tamas Blummer <tamas@bitsofproof.com> Content-Type: multipart/alternative; boundary=001a11c30a049d7a4704f5a9d2a3 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: 1WTVsa-0002fK-3z Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, Andreas Schildbach <andreas@schildbach.de> Subject: Re: [Bitcoin-development] BIP 70 refund field 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: Fri, 28 Mar 2014 12:27:25 -0000 --001a11c30a049d7a4704f5a9d2a3 Content-Type: text/plain; charset=UTF-8 > > It is not more effort than an auto remembered call-in phone number. You > delete if you do not care. The difference however is that it would be a > clean protocol for repeated payments in both directions for whatever > reason, where "refund" is and "payment" are not special compared to "1st > installment", "overpayed back" or "tip" or whatever extra charge arises > later. > I think that'd be too abstract. The purpose of the refund field is that so if/when you receive a payment there, the wallet UI can do something intelligent, like show you in your transactions list that a certain payment was refunded using language the user will understand. If it's modelled at the protocol level without that then it makes producing good UI's harder. --001a11c30a049d7a4704f5a9d2a3 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"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div>It= is not more effort than an auto remembered call-in phone number. You delet= e if you do not care. The difference however is that it would be a clean pr= otocol for repeated payments in both directions for whatever reason, where = "refund" is and "payment" are not special compared to &= quot;1st installment", "overpayed back" or "tip" = =C2=A0or whatever extra charge arises later.</div> </div></div></blockquote><div><br></div><div>I think that'd be too abst= ract. The purpose of the refund field is that so if/when you receive a paym= ent there, the wallet UI can do something intelligent, like show you in you= r transactions list that a certain payment was refunded using language the = user will understand. If it's modelled at the protocol level without th= at then it makes producing good UI's harder.</div> </div></div></div> --001a11c30a049d7a4704f5a9d2a3--