Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-20 📝 Original message: On Fri, Aug 21, 2015 at ...

📅 Original date posted:2015-08-20
📝 Original message:
On Fri, Aug 21, 2015 at 12:12:15AM +0200, Anthony Towns wrote:
> But C could achieve that outcome on its own, just by delaying
> notifying B until near the timeout; no collusion necessary. In any
> event, if the transaction's going to succeed, the money on the B-C
> channel's HTLC is going to be C's, so C is mainly depriving itself by
> filing to communicate.

Yes, the point is that pending sends between participants in this cartel
have a shorter time than outside this cartel. So the point is that
C<->D<->E links will always have shorter HTLCs in transit than B's. It's
only C holding it up, but before that D and E decided not to hold it up.

> If you have B and D collude instead, so that E reveals R to D, and D
> reveals R to B instead of C, then the payments could go:
>
> D pays E
> D reveals R to B
> A pays B
> B pays D
>
> with the transaction from B->C and C->D remaining open until the
> timeout, but everyone else is square.??? That would inconvenience C,
> possibly cheaply for B and D. If there's already a channel between B
> and D (for the "B pays D" step), I'm not sure why B and D wouldn't
> just announce that, and once it was announced, I don't see why A would
> route via C anyway...

Perhaps I may be misunderstanding things, but the purpose of not
announcing is to collectively make any paths to C delay closing out the
HTLC as long as possible, so that anyone that transacts with C has to
wait a long time, which will decrease the incentive to transact with C.
So the threat is that if C is being attacked, and B is not colluding,
then A and B will dislike transacting with C, even though it's not C's
fault. There's insufficient incentive to push funds when closing out the
HTLC (as opposed to pulling), e.g. A->B, due to the off-chance they
forget, but I may be wrong here, this is a bit speculative.

--
Joseph Poon