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
|
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 <mh.in.england@gmail.com>) id 1WwVtF-0008NL-TD
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 12:19:57 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.171 as permitted sender)
client-ip=209.85.214.171; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f171.google.com;
Received: from mail-ob0-f171.google.com ([209.85.214.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwVtE-000799-3z
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 12:19:57 +0000
Received: by mail-ob0-f171.google.com with SMTP id nu7so5656107obb.16
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 05:19:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.181.74 with SMTP id du10mr156527obc.52.1402921190632;
Mon, 16 Jun 2014 05:19:50 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 05:19:50 -0700 (PDT)
In-Reply-To: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
Date: Mon, 16 Jun 2014 14:19:50 +0200
X-Google-Sender-Auth: zJDej7Rm6lzeuyPB4n32rDp7OBI
Message-ID: <CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Lawrence Nahum <lawrence@greenaddress.it>
Content-Type: multipart/alternative; boundary=089e0118479a3734a204fbf30b0b
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WwVtE-000799-3z
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: Mon, 16 Jun 2014 12:19:58 -0000
--089e0118479a3734a204fbf30b0b
Content-Type: text/plain; charset=UTF-8
Looking good! I think this is much better than the original draft. Agree
with Andreas that supports_instant is simply equal to
(supported_instant_providers.size() > 1) which makes it redundant.
Daniel is right that putting every possible provider in the Payment message
might not scale in a world where there are huge numbers of
instant-confirmation providers, but I'm hoping that we never have to scale
to that size, because if we did that'd rather imply that Bitcoin has become
useless for in-person payments without trusted third parties and avoiding
that is rather the whole point of the project :) So I'm OK with some
theoretical lack of scalability for now.
A more scalable approach would be for the user to send the name and
signature of their "instant provider" every time and the merchant just
chooses whether to ignore it or not, but as Lawrence points out, this is
incompatible with the provider charging extra fees for "instantness". But
should we care? I'm trying to imagine what the purchasing experience is
like with optional paid-for third party anti-double-spend protection.
Ultimately it's the merchant who cares about this, not me, so why would I
ever pay? It makes no sense for me to pay for double spend protection for
the merchant: after all, I'm honest. This is why it doesn't make sense for
me to pay miners fees either, it's the *receiver* who cares about
confirmations, not the sender.
So I wonder if a smarter design is that the user always submits the details
of their instantness provider and we just don't allow for optional
selection of instantness. I'm not sure that works, UX wise, so is having a
less scalable design to support it worthwhile?
--089e0118479a3734a204fbf30b0b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Looking good! I think this is m=
uch better than the original draft. Agree with Andreas that supports_instan=
t is simply equal to (supported_instant_providers.size() > 1) which make=
s it redundant.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Daniel is r=
ight that putting every possible provider in the Payment message might not =
scale in a world where there are huge numbers of instant-confirmation provi=
ders, but I'm hoping that we never have to scale to that size, because =
if we did that'd rather imply that Bitcoin has become useless for in-pe=
rson payments without trusted third parties and avoiding that is rather the=
whole point of the project :) So I'm OK with some theoretical lack of =
scalability for now. </div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">A more scal=
able approach would be for the user to send the name and signature of their=
"instant provider" every time and the merchant just chooses whet=
her to ignore it or not, but as Lawrence points out, this is incompatible w=
ith the provider charging extra fees for "instantness". But shoul=
d we care? I'm trying to imagine what the purchasing experience is like=
with optional paid-for third party anti-double-spend protection. Ultimatel=
y it's the merchant who cares about this, not me, so why would I ever p=
ay? It makes no sense for me to pay for double spend protection for the mer=
chant: after all, I'm honest. This is why it doesn't make sense for=
me to pay miners fees either, it's the <i>receiver</i>=C2=A0who cares =
about confirmations, not the sender.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So I wonder=
if a smarter design is that the user always submits the details of their i=
nstantness provider and we just don't allow for optional selection of i=
nstantness. I'm not sure that works, UX wise, so is having a less scala=
ble design to support it worthwhile?</div>
</div>
--089e0118479a3734a204fbf30b0b--
|
