From decker.christian at gmail.com  Mon May  8 11:47:24 2017
From: decker.christian at gmail.com (Christian Decker)
Date: Mon, 8 May 2017 13:47:24 +0200
Subject: [Lightning-dev] Spontaneous transfers
Message-ID: <20170508114724.GB28181@nex>

Hi all,

following the current discussion about invoice based transfers, I've
been contacted by some users that would like us to consider other
use-cases as well. They'd like not to have to go through the
invoice-transfer-release cycle that invoices support, e.g., donations
withough prior contact between the recipient and the sender.

The recurring requirements for these transfers are that a) the
recipient gets the payment preimage so that she can trigger the
clearing of the HTLC, and b) that there is a mechanism that signals to
the recipient who the sender is, without out of band communication.

So assuming Alice is the sender and Bob is the recipient I cam up with
the following possible solutions:

 - We can stuff that information into the routing info. We have the
   flexibility of adding a new realm in there, and the last hop does
   not contain much useful information currently. So we'd define a new
   "realm" that basically let's the per-hop payload be interpreted as
   the sender information, and we can put R and Alice's ID in there.

 - Another option is that Alice can create a circular route, from
   Alice sending `X+fees` to Bob and then `fees` back to herself,
   i.e., masquerading the payment as an oversized fee that is
   deposited at Bob. This way Alice can trigger the payment herself,
   but we can't communicate the sender's identity to Bob. We may even
   be able to build the game in such a way that the payout of the
   winning amount is the second half of the route, if Alice wins at
   all.

I think the first option is probably the easiest and cleanest, and the
second one is more of a novelty, but it'd allow the creation of a
gambling service that does not know the identity of its players :-)

Are there other solutions that we can offer with the existing
protocol, or are there changes we could add for a v1.1 that would
better accomodate these use-cases?

Cheers,
Christian

P.S.: I'm seeing quite a few of these ideas being repeated, because we
haven't documented these brainstorming ideas anywhere, shall we use
the lightning-rfc wiki on Github to catch them, so we can reference
them and maybe formulate them as BOLTs later?