From decker.christian at gmail.com  Tue May  9 10:19:24 2017
From: decker.christian at gmail.com (Christian Decker)
Date: Tue, 9 May 2017 12:19:24 +0200
Subject: [Lightning-dev] Spontaneous transfers
In-Reply-To: <871sry3jtp.fsf@rustcorp.com.au>
References: <20170508114724.GB28181@nex>
 <871sry3jtp.fsf@rustcorp.com.au>
Message-ID: <20170509101924.GC21968@nex>

On Tue, May 09, 2017 at 10:52:42AM +0930, Rusty Russell wrote:
> 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).

Right, we can't use those fields, and 16 bytes is not sufficient to
identify the sender. But we could probably use it for a prefix lookup
in our routing table and then derive the payment preimage from
that. If this is the last hop the `channel_id` is also empty, and we
can use that as well. By defining a new realm we can also reorder the
fields to have 24 contiguous bytes.

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

Ah I see, I had a bit of trouble seeing how we could create a route
that commits to the 2 possible outcomes, since the HMAC commits to the
`amt_to_forward`, so there'd be no way of forwarding either wins or
losses. You're saying that the route simply stops at LD if we lose.

The XORing is quite interesting though I can't really see how it'd
work yet. LD would commit to a secret by sending you the hash, you
construct a route using that hash and your own pick (payment hash for
the second half) on the first half and then send the winnings back to
me using my own pick? How are you combining the LD hash and your own
hash to make it provably fair and giving LD the ability to pull the
payment in say 50% of the cases?

Cheers,
Christian