From: Stephen Pair <stephen@bitpay•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Date: Fri, 21 Dec 2012 12:05:21 -0500 [thread overview]
Message-ID: <CADb9v0JaKFuDCY=NHRYQEjUAt4VKVm5pO2XZHgVttKYv-iQisg@mail.gmail.com> (raw)
In-Reply-To: <CADb9v0Lc3HDpLO_ZdibPcxyrggACVfG+482oj72=986pfSc4mA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]
The more I think about this topic, the more I think the first task at hand
is to implement secure, private messaging...the nature of any messages
(payment requests or otherwise) sent between wallets is such that it needs
to be secured. And the great thing is that it's easy to do and you don't
need to solve the PKI problem. Have the wallet maintain one or more ECC
key pairs for the purposes of signing and encrypting messages. Allow these
to be shared between wallets, or exported/imported, etc. You can punt on
the whole topic of verifying the others' public keys using PKI (I mean,
people use bitcoin addresses today without the use of any formal or
explicit PKI to verify them...people will make do without it for
communications keys just fine...and they can always use PGP or other PKI if
they feel the need...most people would just pick up the phone to verify a
friend's public key)...this also doesn't preclude the use of X.509 for the
merchant/customer scenario...
For a payment protocol, you could do something like this: use https & ssl
certificates/CAs as one method of obtaining an ECC public key...pki_type
could be "https" and pki_bytes could be a url for the https location to
download the ECC public key. The software would reject (or warn) if the
SSL certificate isn't considered valid by the normal CA validation process.
The wallet would not necessarily need to permanently store ECC public keys
obtained in this manner. This approach doesn't require people to obtain
new certificates just for bitcoin.
In fact, there would be very little difference to the proposed payments
protocol if this approach were taken...instead of using X.509 directly for
signing and encrypting messages, you are using it for signing and
encrypting the ECC public key exchange. And this allows people that don't
have web servers or SSL certificates to exchange their ECC public keys by
other means and be able to use this payment protocol as well as any others
that one could imagine. So, I actually think this is a better way of
keeping PKI out of the scope of the proposal.
Payment requests are just one kind of messaging between wallets. I've also
mentioned the "cheques" feature. I'm sure there are many more
possibilities. Having a uniform method of securing messages sent between
wallets (that doesn't depend on external tools) would be a great step
forward IMO.
[-- Attachment #2: Type: text/html, Size: 2613 bytes --]
next prev parent reply other threads:[~2012-12-21 17:06 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
2012-12-20 19:32 ` Stephen Pair
2012-12-21 17:05 ` Stephen Pair [this message]
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='CADb9v0JaKFuDCY=NHRYQEjUAt4VKVm5pO2XZHgVttKYv-iQisg@mail.gmail.com' \
--to=stephen@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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