From: Mike Hearn <mike@plan99•net>
To: Stephen Pair <stephen@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Date: Thu, 20 Dec 2012 18:43:34 +0100 [thread overview]
Message-ID: <CANEZrP162Q=hoqBQvLPm6rT=xNHMOtau42gDzRS4ddEtMFk5Uw@mail.gmail.com> (raw)
In-Reply-To: <CADb9v0K9xD+ndB-dJDkmPOuo1omrtMk3WTo238OjVcWoQ-CmXA@mail.gmail.com>
Thanks for the thoughts. For those who don't know, Stephen works for BitPay.
> My first observation is that the proposal is too heavily oriented around a
> merchant/customer interaction.
The term "merchant" is just being used to mean the entity requesting
the payment. I'm hopeful that in future mobile wallets will be
creating these messages where today they'd make URLs and QRcodes. So
it's definitely intended for person to person payments too.
> you may find yourself in a situation needing to parse a protobuf
> message in a web browser
Nothing stops you converting them into whatever form you want on the
server side. If you don't care about the signature checking then it's
no problem to use a server. If you do then you'd need to ship all the
code for verifying signatures that to the client anyway, at which
point a small protobuf parser is hardly a deal killer.
> ...like what about the casual user that wants to create a payment request to
> send to their friend over email
They can send an unsigned payment request. Note that if you mail it as
an attachment from a competent, up to date email provider then the
attachment isn't really unsigned. The whole thing is covered by the
emails DKIM signature which is applied transparently by the ESP. If
the signature fails to verify then the mail client can show that or
treat the mail differently (as Gmail does). This is easy to use for
the end user - they don't have to think about cryptography or PKI. As
long as their email account is secure then they can send signed mails
asserting to their identity.
> Refund addresses...this is not going to be as useful as people might
> think...most refunds that bitpay needs to process happen days or even months
> after the initial purchase
Useful feedback, thanks. Still, there may be other types of merchants
for whom it's useful, and many users won't change their wallet. It
certainly simplifies things if you can present the refund address and
give a one-click option to use it. If the user wants to use a
different address, then they can go onto the slow/complicated path.
This current spec deliberately punts on the topic of identifying end
users. It's a difficult problem. Whereas many merchants have SSL
certs, most end users don't have published keys in any useful form. By
far the easiest way for 99% of people to generate a signed message is
to send email that's signed by DKIM (from gmail, hotmail, yahoo, other
providers etc). Then it's all transparent and behind the scenes. Their
identity is their email address.
So for BitPays scenario, you could require an email to be sent by the
end user containing new instructions. Your MTA can show you whether
the mail is correctly DKIM signed or not when deciding whether to
follow the instructions.
> But, if the recipient never cashes the check, the sender could pull those
> funds back after a certain period of time.
Yeah, I like the term "check"/"cheque" for that concept of a reversible payment.
> I like the use of merchant_data...this means that you no longer will need a
> unique bitcoin address for every invoice.
It's still a good idea to use one for privacy reasons. The merchant
data is there so you can stuff whatever state you want into it. So
it's like cookies. You don't have to keep state on the server side.
Just encrypt/sign it, put it in the invoice, and when you get a
payment message back there's no need to do database lookups or
anything, you can just do some crypto and know who is submitting it.
> Generally speaking, I'm not a fan of embedding things like that
What's wrong with it? Isn't your proposal more complex? I don't see
why it's better than just embedding it.
> The Receipt should be signed...it could be used as proof of payment by
> wallets.
There's no Receipt message, a SignedPaymentRequest + transactions that
pay to the requested outputs are together the proof of payment.
Re a new URI scheme. Interesting idea, thanks for the suggestion. It
seemed like it'd be easier for merchants to integrate if a single
linked worked for all wallet implementations/versions. But I guess we
could do both schemes, even.
next prev parent reply other threads:[~2012-12-20 17:43 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-26 22:37 Gavin Andresen
2012-11-26 23:02 ` Mike Hearn
2012-11-26 23:13 ` Luke-Jr
2012-11-26 23:16 ` Mike Hearn
2012-11-26 23:19 ` Luke-Jr
2012-11-26 23:27 ` Mike Hearn
2012-11-26 23:32 ` Gregory Maxwell
2012-11-26 23:44 ` Luke-Jr
2012-11-27 0:16 ` Gregory Maxwell
2012-11-27 0:26 ` Mike Hearn
2012-11-27 0:45 ` Rick Wesson
2012-11-27 1:09 ` Gavin
2012-11-27 8:44 ` Mike Hearn
2012-11-27 0:44 ` Luke-Jr
2012-11-26 23:38 ` Rick Wesson
2012-11-26 23:52 ` Jeff Garzik
2012-11-27 0:02 ` Rick Wesson
2012-11-27 0:31 ` Luke-Jr
2012-11-27 0:37 ` Rick Wesson
2012-11-27 2:16 ` Walter Stanish
2012-11-27 2:47 ` Gregory Maxwell
2012-11-27 3:16 ` Walter Stanish
2012-11-27 3:29 ` Rick Wesson
2012-11-27 3:31 ` Walter Stanish
2012-11-27 3:54 ` Rick Wesson
2012-11-27 4:17 ` Walter Stanish
2012-11-27 8:43 ` Michael Gronager
2012-11-27 10:23 ` Mike Hearn
2012-11-27 10:42 ` Michael Gronager
2012-11-27 11:36 ` Pieter Wuille
2012-11-27 11:46 ` Michael Gronager
2012-11-27 12:03 ` Mike Hearn
2012-11-27 12:39 ` Michael Gronager
2012-11-27 14:05 ` Gavin Andresen
2012-11-27 14:26 ` Gavin Andresen
2012-11-28 13:55 ` Walter Stanish
2012-11-27 17:03 ` Andy Parkins
2012-11-27 17:14 ` Mike Hearn
2012-11-27 17:26 ` Andy Parkins
2012-11-27 18:16 ` Mike Hearn
2012-11-27 21:39 ` Gavin Andresen
2012-11-28 10:43 ` Mike Hearn
2012-11-28 12:57 ` Peter Todd
2012-11-28 14:09 ` Gavin Andresen
2012-11-28 8:33 ` Peter Todd
2012-11-28 23:36 ` Roy Badami
2012-11-29 0:30 ` Watson Ladd
2012-11-29 8:16 ` slush
2012-11-29 16:11 ` Gavin Andresen
2012-11-29 17:07 ` Roy Badami
2012-11-29 17:30 ` Gavin Andresen
2012-11-29 17:31 ` Mike Hearn
2012-11-29 18:53 ` Roy Badami
2012-12-01 19:25 ` Gavin Andresen
2012-12-03 19:35 ` Mike Koss
2012-12-03 20:59 ` Gavin Andresen
2012-12-03 21:28 ` Mike Hearn
2012-12-03 22:26 ` Roy Badami
2012-12-03 22:34 ` Jeff Garzik
2012-12-03 22:48 ` Roy Badami
2012-12-16 21:15 ` Melvin Carvalho
2012-12-17 2:18 ` Jeff Garzik
2012-12-17 8:24 ` Melvin Carvalho
2012-12-17 9:19 ` Mike Hearn
2012-12-17 9:31 ` Gary Rowe
2012-12-17 11:23 ` Melvin Carvalho
2012-12-17 17:57 ` Gavin Andresen
2012-12-20 16:53 ` Stephen Pair
2012-12-20 17:43 ` Mike Hearn [this message]
2012-12-20 19:32 ` Stephen Pair
2012-12-21 17:05 ` Stephen Pair
2012-12-24 0:38 ` Elden Tyrell
2012-12-04 17:06 ` Mike Hearn
2012-12-05 19:34 ` Gavin Andresen
2012-12-06 6:31 ` Andreas Petersson
2012-12-06 8:53 ` Mike Hearn
2012-12-06 16:56 ` Gavin Andresen
2012-12-06 17:55 ` Mike Hearn
2012-12-06 19:13 ` Gavin Andresen
2012-12-07 10:45 ` Mike Hearn
2012-12-07 11:01 ` Mike Hearn
2012-12-07 16:19 ` Gavin Andresen
2012-12-07 16:27 ` Mike Hearn
2012-12-06 18:13 ` Alan Reiner
[not found] ` <CALf2ePx5jS@mail.gmail.com>
2014-09-17 19:28 ` Vezalke
2012-12-03 21:42 ` Gregory Maxwell
2012-12-23 2:33 ` Mark Friedenbach
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='CANEZrP162Q=hoqBQvLPm6rT=xNHMOtau42gDzRS4ddEtMFk5Uw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=stephen@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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