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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WwYrO-0006mM-5r for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 15:30:14 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WwYrL-0006FP-Rz
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 15:30:14 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WwYrE-0003UJ-7B for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 17:30:04 +0200
Received: from 93-35-10-132.ip52.fastwebnet.it ([93.35.10.132])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 17:30:04 +0200
Received: from lawrence by 93-35-10-132.ip52.fastwebnet.it with local (Gmexim
0.1 (Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 17:30:04 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Lawrence Nahum <lawrence@greenaddress.it>
Date: Mon, 16 Jun 2014 15:28:00 +0000 (UTC)
Message-ID: <loom.20140616T170619-497@post.gmane.org>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 93.35.10.132 (Mozilla/5.0 (X11;
Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/35.0.1916.114 Safari/537.36)
X-Spam-Score: -2.5 (--)
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
-0.0 SPF_PASS SPF: sender matches SPF record
-1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WwYrL-0006FP-Rz
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 15:30:14 -0000
Mike Hearn <mike <at> plan99.net> writes:
[snip]
> 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.
Hard to say for now. I like the current simplicity but if someone can come
up with some use case for other options we should discuss and investigate
them. I don't see more than a bunch of accepted payment methods anywhere I
ever been in my life, I don't see merchants trusting more than a handful of
third parties.
> 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?
I think you are wrong here.
Just because up to date credit cards charged the merchant which in turn
charged you and the ordinary cash payer doesn't mean a newer and better
system can't be transparent from day one.
Ultimately you care because the alternative is to wait.
> It makes no sense for me to pay for double spend protection for the
merchant: after all, I'm honest.
It's quite simple, in a low amounts world people will probably accept zero
confs, just like occasionally people can walk out with a bag of crisps
without paying from a Pret in London. Guards would cost more than what
they'd save from thefts.
With higher amounts they will either not accept bitcoin unless instant
confirmed or they will make you wait if that's even feasible (unlikely in a
supermarket or petrol station but perfectly fine at the restaurant maybe).
> 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.
You care too: time and money, or just money if you want to use the old
simplification.
> 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?
We would not support that I think. Explicit is better than implicit.
We will charge for instant confirmation and wouldn't want the user charged
unless pre-agreed, especially if then they also have to wait because the
instant tx was not recognized as such.
Yeah we can charge the merchant that can then in turn charge you, we may as
well charge you and be transparent about it but also have deals with
merchant where they pay fixed amounts per month for unlimited tx and make it
free for their users.
Perhaps just like today people ask you which card you are going to use and
they may not accept Amex or Diners the same will go for instant and they,
the merchants, will just pick the instant provider from a touch screen
before allowing the payment in.
|
