From: Mike Hearn <mike@plan99.net>
To: Tamas Blummer <tamas@bitsofproof.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 70 refund field
Date: Fri, 28 Mar 2014 16:23:10 +0100 [thread overview]
Message-ID: <CANEZrP26+hWJaFYkZ2oUKhr9FQ03CXCdvt8V1Mm4mGJaPCy2Hw@mail.gmail.com> (raw)
In-Reply-To: <85A1792C-502E-4AC6-B8BC-A10C8FC1917F@bitsofproof.com>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
So I take it BOPShop won't be supporting BIP70 then? :(
On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer <tamas@bitsofproof.com>wrote:
> I have nothing against incremental development. This will however not pick
> up until it offers some incremental benefit compared to current payment
> processor solutions,
> such as e.g.
>
> 1. Symmetrical. One can also offer a payment.
> 2. Aggregating and Netting. Handle multiple installments and/or net with
> previous cash flows.
> 3. More secure. One has a check not only on the payment address (which
> already has one with https:// in the web shop scenario it is currently
> able support) but not on the refund.
>
>
> On 28.03.2014, at 15:01, Gavin Andresen <gavinandresen@gmail.com> wrote:
>
> On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <tamas@bitsofproof.com>wrote:
>
>> May I ask how the current payment protocol is supposed to handle salaries?
>>
>
> It doesn't.
>
> "walk before you run" and all that; lets see what problems we run into
> with the minimal payment protocol we have now (like refund outputs you have
> to remember forever) before we create an insurmountable set of problems by
> trying to solve everything we can think of all at once.
>
> --
> --
> Gavin Andresen
>
>
>
[-- Attachment #2: Type: text/html, Size: 2221 bytes --]
next prev parent reply other threads:[~2014-03-28 15:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 11:07 [Bitcoin-development] BIP 70 refund field Mike Hearn
2014-03-28 11:25 ` Andreas Schildbach
2014-03-28 11:31 ` Mike Hearn
2014-03-28 16:59 ` Andreas Schildbach
2014-03-28 18:19 ` Mike Hearn
2014-03-28 20:56 ` Andreas Schildbach
2014-03-29 9:27 ` Roy Badami
2014-03-29 13:29 ` Mike Hearn
2014-03-30 17:21 ` Andreas Schildbach
2014-03-28 11:38 ` Wladimir
2014-03-28 11:45 ` Tamas Blummer
2014-03-28 11:46 ` Mike Hearn
2014-03-28 11:54 ` Tamas Blummer
2014-03-28 12:27 ` Mike Hearn
2014-03-28 12:55 ` Tamas Blummer
2014-03-28 13:00 ` Mike Hearn
2014-03-28 13:09 ` Tamas Blummer
2014-03-28 11:30 ` Tamas Blummer
2014-03-28 13:18 ` Tamas Blummer
2014-03-28 14:01 ` Gavin Andresen
2014-03-28 14:06 ` Mike Hearn
2014-03-28 14:27 ` Tamas Blummer
2014-03-28 15:23 ` Mike Hearn [this message]
2014-03-28 15:26 ` Tamas Blummer
2014-03-28 16:34 ` Mike Hearn
2014-03-28 16:45 ` Tamas Blummer
2014-03-31 9:23 ` Peter Todd
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=CANEZrP26+hWJaFYkZ2oUKhr9FQ03CXCdvt8V1Mm4mGJaPCy2Hw@mail.gmail.com \
--to=mike@plan99.net \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=tamas@bitsofproof.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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