Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <sebastien.requiem@gmail.com>) id 1Wznlz-0006hh-7d
	for bitcoin-development@lists.sourceforge.net;
	Wed, 25 Jun 2014 14:02:03 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.174 as permitted sender)
	client-ip=74.125.82.174;
	envelope-from=sebastien.requiem@gmail.com;
	helo=mail-we0-f174.google.com; 
Received: from mail-we0-f174.google.com ([74.125.82.174])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wznlx-0005ms-6B
	for bitcoin-development@lists.sourceforge.net;
	Wed, 25 Jun 2014 14:02:03 +0000
Received: by mail-we0-f174.google.com with SMTP id u57so2136198wes.19
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 25 Jun 2014 07:01:52 -0700 (PDT)
X-Received: by 10.180.108.68 with SMTP id hi4mr5724355wib.80.1403704912080;
	Wed, 25 Jun 2014 07:01:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.24.225 with HTTP; Wed, 25 Jun 2014 07:01:31 -0700 (PDT)
In-Reply-To: <loom.20140618T140509-802@post.gmane.org>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
	<lnhgsk$va6$1@ger.gmane.org> <loom.20140615T111027-736@post.gmane.org>
	<lnk4ii$ehf$1@ger.gmane.org> <loom.20140618T140509-802@post.gmane.org>
From: sebastien requiem <sebastien.requiem@gmail.com>
Date: Wed, 25 Jun 2014 16:01:31 +0200
Message-ID: <CABLWKA9nownE3NSpnTokxrGDcL6W2wasiQKYem0taP7qJBOVyA@mail.gmail.com>
To: Lawrence Nahum <lawrence@greenaddress.it>
Content-Type: multipart/alternative; boundary=e89a8f3ba53da773e304fca984a0
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(sebastien.requiem[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Wznlx-0005ms-6B
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
 backwards compatible proto buffer extension
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 14:02:03 -0000

--e89a8f3ba53da773e304fca984a0
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 18, 2014 at 2:09 PM, Lawrence Nahum <lawrence@greenaddress.it>
wrote:

> [snip]
>
> Allow me to recap BIP changes in discussion:
>
> - making some changes to allow merchants to offer discounts in case of
> instant ?
> - allowing multiple signatures ?
>
> Did I miss anything? Thoughts on the above from others?
>

Jumping on this thread after reading it all. I am in favor of the
discount offered by the merchant.

Ideally the merchant could get the amount of the wallet *fee*
for instant payment (privacy leak?). That way, the merchant
could decide to support the instant payment at 100% (better
user experience after all) or at 50% only or at 0%.

This would encourage instant payment for merchants and buyers without
(re-)creating a non-transparent system.

regards,


-- 
sebastien requiem - bendingspoons.com

--e89a8f3ba53da773e304fca984a0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Jun 18, 2014 at 2:09 PM, Lawrence Nahum <span dir=
=3D"ltr">&lt;<a href=3D"mailto:lawrence@greenaddress.it" target=3D"_blank">=
lawrence@greenaddress.it</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">[snip]<br><div>
<br>
Allow me to recap BIP changes in discussion:<br>
<br>
- making some changes to allow merchants to offer discounts in case of<br>
instant ?<br>
- allowing multiple signatures ?<br>
<br>
Did I miss anything? Thoughts on the above from others?<br>
</div></blockquote><div><br></div><div>Jumping on this thread after reading=
 it all. I am in favor of the<br>discount offered by the merchant.<br><br>I=
deally the merchant could get the amount of the wallet *fee*<br>for instant=
 payment (privacy leak?). That way, the merchant<br>

could decide to support the instant payment at 100% (better<br>user experie=
nce after all) or at 50% only or at 0%.<br><br></div>This would encourage i=
nstant payment for merchants and buyers without<br>(re-)creating a non-tran=
sparent system.<br>

</div><div class=3D"gmail_quote"><div><br></div><div>regards,<br></div><div=
><br>=C2=A0</div></div>-- <br>sebastien requiem - <a href=3D"http://bending=
spoons.com">bendingspoons.com</a><br></div></div>

--e89a8f3ba53da773e304fca984a0--