From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A4F27AD for ; 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 ; Mon, 10 Aug 2015 21:02:44 +0000 (UTC) Received: by wibhh20 with SMTP id hh20so167747772wib.0 for ; 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 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 To: Gavin Andresen Message-ID: <20150810210240.GC12450@navy> References: <55C79FF0.8040100@thinlink.com> <55C7CECB.7050905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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