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"><<a href=3D"mailto:lawrence@greenaddress.it" target=3D"_blank">= lawrence@greenaddress.it</a>></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--