1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <roy@gnomon.org.uk>) id 1WQkt0-00065r-Rf
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 21:52:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gnomon.org.uk
designates 93.93.131.22 as permitted sender)
client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
helo=darla.gnomon.org.uk;
Received: from darla.gnomon.org.uk ([93.93.131.22])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WQksy-0003NX-UP
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 21:52:26 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id s2KLq9Li051971
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Thu, 20 Mar 2014 21:52:15 GMT (envelope-from roy@darla.gnomon.org.uk)
Received: (from roy@localhost)
by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id s2KLq9ca051970;
Thu, 20 Mar 2014 21:52:09 GMT (envelope-from roy)
Date: Thu, 20 Mar 2014 21:52:08 +0000
From: Roy Badami <roy@gnomon.org.uk>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140320215208.GC88006@giles.gnomon.org.uk>
References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org>
<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>
<lge7nk$3mf$2@ger.gmane.org>
<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
<CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com>
<CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -1.5 (-)
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 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
X-Headers-End: 1WQksy-0003NX-UP
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
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: Thu, 20 Mar 2014 21:52:27 -0000
On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
> Yes, this overlaps somewhat with the PKI signing in BIP70, but not
> entirely - you might want to serve unsigned payment requests, but
> still have confidentiality and authenticity for a local face to face
> transaction. The signing and encryption does different things
I'm not sure if this what you're getting at, but in a common
face-to-face scenario, it really doesn't overlap so much (in that the
PKI in BIP70 isn't really helpful).
It's not unusual, in a face-to-face transaction at a bricks-and-mortar
establishment, that you know neither the legal name of the entity
running the establishment, nor any electronic identifier (domain name,
email address) that might be presented to you in an X.509 certificate,
even if such a certificate is presented in the PaymentRequest.
In many cases I want/need to simply be assured that I am paying "the
person/organisation which operates that machine behind the counter,
right there".
In many ways I'll miss the simplicity of BIP21 QR codes for
face-to-face transactions - because in this use case the payment
protocol complicates (and in many cases weakens) the assurance that
you really are paying the entity that prepared the QR code.
roy
|
