From cjp at ultimatestunts.nl  Tue Sep 27 18:01:35 2016
From: cjp at ultimatestunts.nl (CJP)
Date: Tue, 27 Sep 2016 20:01:35 +0200
Subject: [Lightning-dev] Atomic payment to multiple parties,
 and payment amount obfuscation
In-Reply-To: <8737kmgkvc.fsf@rustcorp.com.au>
References: <87shtd7syz.fsf@rustcorp.com.au>
	<1474611342.1666.6.camel@ultimatestunts.nl>
	<8737kmgkvc.fsf@rustcorp.com.au>
Message-ID: <1474999295.5451.29.camel@ultimatestunts.nl>

You mentioned two examples of out-of-band distribution of the pre-image:
from B (role 2) to B (role 1), and as a scenario assumption of C
receiving the pre-image out-of-band. I think there is no risk in this.

I think out-of-band distribution of the pre-image is not only harmless:
it is even desirable. If one of the intermediate nodes blocks the
regular distribution, the other ones can commit the transaction on their
channels as soon as they receive the pre-image (in- or out-of-band). The
node on the payee-side of the blocking node can enforce being paid by
the HTLC mechanism, and the node on the payer-side doesn't mind not
having to pay (but can still pay voluntarily). The only nodes
potentially losing funds are the ones that don't follow the regular
protocol.

If you don't have out-of-band distribution of the pre-image, one
blocking node can potentially keep all HTLCs on his payer-side locked
for quite some time (until their time-outs). Eventually they end up
being rolled back, with the blocking node again being the only one
losing funds (which is good).

The advantage of having your HTLCs resolved quickly, so those funds can
flow in the opposite direction quickly, might be a sufficient incentive
for non-regular distribution of the pre-image. In Amiko Pay,
payer->payee distribution is added next to payee->payer distribution,
but it's a voluntary thing, and people might decide to remove it from
their version of Amiko Pay, without any real harm being done.

CJP


Rusty Russell schreef op di 27-09-2016 om 11:33 [+0930]:

> Imagine the simple case where I pay C $4 in fees, via B:
> 
>      $5     $5     $1     $1
>    A ---> B ---> C ---> B ---> A
>     4days   3days  2days  1day
> 
> B can simply use the H-preimage it gets from A to fulfill the HTLC A
> offered, gaining $4 and ignoring C.  If C somehow gets the preimage
> out-of-band, it can claim the $5 from B and then B can get its $1 from
> C.
> 
> The risk (for B) is that C will wait until the C->B HTLC has expired,
> *then* use the B->C HTLC to collect $5, leaving B out-of-pocket.
> 
> Now, there's nothing special about this: the game happens for normal
> fees too, especially since we don't know if two apparently-distinct
> nodes are actually identical.  It's just more tempting when the fees are
> high.
> 
> Fun!
> 
> Thanks,
> Rusty.