public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Roy Badami <roy@gnomon.org.uk>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP 70 refund field
Date: Sat, 29 Mar 2014 14:29:47 +0100	[thread overview]
Message-ID: <CANEZrP3+-kJiO+pCAdEGtzebcR65eAnTjuFQgQPbzAmh6v-WyQ@mail.gmail.com> (raw)
In-Reply-To: <20140329092721.GG62995@giles.gnomon.org.uk>

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]

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 <roy@gnomon.org.uk> 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
>

[-- Attachment #2: Type: text/html, Size: 4021 bytes --]

  reply	other threads:[~2014-03-29 13:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28 11:07 [Bitcoin-development] BIP 70 refund field Mike Hearn
2014-03-28 11:25 ` Andreas Schildbach
2014-03-28 11:31   ` Mike Hearn
2014-03-28 16:59     ` Andreas Schildbach
2014-03-28 18:19       ` Mike Hearn
2014-03-28 20:56         ` Andreas Schildbach
2014-03-29  9:27           ` Roy Badami
2014-03-29 13:29             ` Mike Hearn [this message]
2014-03-30 17:21               ` Andreas Schildbach
2014-03-28 11:38   ` Wladimir
2014-03-28 11:45     ` Tamas Blummer
2014-03-28 11:46       ` Mike Hearn
2014-03-28 11:54         ` Tamas Blummer
2014-03-28 12:27           ` Mike Hearn
2014-03-28 12:55             ` Tamas Blummer
2014-03-28 13:00               ` Mike Hearn
2014-03-28 13:09                 ` Tamas Blummer
2014-03-28 11:30 ` Tamas Blummer
2014-03-28 13:18   ` Tamas Blummer
2014-03-28 14:01     ` Gavin Andresen
2014-03-28 14:06       ` Mike Hearn
2014-03-28 14:27       ` Tamas Blummer
2014-03-28 15:23         ` Mike Hearn
2014-03-28 15:26           ` Tamas Blummer
2014-03-28 16:34             ` Mike Hearn
2014-03-28 16:45               ` Tamas Blummer
2014-03-31  9:23 ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANEZrP3+-kJiO+pCAdEGtzebcR65eAnTjuFQgQPbzAmh6v-WyQ@mail.gmail.com \
    --to=mike@plan99.net \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=roy@gnomon.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox