From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <laanwj@gmail.com>) id 1WTV7i-0003vY-3U for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:38:58 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.180 as permitted sender) client-ip=209.85.213.180; envelope-from=laanwj@gmail.com; helo=mail-ig0-f180.google.com; Received: from mail-ig0-f180.google.com ([209.85.213.180]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTV7h-0004IQ-3G for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:38:58 +0000 Received: by mail-ig0-f180.google.com with SMTP id hl1so702233igb.1 for <bitcoin-development@lists.sourceforge.net>; Fri, 28 Mar 2014 04:38:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.60.103 with SMTP id g7mr37466512igr.20.1396006731772; Fri, 28 Mar 2014 04:38:51 -0700 (PDT) Received: by 10.64.70.131 with HTTP; Fri, 28 Mar 2014 04:38:51 -0700 (PDT) In-Reply-To: <lh3m7i$v18$1@ger.gmane.org> References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com> <lh3m7i$v18$1@ger.gmane.org> Date: Fri, 28 Mar 2014 12:38:51 +0100 Message-ID: <CA+s+GJCf9o6VEky=JXgrG8v39hyQtPz71yuftF_jyp0bX9WHsA@mail.gmail.com> From: Wladimir <laanwj@gmail.com> To: Andreas Schildbach <andreas@schildbach.de> Content-Type: multipart/alternative; boundary=047d7b1117c159f8fe04f5a92519 X-Spam-Score: -0.6 (/) 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 (laanwj[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WTV7h-0004IQ-3G Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> 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 11:38:58 -0000 --047d7b1117c159f8fe04f5a92519 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <andreas@schildbach.de>wrote: > I see the problem. > > However, I don't see how PaymentDetails can be an answer. None of the > fields (other than outputs and network) can be known in advance (at the > time of the initial payment). > > You're probably aiming for an expires field? How would you refund a > payment after expiry? Note its not your choice wether to refund a > payment -- it can be ordered by a court years after the payment happened. > Communication between the merchant and buyer would be needed in this case. I'd say that would be not unreasonable if something is to be refunded after a year or more. After all, people may have moved, bank accounts changed, even outside the bitcoin world. It should probably not be accepted to set a very low expiration time for the refund address, like <3 months, as it's as bad as not providing a refund address at all and brings back all the pre-BIP70 confusion. Wladimir --047d7b1117c159f8fe04f5a92519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <span dir=3D"ltr"><= <a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildba= ch.de</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">I see the problem.<br> <br> However, I don't see how PaymentDetails can be an answer. None of the<b= r> fields (other than outputs and network) can be known in advance (at the<br> time of the initial payment).<br> <br> You're probably aiming for an expires field? How would you refund a<br> payment after expiry? Note its not your choice wether to refund a<br> payment -- it can be ordered by a court years after the payment happened.<b= r></blockquote><div><br></div><div>Communication between the merchant and b= uyer would be needed in this case.<br><br></div><div>I'd say that would= be not unreasonable if something is to be refunded after a year or more. A= fter all, people may have moved, bank accounts changed, even outside the bi= tcoin world.<br> <br></div><div>It should probably not be accepted to set a very low expirat= ion time for the refund address, like <3 months, as it's as bad as n= ot providing a refund address at all and brings back all the pre-BIP70 conf= usion.<br> </div><div></div><div><br></div><div class=3D"h5">Wladimir<br></div></div><= br></div></div> --047d7b1117c159f8fe04f5a92519--