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 ) 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 ; 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: References: Date: Fri, 28 Mar 2014 12:38:51 +0100 Message-ID: From: Wladimir To: Andreas Schildbach 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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

= On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <= andreas@schildba= ch.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 b= uyer 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. A= fter all, people may have moved, bank accounts changed, even outside the bi= tcoin world.

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.

Wladimir
<= br>
--047d7b1117c159f8fe04f5a92519--