[Lightning-dev] Spontaneous transfers

[Rusty Russell]

Christian Decker <decker.christian at gmail.com> writes:
> 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.

Thanks for bringing this up!

> 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) hthat 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.

Anti-probing requires the amount and cltv fields.  We can use the 16
bytes in the onion to communicate a 128-bit R value, however, which
suffices AFAICT.

(If we ever want to support larger amounts we'll need a new onion
version but we can probably avoid enlarging it: steal two bytes from
`outgoing_cltv_value` and have a new max of 720k bitcoins).

>  - 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 :-)

Damn, I thought of doing exactly this trick to implement LightningDice
service just yesterday!  As usual, you're one step ahead :)

You also want to be able to prove to a third party if the server cheats,
so the server revealing the payment preimage should be enough to show
that you lost.  I can't think of a way of doing that with preimages.

But ignoring that, we can pack a full payment hash into a pair of
per_hop, so the LightningDice(TM) service run a pair of neighboring
nodes:

1. LD provides a payment hash as usual.
2. You pick a payment preimage for your winnings.
3. Construct route through the two LD nodes and back to you, except
   1. the payment hash is encoded into the two padding fields for the LD nodes.
   2. the onion switches to commit to your own payment hash for the return

Then if you lose (using your payment hash XOR preimage), LD takes the
money and you can see you lost by receiving the preimage.  If you win,
it simply continues forwarding the onion with the new payment hash and
(increased) amount.

The cool thing about this is that you can pay someone probabalistically
via the LD server (as long as you trust them not to collude on payment
hashes).

> Are there other solutions that we can offer with the existing
> protocol, or are there changes we coiruld 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?

Yes, I think we all have mental lists.  This seems like something work
having a wiki on github for?

Cheers,
Rusty.