summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndreas Schildbach <andreas@schildbach.de>2014-01-27 19:18:11 +0100
committerbitcoindev <bitcoindev@gnusha.org>2014-01-27 18:18:31 +0000
commit33fa783e7174257a4bfabab10615a3213cfb729c (patch)
tree2303c985562aa108bd3d60e38452f8a217603dd8
parenta076e4e33c6a2c5f261db224def7d1d8fa75708e (diff)
downloadpi-bitcoindev-33fa783e7174257a4bfabab10615a3213cfb729c.tar.gz
pi-bitcoindev-33fa783e7174257a4bfabab10615a3213cfb729c.zip
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
-rw-r--r--56/d3200187be8f6a1d635ce4e118159111746627172
1 files changed, 172 insertions, 0 deletions
diff --git a/56/d3200187be8f6a1d635ce4e118159111746627 b/56/d3200187be8f6a1d635ce4e118159111746627
new file mode 100644
index 000000000..f08015f41
--- /dev/null
+++ b/56/d3200187be8f6a1d635ce4e118159111746627
@@ -0,0 +1,172 @@
+Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
+ helo=mx.sourceforge.net)
+ by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <gcbd-bitcoin-development@m.gmane.org>)
+ id 1W7qlT-0003yu-Ub for bitcoin-development@lists.sourceforge.net;
+ Mon, 27 Jan 2014 18:18:31 +0000
+Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
+ designates 80.91.229.3 as permitted sender)
+ client-ip=80.91.229.3;
+ envelope-from=gcbd-bitcoin-development@m.gmane.org;
+ helo=plane.gmane.org;
+Received: from plane.gmane.org ([80.91.229.3])
+ by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
+ (Exim 4.76) id 1W7qlS-0007FT-NE
+ for bitcoin-development@lists.sourceforge.net;
+ Mon, 27 Jan 2014 18:18:31 +0000
+Received: from list by plane.gmane.org with local (Exim 4.69)
+ (envelope-from <gcbd-bitcoin-development@m.gmane.org>)
+ id 1W7qlL-0001fz-TQ for bitcoin-development@lists.sourceforge.net;
+ Mon, 27 Jan 2014 19:18:23 +0100
+Received: from f053014231.adsl.alicedsl.de ([78.53.14.231])
+ by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
+ id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
+ Mon, 27 Jan 2014 19:18:23 +0100
+Received: from andreas by f053014231.adsl.alicedsl.de with local (Gmexim 0.1
+ (Debian)) id 1AlnuQ-0007hv-00
+ for <bitcoin-development@lists.sourceforge.net>;
+ Mon, 27 Jan 2014 19:18:23 +0100
+X-Injected-Via-Gmane: http://gmane.org/
+To: bitcoin-development@lists.sourceforge.net
+From: Andreas Schildbach <andreas@schildbach.de>
+Date: Mon, 27 Jan 2014 19:18:11 +0100
+Message-ID: <lc67sl$h3$1@ger.gmane.org>
+References: <lc5hmg$1jh$1@ger.gmane.org>
+ <CANEZrP3POX5SACS18_rrQxx=mzmthrM418zmd8Z7-5CBNFSW4Q@mail.gmail.com>
+Mime-Version: 1.0
+Content-Type: text/plain; charset=ISO-8859-1
+Content-Transfer-Encoding: 7bit
+X-Complaints-To: usenet@ger.gmane.org
+X-Gmane-NNTP-Posting-Host: f053014231.adsl.alicedsl.de
+User-Agent: Mozilla/5.0 (X11; Linux x86_64;
+ rv:24.0) Gecko/20100101 Thunderbird/24.2.0
+In-Reply-To: <CANEZrP3POX5SACS18_rrQxx=mzmthrM418zmd8Z7-5CBNFSW4Q@mail.gmail.com>
+X-Spam-Score: -0.9 (/)
+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
+ See http://spamassassin.org/tag/ for more details.
+ -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
+ no trust [80.91.229.3 listed in list.dnswl.org]
+ -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
+ sender-domain
+ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
+ 1.1 DKIM_ADSP_ALL No valid author signature,
+ domain signs all mail
+ -0.0 SPF_PASS SPF: sender matches SPF record
+ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
+ domain
+X-Headers-End: 1W7qlS-0007FT-NE
+Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
+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: Mon, 27 Jan 2014 18:18:32 -0000
+
+On 01/27/2014 02:11 PM, Mike Hearn wrote:
+
+> I would like to see Bluetooth continue to work for scan-to-pay even in
+> the signed case. So for this reason the current approach with a BTMAC
+> parameter in the Bitcoin URI seems to work universally across NFC tags
+> and QR codes, and would allow download of a signed PaymentRequest even
+> in the case where a QR code is used.
+
+I'm not saying I'm against signed payment requests, but unfortunately
+they are just too big for QR-codes. Then again, QR-codes *can* take up
+to 2 KB. How big would a very basic trust chain plus signature be?
+
+> Because a Bitcoin URI already contains a public key (hash), re-using
+> that to establish an encrypted/authd connection on top of an insecure
+> RFCOMM socket would seem to be relatively straightforward.
+
+I was under the impression that addresses will go away. Can you
+elaborate on the mechanism?
+
+> Obviously such QR-encoded payment requests cannot grow in size as much
+> as using other media. In particular, I expect PKI signed requests are
+> out of question. However, in face to face payments the value of a sig
+> based on PKI is highly questionable, and the fact the sig cannot be
+> verified without TCP connectivity doesn't help.
+>
+> Just a correction here - the reason signed payment requests are "large"
+> (about 4000 bytes) is exactly because they *can* be verified offline,
+> i.e. by a Trezor. The signed payment request contains all the data
+> needed to establish its authenticity, including certificates and the
+> signature itself. No TCP connection is needed.
+
+Ok, that's good news (to me). However, you are going to manage trust
+stores (adding and revoking) without TCP?
+
+> For face to face payments, I think signing is still useful. For one, we
+> want to keep the distinction between "merchant" and "user" as blurry and
+> indistinct as possible. A strong separation between merchants and
+> consumers is one of the many bad things about the credit card system.
+
+Ack.
+
+> Whilst initially we'd expect the payment protocol to be used by online
+> webshops, in future it could be used by little corner shops, children's
+> lemonade stands and so on.
+
+Well I'm thinking the other way round. Use Bitcoin where its already
+used today -- face to face.
+
+> you probably still would like a receipt if you buy
+> something from a local market trader.
+
+Yes, but where is the problem?
+
+> Another use case - we heard a story about a restaurant owner who
+> accepted Bitcoin. He printed a static bitcoin URI onto a QR code on the
+> menu. A month or two later he discovered one of his waiters had
+> re-printed the menus with his own QR code! The people thought they had
+> been paying for the meal, and in fact it went right into the pocket of
+> the waiter.
+
+Sad story, but it's really a special case. Using a printed QR-code is
+clearly the wrong tool for his task, for several reasons.
+
+And again, how is he going to provide the payment request to the payer
+without TCP?
+
+> As to how it works, well, that's not hard. Comodo give away free email
+> address certs with a few mouse clicks, it's no harder than signing up
+> for a website.
+
+We don't want to force people to sign up anywhere. Bitcoin is instant-on.
+
+> - I chose to re-use the "bitcoin:" URL scheme
+>
+> Other wallets won't know what to do with it and would yield a strange
+> error message.
+
+Which is why I said we need some transition time.
+
+> Rather than pack a file into a URL, if you don't want to
+> use the current r= extension it's better for apps to just register to
+> handle .bitcoinpaymentrequest files / the right MIME type. Downloading
+> it and opening it would do the right thing automatically.
+
+That's a good point. I'll implement this asap.
+
+> Remember BIP 73 also! It says that with the apps built-in QR scanner, if
+> you scan an HTTP[S] URI, you should try downloading it with a magic
+> header. That way you can get a payment request file out of the server.
+> Without the magic header (i.e. a normal generic barcode scanner app) it
+> would open a web page containing a bitcoin URI clickable link.
+
+Interesting, did not know about this BIP. However I don't understand the
+usecase. Its not like my browsers always display QR-codes with URL of
+the page being shown. And if the page in question bothers to show a QR
+code, it could just as well also link to a payment request resource (as
+suggested above).
+
+
+
+