Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Fri, 28 Mar 2014 17:59:52 +0100
Message-ID: <lh49pp$4bc$1@ger.gmane.org>
References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>	<lh3m7i$v18$1@ger.gmane.org>
	<CANEZrP3zBFs=JpJi6eazTvrTaRX6XCJLu-zrraE6bezYW7b9pQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
In-Reply-To: <CANEZrP3zBFs=JpJi6eazTvrTaRX6XCJLu-zrraE6bezYW7b9pQ@mail.gmail.com>
Subject: Re: [Bitcoin-development] BIP 70 refund field
Precedence: list

Ok, why don't fix this in the spec for now, by defining a fixed expiry
time. In the EU, most products are covered by a 2 years warranty, so it
seems appropriate to pick 2.5 years (30 months) -- allowing for some
time to ship the product back and forth.


On 03/28/2014 12:31 PM, Mike Hearn wrote:
> On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach
> <andreas@schildbach.de <mailto:andreas@schildbach.de>> wrote:
> 
>     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 don't need all the fields indeed, but they're mostly optional
> (except time). So for the refund you'd fill out:
> 
> outputs (same as today)
> time
> expiry_time
> 
>     You're probably aiming for an expires field? How would you refund a
>     payment after expiry?
> 
> 
> It'd have to be ad-hoc at that point. OK, you don't get the nice UI that
> the refund field provides. Oh well. It should be rare to get refunds
> very very late after the purchase.
>  
> 
>     Btw. another problem is that the refund address is currently
>     unprotected.
> 
> 
> Yes indeed as is the rest of the Payment structure. We talked about
> signing it with one of the keys that's signing the Bitcoin transaction
> as well. But it seems like a bit overkill. Usually it'll be submitted
> over HTTPS or a (secured!) Bluetooth channel though so tampering with it
> should not be possible.
> 
> However this does raise the question of whether a refund should be a
> full blown PaymentRequest with optional PKI signing. Normally, I think,
> a seller does not know or care about the identity of a buyer for
> refunds, outside of their own tracking system.
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>