From: Anthony Towns <aj@erisian.com.au>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] What Lightning Is
Date: Tue, 11 Aug 2015 05:02:40 +0800 [thread overview]
Message-ID: <20150810210240.GC12450@navy> (raw)
In-Reply-To: <CABsx9T03BXULmu_mNq+3Qd-68CYpYy67+CpMV9hCYaYb1Bc+1A@mail.gmail.com>
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
next prev parent reply other threads:[~2015-08-10 21:02 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 14:25 [bitcoin-dev] Block size following technological growth Pieter Wuille
2015-07-30 15:04 ` Greg Sanders
2015-07-30 15:12 ` Jorge Timón
2015-07-30 16:23 ` Jameson Lopp
2015-07-30 16:36 ` Bryan Bishop
2015-07-30 16:43 ` Jameson Lopp
2015-07-30 16:36 ` Venzen Khaosan
2015-07-30 17:51 ` Jorge Timón
2015-07-30 18:00 ` Jorge Timón
2015-07-30 16:56 ` Gary Mulder
2015-07-30 17:13 ` Mark Friedenbach
2015-07-30 16:20 ` Gavin Andresen
2015-07-30 16:41 ` Suhas Daftuar
2015-07-30 16:48 ` Adam Back
2015-07-30 16:49 ` Pieter Wuille
2015-07-31 10:16 ` Mike Hearn
2015-07-31 11:43 ` Venzen Khaosan
2015-07-31 11:51 ` Jorge Timón
2015-07-31 12:15 ` Mike Hearn
2015-07-31 13:07 ` Marcel Jamin
2015-07-31 14:33 ` Jorge Timón
2015-07-31 14:58 ` Mike Hearn
2015-07-31 15:28 ` Venzen Khaosan
2015-07-31 20:09 ` Elliot Olds
2015-08-04 10:35 ` Jorge Timón
2015-08-04 11:04 ` Hector Chu
2015-08-04 11:27 ` Pieter Wuille
2015-08-04 11:34 ` Hector Chu
2015-08-04 12:10 ` Venzen Khaosan
2015-08-04 13:13 ` Jorge Timón
2015-08-04 13:28 ` Hector Chu
2015-08-04 13:42 ` Venzen Khaosan
2015-08-04 17:59 ` Jorge Timón
2015-08-04 13:12 ` Gavin Andresen
2015-08-04 13:54 ` Pieter Wuille
2015-08-04 14:30 ` Venzen Khaosan
2015-08-04 14:43 ` [bitcoin-dev] Fwd: " Venzen Khaosan
2015-08-04 14:45 ` [bitcoin-dev] " Alex Morcos
2015-08-05 8:14 ` Gareth Williams
2015-08-04 11:59 ` Jorge Timón
2015-08-04 12:19 ` Hector Chu
2015-08-04 13:34 ` Venzen Khaosan
2015-08-04 13:37 ` Jorge Timón
2015-08-05 7:29 ` Elliot Olds
2015-08-06 1:26 ` Jorge Timón
2015-08-06 13:40 ` Gavin Andresen
2015-08-06 14:06 ` Pieter Wuille
2015-08-06 14:21 ` Gavin Andresen
2015-08-06 14:53 ` Pieter Wuille
[not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com>
2015-08-06 15:24 ` [bitcoin-dev] Fwd: " Gavin Andresen
2015-08-06 15:26 ` Pieter Wuille
2015-08-06 18:43 ` Michael Naber
2015-08-06 18:52 ` Pieter Wuille
2015-08-07 16:06 ` Thomas Zander
2015-08-07 16:30 ` Pieter Wuille
2015-08-07 17:00 ` Thomas Zander
2015-08-07 17:09 ` Pieter Wuille
2015-08-07 21:35 ` Thomas Zander
2015-08-07 22:53 ` Adam Back
2015-08-08 16:54 ` Dave Scotese
2015-08-07 17:50 ` Gavin Andresen
2015-08-07 18:05 ` Jameson Lopp
2015-08-07 18:10 ` Pieter Wuille
2015-08-07 21:43 ` Thomas Zander
2015-08-07 22:00 ` Thomas Zander
2015-08-06 16:19 ` [bitcoin-dev] " Tom Harding
2015-08-06 21:56 ` Peter Todd
2015-08-06 15:25 ` Jorge Timón
2015-08-06 16:03 ` Gavin Andresen
2015-08-06 16:11 ` Mike Hearn
2015-08-06 17:15 ` Jorge Timón
2015-08-06 19:42 ` Gavin Andresen
2015-08-06 20:01 ` Pieter Wuille
2015-08-06 21:51 ` Jorge Timón
2015-08-06 23:09 ` Elliot Olds
2015-08-10 19:28 ` Jorge Timón
2015-08-11 5:48 ` Elliot Olds
2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding
2015-08-09 18:54 ` Mark Friedenbach
2015-08-09 20:14 ` Hector Chu
[not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>
2015-08-09 20:48 ` Hector Chu
2015-08-10 4:48 ` Joseph Poon
2015-08-10 17:03 ` odinn
2015-08-10 17:14 ` Pieter Wuille
2015-08-10 17:45 ` odinn
2015-08-09 21:27 ` Tom Harding
2015-08-09 21:40 ` Chris Pacia
2015-08-09 21:45 ` Hector Chu
2015-08-09 21:57 ` Patrick Strateman
2015-08-09 22:03 ` Hector Chu
2015-08-09 22:36 ` Patrick Strateman
2015-08-10 1:52 ` Tom Harding
2015-08-10 3:31 ` Patrick Strateman
2015-08-09 22:06 ` Patrick Strateman
2015-08-09 22:09 ` Hector Chu
2015-08-09 22:27 ` Patrick Strateman
2015-08-09 22:30 ` Hector Chu
2015-08-09 22:44 ` Gavin Andresen
2015-08-09 22:51 ` Btc Drak
2015-08-10 8:27 ` Thomas Zander
2015-08-10 8:36 ` Patrick Strateman
2015-08-10 4:39 ` Joseph Poon
2015-08-10 21:02 ` Anthony Towns [this message]
2015-08-10 21:19 ` Anthony Towns
2015-08-10 21:43 ` Adam Back
2015-08-11 9:01 ` Hector Chu
2015-08-11 17:17 ` Simon Liu
2015-07-31 14:52 ` [bitcoin-dev] Block size following technological growth Bryan Bishop
2015-07-30 17:46 ` Jorge Timón
2015-08-02 22:35 ` Anthony Towns
2015-07-30 20:20 ` Thomas Zander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150810210240.GC12450@navy \
--to=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=gavinandresen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox