From rusty at rustcorp.com.au  Wed May 10 03:57:41 2017
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 10 May 2017 13:27:41 +0930
Subject: [Lightning-dev] Spontaneous transfers
In-Reply-To: <20170509101924.GC21968@nex>
References: <20170508114724.GB28181@nex> <871sry3jtp.fsf@rustcorp.com.au>
	<20170509101924.GC21968@nex>
Message-ID: <87pofhz7m2.fsf@rustcorp.com.au>

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

Hmm, good point.  I was wrong about stealing 2 bytes from
outgoing_cltv_value, BTW: it needs to be a block height :(

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

Yes.  LD knows the preimage, so can take the funds (if it wins).  The
rest of the onion commits to the *new* rhash and amount, so if it loses
LD launches a new HTLC using the rest of the onion.

> 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?

Well, you can tell if it cheats, since it provides the preimage, you
know you should have won.  You can't prove it to a third party, however.

XOR rules might look like:

        bottom 7 bits = 0000000 -> LD wins (house edge)
        otherwise bottom bit = 1 : LD wins
        otherwise bottom bit = 0 : player wins

Cheers,
Rusty.