From: Peter Vessenes <peter@coinlab•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol thoughts
Date: Tue, 2 Oct 2012 10:52:04 -0700 [thread overview]
Message-ID: <CAMGNxUuqyASMxu6DyL0n1_k7+Xt-3yeXbP8txiRjdUFrQtHNjA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]
There are tons of scenarios, some discussed here on this list previously,
which would benefit from out of band messages and notes.
This is small, but an interesting tidbit from BTC Foundation payments;
roughly 3-5% of our initial members double-spent. WOW, that's terrible.
I presume that's because they use web wallets without double-click
prevention. But, seriously! A tiny UI issue that's a big deal in an
irrevocable payment system.
On Tue, Oct 2, 2012 at 10:43 AM, Gavin Andresen <gavinandresen@gmail•com>wrote:
> I agree we need a payment protocol, but instead of thinking of all of the
> things we might possibly want I would like to solve a few boring problems
> that we have right now.
>
> Absolutely critical:
>
> + Bitcoin addresses by themselves are insecure against man-in-the-middle
> attacks. We need a payment protocol so if you get a donation link for
> "Bitcoin Foundation" in an email message and click on it you can be
> reasonably certain that your coins will actually go to the Foundation and
> not some hacker at your ISP that modified the email message.
>
>
I'm trying but can't think of a lightweight solution to this off the top of
my head. Not that that proves much.
> + 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.
>
>
+ Protocol for gathering signatures from multiple devices
> (extension/variation of the basic payment protocol, I think).
>
> With the foundation trying to operate without bank accounts, I think it
comes into clarity for me just how innovative and incredibly awesome this
would be for financial controls for companies. Imagine the bookkeeper
inputting payments, and the owner (or 2 of 3 owners) approving them. I can
even imagine large member groups having 2/3 or majority spend rules.
When we talk about stuff like this, I come back around to thinking there
should be many different GUIs -- this use case is more business-y, it's
stuff like this that I always think about the bitcoin testing project
helping provide -- a standard backend that a bookkeeping GUI could go on
top of..
> Not absolutely necessary, but I think v1 should have it anyway:
>
> + Where-to-send-refund information included with payments, so
> overpayments/refunds can be handled efficiently and displayed intelligently
> in the customer's wallet.
>
>
> Everything else I think can wait.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter@coinlab•com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
[-- Attachment #2: Type: text/html, Size: 5574 bytes --]
next prev parent reply other threads:[~2012-10-02 17:52 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 [this message]
2012-10-02 18:07 ` Jeff Garzik
2012-10-02 22:35 ` Peter Vessenes
2012-10-02 22:44 ` Mike Hearn
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=CAMGNxUuqyASMxu6DyL0n1_k7+Xt-3yeXbP8txiRjdUFrQtHNjA@mail.gmail.com \
--to=peter@coinlab$(echo .)com \
--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