From rusty at rustcorp.com.au Mon Nov 7 22:19:48 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 08 Nov 2016 08:49:48 +1030 Subject: [Lightning-dev] Single channel on mobile clients In-Reply-To: References: Message-ID: <878tsvdjaz.fsf@rustcorp.com.au> Anton Kumaigorodskiy writes: >> The recipient can signal that it would accept multipath >> transfers, and the client can decide whether to perform a multipath >> payment >> At this point >> we can only try again with a different path, but the retry logic is >> still not worked out completely at this point. > > What if there was a special protocol for payment requests so that payer > and payee could properly negotiate a number of routes and other details? > > For example, a payee's QR code could contain not H(R)+routing but a server > address and other details sufficient for a payer to establish a connection > with payee's device, then ask for H(R)+routing, then re-ask again if it needs > more routes and again later if payment fails half-way. This seems appropriate > since both devices have to be online anyway to carry out the payment and there > can be many such maintenance servers, each coffee shop may have it's own. I prefer the QR code offering one or more routes from rendevous points, and the payer using some other method to find them (not more communication with the payee). Given two paths to the payee A (D->C->B->A and G->F->E->A), client could start by trying to reach the endpoints D or G, then try C, F, B, E before failing. Of course, if payment failure is common, then this may still be insufficient. Cheers, Rusty.