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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
|
Return-Path: <anthony.j.towns@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A4F27AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 21:02:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9BA9F15D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 21:02:44 +0000 (UTC)
Received: by wibhh20 with SMTP id hh20so167747772wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 14:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=sender:date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=6pKUccZ2X3hgFJL6jFQj+T8uDoTKG4dQOHHwn8m0p1M=;
b=ZGA/3PQGvCJuM2CCDoC1e1mjiCoETJMIRu7G5UCa7opYvdY+a9tszLdKeNBuXf8pCs
n7WOxc7SZRPU1YyIo7JCGXBAgAhyThOpp3H9B35FuJ0UyvJUeUyemdREqzMqphXCPL/p
yZoZarn0Ot91mrAGhT7IcqQJeGx2lZtS7Cy/dS0YNAJlr9XLN9G3VkeMwkRMyUR5XGom
GF8tReXcAEXav8aA9/f8KEr0WcIBQRfjaMeY17YvtYOQq80G+D6r1LWGBcw+ru9V8bnM
oYAxUQr3jAb9fCGF+PAdJUHy6QQ+5EBXF5CdHZVi0uMjbONCL4iuJ60RXvTgMq6GGec9
Ys6A==
X-Received: by 10.180.8.135 with SMTP id r7mr28674848wia.58.1439240563460;
Mon, 10 Aug 2015 14:02:43 -0700 (PDT)
Received: from erisian.com.au (tmo-102-58.customers.d1-online.com.
[80.187.102.58]) by smtp.gmail.com with ESMTPSA id
lu5sm31273119wjb.9.2015.08.10.14.02.41
(version=TLS1 cipher=RC4-SHA bits=128/128);
Mon, 10 Aug 2015 14:02:42 -0700 (PDT)
Sender: Anthony Towns <anthony.j.towns@gmail.com>
Received: by erisian.com.au (sSMTP sendmail emulation);
Tue, 11 Aug 2015 05:02:40 +0800
Date: Tue, 11 Aug 2015 05:02:40 +0800
From: Anthony Towns <aj@erisian.com.au>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20150810210240.GC12450@navy>
References: <CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<55C79FF0.8040100@thinlink.com>
<CAOG=w-skYq84=PtN45FB-dGoY1783Jz7K1T16e2JVGjLazWuyA@mail.gmail.com>
<CALJP9GDMgqn2VeR4y4RVxqJ_iW57hExwXBHNSkxo+-AK+7Zb6g@mail.gmail.com>
<55C7CECB.7050905@gmail.com>
<CAAO2FKFBC46rFe7FV+F_H0gPiVfY8S7g09O2RNxMoZMCwywp6A@mail.gmail.com>
<CABsx9T03BXULmu_mNq+3Qd-68CYpYy67+CpMV9hCYaYb1Bc+1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T03BXULmu_mNq+3Qd-68CYpYy67+CpMV9hCYaYb1Bc+1A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] What Lightning Is
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 21:02:45 -0000
On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote:
> I'd love to see somebody write up a higher-level description of what the
> user experience is like, what communication happens underneath, and what
> new pieces of infrastructure need to get built to make it all work.
>
> A use-case to start with:
>
> A customer starts with eleven on-chain bitcoin. They want to pay for a nice
> cup of tea.
IMO:
1. User swipes their phone over merchant's NFC device
(or scans a QR code displayed by the register or whatever)
2. Dialog pops up on phone:
"Pay Infinitea $5.20? [yes] [no]"
3. User presses [yes]
4. Brief pause
5. "Payment confirmed" appears on both user's phone and merchant's POS
device
The backend bits that need to happen:
1. Merchant passes on their identity and public key, an amount, and a
hash for the payment.
2. User's phone goes online to see if a route to the vendor can be
worked out, and to work out what lightning network fees are needed.
Also translates the bitcoins requested into the user's preferred
currency so they don't have to do maths in their head.
3. User's phone prepares a lightning transaction to the vendor, signed
with the corresponding lightning channel keys, using the hash the
merchant provided, and sends it through one of the channels the user
already has open and funded (at >$5.20 worth of bitcoins).
4. The transaction makes its way through the lightning network, and the
confirmation makes its way back. It's not clear to me how long this
realistically takes (either how many hops are likely, or how long
a single hop will actually take; I assume it should be a couple
of seconds).
5. UIs at both ends update. User gets a nice cup of tea.
There's a few potential problems with this:
- what if the merchant says "no you didn't pay me, your phone is lying,
you're a liar, I hate you, no tea for you" despite your phone saying
you paid?
a) you could mitigate this by having the payments be incremental
(here's 1c, 520 times) with both terminals visibly updating;
but that would take up to 520x longer than sending a single
transaction, and mightn't really be any better anyway
b) you could also have the initial negotiation involve signing
something that could be adjudicated independently later (hey,
here's a QR code saying he owed me a tea, here's a QR code showing
I paid for it, and here's a video of him saying "no tea for you").
c) Or maybe you just bite the $5 and never shop there again; just
as you would if you handed over $5.20 in cash and then they told
you you hadn't paid them.
- what if the transaction's unroutable? then you get a "service
unavailable" notice on your phone and pay by other means -- blockchain,
cash, etc. Same as if your credit card won't register. ditto if your
phone can't get on the internet.
- what if the fees are large? (eg, the coffee costs $5, and the fees are
20c?)
a) I think they'll actually be small -- even for a 10% pa interest
rate denominated in bitcoin, the time-value of $5.20 in bitcoin
for 7 days is just under 1c (.35%). If so, that's noise, and the
user legitimately doesn't care. OTOH, it does get multiplied by
number of hops, and maybe the user cares about $5.20 vs $5.26.
b) Alternatively, the app could just indicate the fees ("Pay $5.20 +
<1c in fees") and/or the user could have an explicit setting for
fee info ("Only warn me when fees are greater than either 5c/1%")
c) Or you could have some UI magic, so the vendor's POS device
initially says "advertised price is $5.20, but I actually
expect just $5.05, call the rest a discount", the phone says
"fees are 5c, so I'll display "Pay just $5.10 for a $5.20 cup of
coffee!". That's closer to how Visa/Mastercard do it and might
be reasonable in many cases.
- what happens if the user presses "yes" but the lightning transaction
then fails? you don't want to wait for the 7 day timeout to know if
you can have a cup of tea; and you don't want the payment to go through
after you've paid for your tea in cash, drank it, and gone home.
a) Maybe the lightning network hubs just reply early cancelling the
transactions, and your phone can say "failed". You can't force
them to do this, but maybe the incentives work out okay so that
they'll want to anyway. (I think they will) If so, everything's
fine. As far as the merchant's concerned, you may as well have
just pressed "No".
b) The vendor could issue a conditional refund, eg an on-blockchain
transaction for the amount of the coffee from them to you,
payable if you ever receive the hash token. (And if you don't,
redeemable by them after a timeout). That doesn't work real well
if the fee for a blockchain txn is more than the price of a cup
of tea of course.
> Assume neither the customer nor the tea shop are technically sophisticated
> -- assume the customer is using an SPV wallet and the tea shop is using a
> service similar to Bitpay.
IMHO, most of the complexity isn't in doing the transaction, it's in
maintaining the channels. For example:
- what if the tea shop has a sudden run of customers, and all their
payment channels fill up?
- how do you close the till at the end of the day (ie, put your
earnings into a cold wallet so they can't be hacked as easily and
clear your channel so you can accept more payments tomorrow?) Do you
do this on the blockchain or do you have a different lightning
network channel to your "bank account"?
- inversely; if you do all your weekly shopping and impulse buys (tea,
coffee, beer, meals, groceries, fuel, road tolls, ...) on lightning,
how do you reset your channels once a day/week/fortnight/month with
some money from your salary/savings, so they don't run out?
- do refunds work, even after the original txn has finished? ("Oh,
actually we're out of tea")
- you have to watch the blockchain once a week or so in case your
counterparty tries stealing your balance by replaying old states and
hoping you don't notice
- how do you keep the channel keys/secrets sufficiently available
and secure?
- how do you figure out who to make channels with in the first place,
and if/when to change them?
- what happens if your phone breaks, is stolen or gets lost; have you
lost your channel secrets, and potentially all the coins in your
balance?
- etc.
(I don't think they're unsolvable or anything, though)
Cheers,
aj
|
