Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTtKe-0004kG-Hd for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 13:29:56 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTtKb-0007xB-8m for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 13:29:56 +0000 Received: by mail-oa0-f50.google.com with SMTP id i7so7305653oag.23 for ; Sat, 29 Mar 2014 06:29:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.117.73 with SMTP id kc9mr12118204obb.20.1396099787893; Sat, 29 Mar 2014 06:29:47 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Sat, 29 Mar 2014 06:29:47 -0700 (PDT) In-Reply-To: <20140329092721.GG62995@giles.gnomon.org.uk> References: <5335BD17.6050408@plan99.net> <20140329092721.GG62995@giles.gnomon.org.uk> Date: Sat, 29 Mar 2014 14:29:47 +0100 X-Google-Sender-Auth: gSF93f3Y8QKASqPya0wxcpoSErc Message-ID: From: Mike Hearn To: Roy Badami Content-Type: multipart/alternative; boundary=f46d044796f3edc6f704f5becf1e 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: 1WTtKb-0007xB-8m Cc: Bitcoin Dev , Andreas Schildbach 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: Sat, 29 Mar 2014 13:29:56 -0000 --f46d044796f3edc6f704f5becf1e Content-Type: text/plain; charset=UTF-8 So how about we say two months? That way it's easy for merchants to comply with the EU DSD and we keep RAM usage in check until we come up with a more sophisticated refund scheme. There's another issue with BIP 70 and refunds that I noticed. The PaymentRequest doesn't specify whether refunds are possible. So wallets have to either never submit refund data, or always submit it even if it makes no sense. Because setting things up to get refunds has a non-zero cost for the sender, it'd help if we could optimise it away for merchants that simply refuse to issue refunds for whatever reason. On Sat, Mar 29, 2014 at 10:27 AM, Roy Badami wrote: > On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote: > > On 03/28/2014 07:19 PM, Mike Hearn wrote: > > > > >> 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. > > > > > > Yeah I was thinking something like that on the walk home. But 2 years > is > > > a long time. Do we have enough RAM for that? > > > > It depends on usage stats, script size, etc... > > > > > Plus warranties usually > > > result in the defective goods being replaced rather than a monetary > > > refund, right? > > > > Usually yes. The next smaller "unit of time" in Germany would be two > > weeks, the so-called "Fernabsatzgesetz". It allows you to send back > > mail-orders and usually you want the money back. Don't know if that made > > it into EU law or how it applies to other countries. > > It's EU law, but the Distance Selling Directive only says "at least > seven days", so the exact period probably varies by country (in the UK > it is 7 days). > > But the clock only starts ticking when you receive the goods, and the > Distance Selling Directive allows the supplier 30 days "to execute the > order" (I *think* the 30 days always has to include shipping, because > for consumer contracts title doesn't pass until the goods are > delivered, so the order wouldn't be considered complete until then). > > So I think latest possible deadline for returning the goods for refund > could be up to 30 days to execute the order plus "at least 7 days" > (with some countries allowing more). Plus, conceivably, shipping > time, if some member states have chosen to interpret the 30 day > execution differently. > > So I think this adds up to "a couple of months, give or take". In > practice, though, even a couple of months is a bit on the short time. > What if the goods are delayed. How many people have had miner orders > outstanding for the best part of a year? > > roy > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --f46d044796f3edc6f704f5becf1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So how about we say two months? That way it's easy for= merchants to comply with the EU DSD and we keep RAM usage in check until w= e come up with a more sophisticated refund scheme.

There= 's another issue with BIP 70 and refunds that I noticed. The PaymentReq= uest doesn't specify whether refunds are possible. So wallets have to e= ither never submit refund data, or always submit it even if it makes no sen= se. Because setting things up to get refunds has a non-zero cost for the se= nder, it'd help if we could optimise it away for merchants that simply = refuse to issue refunds for whatever reason.



On Sat, Mar 29, 2014 at 10:27 AM, Roy Badami <= roy@gnomon.org.uk> wrote:
On Fri, Mar 28, 2014 at 09:5= 6:57PM +0100, Andreas Schildbach wrote:
> On 03/28/2014 07:19 PM, Mike Hearn wrote:
>
> >> 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 warra= nty, so it
> >> seems appropriate to pick 2.5 years (30 months) -- allowing f= or some
> >> time to ship the product back and forth.
> >
> > Yeah I was thinking something like that on the walk home. But 2 y= ears is
> > a long time. Do we have enough RAM for that?
>
> It depends on usage stats, script size, etc...
>
> > Plus warranties usually
> > result in the defective goods being replaced rather than a moneta= ry
> > refund, right?
>
> Usually yes. The next smaller "unit of time" in Germany woul= d be two
> weeks, the so-called "Fernabsatzgesetz". It allows you to se= nd back
> mail-orders and usually you want the money back. Don't know if tha= t made
> it into EU law or how it applies to other countries.

It's EU law, but the Distance Selling Directive only says "a= t least
seven days", so the exact period probably varies by country (in the UK=
it is 7 days).

But the clock only starts ticking when you receive the goods, and the
Distance Selling Directive allows the supplier 30 days "to execute the=
order" (I *think* the 30 days always has to include shipping, because<= br> for consumer contracts title doesn't pass until the goods are
delivered, so the order wouldn't be considered complete until then).
So I think latest possible deadline for returning the goods for refund
could be up to 30 days to execute the order plus "at least 7 days"= ;
(with some countries allowing more). =C2=A0Plus, conceivably, shipping
time, if some member states have chosen to interpret the 30 day
execution differently.

So I think this adds up to "a couple of months, give or take". = =C2=A0In
practice, though, even a couple of months is a bit on the short time.
What if the goods are delayed. =C2=A0How many people have had miner orders<= br> outstanding for the best part of a year?

roy


---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d044796f3edc6f704f5becf1e--