Re: [Bitcoin-development] Payment protocol thoughts

[Peter Vessenes <peter@coinlab.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 --]