public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Lawrence Nahum <lawrence@greenaddress.it>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Date: Mon, 16 Jun 2014 15:28:00 +0000 (UTC)	[thread overview]
Message-ID: <loom.20140616T170619-497@post.gmane.org> (raw)
In-Reply-To: CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com

Mike Hearn <mike <at> plan99.net> writes:
[snip]
> Daniel is right that putting every possible provider in the Payment 
message might not scale in a world where there are huge numbers of instant-
confirmation providers, but I'm hoping that we never have to scale to that 
size, because if we did that'd rather imply that Bitcoin has become useless 
for in-person payments without trusted third parties and avoiding that is 
rather the whole point of the project :) So I'm OK with some theoretical 
lack of scalability for now. 

Hard to say for now. I like the current simplicity but if someone can come 
up with some use case for other options we should discuss and investigate 
them. I don't see more than a bunch of accepted payment methods anywhere I 
ever been in my life, I don't see merchants trusting more than a handful of 
third parties.

> A more scalable approach would be for the user to send the name and 
signature of their "instant provider" every time and the merchant just 
chooses whether to ignore it or not, but as Lawrence points out, this is 
incompatible with the provider charging extra fees for "instantness". But 
should we care? I'm trying to imagine what the purchasing experience is like 
with optional paid-for third party anti-double-spend protection. Ultimately 
it's the merchant who cares about this, not me, so why would I ever pay?

I think you are wrong here.
Just because up to date credit cards charged the merchant which in turn 
charged you and the ordinary cash payer doesn't mean a newer and better 
system can't be transparent from day one.

Ultimately you care because the alternative is to wait.

> It makes no sense for me to pay for double spend protection for the 
merchant: after all, I'm honest.

It's quite simple, in a low amounts world people will probably accept zero 
confs, just like occasionally people can walk out with a bag of crisps 
without paying from a Pret in London. Guards would cost more than what 
they'd save from thefts.

With higher amounts they will either not accept bitcoin unless instant 
confirmed or they will make you wait if that's even feasible (unlikely in a 
supermarket or petrol station but perfectly fine at the restaurant maybe).

> This is why it doesn't make sense for me to pay miners fees either, it's 
the receiver who cares about confirmations, not the sender.

You care too: time and money, or just money if you want to use the old 
simplification.

> So I wonder if a smarter design is that the user always submits the 
details of their instantness provider and we just don't allow for optional 
selection of instantness. I'm not sure that works, UX wise, so is having a 
less scalable design to support it worthwhile?

We would not support that I think. Explicit is better than implicit.

We will charge for instant confirmation and wouldn't want the user charged 
unless pre-agreed, especially if then they also have to wait because the 
instant tx was not recognized as such.

Yeah we can charge the merchant that can then in turn charge you, we may as 
well charge you and be transparent about it but also have deals with 
merchant where they pay fixed amounts per month for unlimited tx and make it 
free for their users.

Perhaps just like today people ask you which card you are going to use and 
they may not accept Amex or Diners the same will go for instant and they, 
the merchants, will just pick the instant provider from a touch screen 
before allowing the payment in. 





  parent reply	other threads:[~2014-06-16 15:30 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-14 12:00 [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Lawrence Nahum
2014-06-14 12:57 ` Andreas Schildbach
2014-06-15  9:22   ` Lawrence Nahum
2014-06-15 12:46     ` Andreas Schildbach
2014-06-15 14:09       ` Lawrence Nahum
2014-06-18 12:09       ` Lawrence Nahum
2014-06-18 13:25         ` Mike Hearn
2014-06-18 15:59           ` Daniel Rice
2014-06-18 16:09             ` Mike Hearn
2014-06-19 17:36               ` Daniel Rice
2014-06-25 14:01         ` sebastien requiem
2014-06-16 12:19 ` Mike Hearn
2014-06-16 12:25   ` Mike Hearn
2014-06-16 15:09   ` Daniel Rice
2014-06-16 15:26     ` Lawrence Nahum
2014-06-16 16:00       ` Daniel Rice
2014-06-16 16:07         ` Mike Hearn
2014-06-16 15:41     ` Paul Goldstein
2014-06-16 15:48       ` Mike Hearn
2014-06-16 16:30         ` Lawrence Nahum
2014-06-16 16:45           ` Mike Hearn
2014-06-16 16:56             ` Lawrence Nahum
2014-06-16 17:01               ` Mike Hearn
2014-06-16 17:16                 ` Lawrence Nahum
2014-06-16 18:02                   ` Alex Kotenko
2014-06-16 18:09                     ` Mike Hearn
2014-06-16 20:29                       ` Daniel Rice
2014-06-16 20:32                         ` Mike Hearn
2014-06-16 20:37                           ` Daniel Rice
2014-06-16 20:46                             ` Mike Hearn
2014-06-16 20:53                               ` Daniel Rice
2014-06-16 20:55                                 ` Mike Hearn
2014-06-16 20:50                             ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
2014-06-16 21:02                         ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Daniel Rice
2014-06-16 20:32                       ` Alex Kotenko
2014-06-16 17:44                 ` Jorge Timón
2014-06-17 15:58                 ` Isidor Zeuner
2014-06-18  1:39         ` Tom Harding
2014-06-17 15:58     ` Isidor Zeuner
2014-06-18  9:15       ` Mike Hearn
2014-06-18 20:47       ` Natanael
2014-06-18  2:01     ` Tom Harding
2014-06-16 15:28   ` Lawrence Nahum [this message]
2014-06-16 15:43     ` Mike Hearn
2014-06-16 17:05       ` Lawrence Nahum
2014-06-16  8:53 Daniel Rice

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=loom.20140616T170619-497@post.gmane.org \
    --to=lawrence@greenaddress.it \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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