From: Mike Hearn <mike@plan99•net>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol thoughts
Date: Wed, 3 Oct 2012 00:44:53 +0200 [thread overview]
Message-ID: <CANEZrP3iot94HW17HpdH9ALMehMQKtRYY0LEe88FgRqU3BAchw@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
I think it's worth pondering the different things we may want in
future, even if that future is quite far out, just to ensure we have a
robust design that won't box us in later. Brainstorming feature ideas
now doesn't commit anyone to implementing them, but it may help
improve the final v1 design.
> + Bitcoin addresses by themselves are insecure against man-in-the-middle
> attacks.
A simple way to solve this problem is just use the SSL identity of the
server that is taking part in the protocol, but it's not much harder
to embed a signature + cert chain into the invoice itself. And once
you're doing that, allowing several different sigs/cert chains is
pretty easy. It means you keep the design open to cases where SSL may
not be appropriate. Eg, you could create invoices signed by your
web-of-trust identity, or some non-SSL Bitcoin specific verification
system.
None of those things have to actually be implemented, but by
considering them now we can make the protocol more future prooof.
> + After sending payment I should have a receipt that proves I followed the
> payee's instructions, so if the payee says they never received the funds I
> can prove that it wasn't my fault.
A signed invoice + the blockchain transactions does this, BUT with a
major caveat: if you have not set up dispute mediation, there is
nobody to prove faultlessness to.
So I'm not sure this would be very useful. Supporting real dispute
mediation seems more practical, but also more work.
> + Protocol for gathering signatures from multiple devices
> (extension/variation of the basic payment protocol, I think).
This would be nice, I think invoices could be wrapped by another
protocol that handles it. I'm not sure it needs to be a part of the
core payment protocol. There are lots of different ways to implement
this and I'm not sure there's agreement on what it should look like -
somebody needs to build a "proprietary" implementation first.
next prev parent reply other threads:[~2012-10-02 22:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-02 16:38 Mike Hearn
2012-10-02 17:43 ` Gavin Andresen
2012-10-02 17:52 ` Peter Vessenes
2012-10-02 18:07 ` Jeff Garzik
2012-10-02 22:35 ` Peter Vessenes
2012-10-02 22:44 ` Mike Hearn [this message]
2012-10-02 22:52 ` Gregory Maxwell
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=CANEZrP3iot94HW17HpdH9ALMehMQKtRYY0LEe88FgRqU3BAchw@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(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