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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alexy.kot.all@gmail.com>) id 1WRZOY-0003F8-4r
for bitcoin-development@lists.sourceforge.net;
Sun, 23 Mar 2014 03:48:22 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.128.170 as permitted sender)
client-ip=209.85.128.170; envelope-from=alexy.kot.all@gmail.com;
helo=mail-ve0-f170.google.com;
Received: from mail-ve0-f170.google.com ([209.85.128.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WRZOX-0004Y0-DL
for bitcoin-development@lists.sourceforge.net;
Sun, 23 Mar 2014 03:48:22 +0000
Received: by mail-ve0-f170.google.com with SMTP id pa12so4299038veb.15
for <bitcoin-development@lists.sourceforge.net>;
Sat, 22 Mar 2014 20:48:15 -0700 (PDT)
X-Received: by 10.220.95.139 with SMTP id d11mr278428vcn.21.1395546495907;
Sat, 22 Mar 2014 20:48:15 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.59.0.38 with HTTP; Sat, 22 Mar 2014 20:47:35 -0700 (PDT)
In-Reply-To: <CANEZrP1=i6eYaJq3JWbQhofrkLExt9ZKEy-Vuq6q48n+UWKWjw@mail.gmail.com>
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>
<20140320121221.GA25052@netbook.cypherspace.org>
<CAJHLa0NeFdXzioQrmK6iKzr85pL3vvTAQH2_vKM3M+T+ZWYjgQ@mail.gmail.com>
<lgh47n$tnn$2@ger.gmane.org>
<CALDj+BbX+ejz+diWDGFJUyOLR6+GnbDyiiNpmEbHybNBj=jL7A@mail.gmail.com>
<CAJHLa0OK1vRiqoHDNYrbO9fNTa8tcY9dMsJ5fC0qpsHS80zvbg@mail.gmail.com>
<532DC076.4060007@monetize.io>
<CAJHLa0NtpFnvWLNa=poOKho-wH7gXevNj=WfAaoWFxDMCSCZrw@mail.gmail.com>
<CANEZrP1=i6eYaJq3JWbQhofrkLExt9ZKEy-Vuq6q48n+UWKWjw@mail.gmail.com>
From: Alex Kotenko <alexykot@gmail.com>
Date: Sun, 23 Mar 2014 03:47:35 +0000
X-Google-Sender-Auth: iDeSHTmD0aoS-D7DMyPmMyEc6GQ
Message-ID: <CALDj+BZpBx1bKis-RGxt9q8vnJ4Ds4a=-LmAS_gHCEgGOeBMfw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c2ae7627fc1904f53dfdee
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
(alexy.kot.all[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: 1WRZOX-0004Y0-DL
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: Sun, 23 Mar 2014 03:48:22 -0000
--001a11c2ae7627fc1904f53dfdee
Content-Type: text/plain; charset=UTF-8
I know that general approach to interaction design in Bitcoin assumes
minimal to no difference between payer and payee, and generally I agree
with this approach.
However, for the sake of my PoS development this assumption is wrong by
default, as PoS is a specialized hardware, and one who cared to buy and
install it is probably not in the same situation as the other party that
didn't care to by anything dedicated.
In short - from PoS point of view there is a customer and a merchant. And
my goal is to make thing work in assumption of fast and reliable connection
on merchant side and no connection requirement at all from customer side.
I didn't put a silly example, as of my experience there are really a lot of
places where cellphone connection isn't good enough for reliable Bitcoin
operation. However, if we're talking about merchant establishments - we can
hope for private local WiFi or wired connection on PoS side, so PoS
internet connection shouldn't be an issue. So this is the use case I'm
designing around and this is why bluetooth based BIP70 implementation is
important for me.
I partly agree with Mike on user interface and IOU idea, but I have no
intention to implement anything like that right now.
--001a11c2ae7627fc1904f53dfdee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier =
new,monospace;color:#003300">I know that general approach to interaction de=
sign in Bitcoin assumes minimal to no difference between payer and payee, a=
nd generally I agree with this approach.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300">However, for the sake of my PoS development this assumption is =
wrong by default, as PoS is a specialized hardware, and one who cared to bu=
y and install it is probably not in the same situation as the other party t=
hat didn't care to by anything dedicated.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace;color:#003300">In short - from PoS point of view there i=
s a customer and a merchant. And my goal is to make thing work in assumptio=
n of fast and reliable connection on merchant side and no connection requir=
ement at all from customer side.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace;color:#003300">I didn't put a silly example, as of m=
y experience there are really a lot of places where cellphone connection is=
n't good enough for reliable Bitcoin operation. However, if we're t=
alking about merchant establishments - we can hope for private local WiFi o=
r wired connection on PoS side, so PoS internet connection shouldn't be=
an issue. So this is the use case I'm designing around and this is why=
bluetooth based BIP70 implementation is important for me.</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace;color:#003300">I partly agree with Mike on user interfac=
e and IOU idea, but I have no intention to implement anything like that rig=
ht now.</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_extra"><div class=3D"gmail_defaul=
t" style=3D"font-family:'courier new',monospace;color:rgb(0,51,0)">=
<br></div>
</div></div>
--001a11c2ae7627fc1904f53dfdee--
|
