Good morning Joost,
> > * I convince Rene to make a channel to me. > > You may succeed, but Rene is probably not going to pay you a hold fee because > you're untrusted. Immaterial: I am interested in damaging the Joost-Rusty and Rusty-Rene relationships, not necessarily recouping these funds. > > > > * I connect to Joost. > > * I prepay to Joost. > > * I forward Me->Joost->Rusty->Rene->me. > > * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and > > the tr\*st that Rene has to Rusty. > > * When the HTLC reaches me, I dicker around and wait until it is about to > > time out before ultimately failing. > > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. > > But most importantly: you will have paid hold fees to Joost for the long lock > time of the htlc. This should keep you from even trying this attack. But I might be interested in paying money in order to damage your reputation with Rusty, and damaging the reputation of Rusty with Rene. Thus my capacity to disrupt the network is increased linearly by the number of hops involved, thus my point: I think what should be paid should be for the entire route, not the first hop. For that matter, how certain are you that Rene and Zeeman are not secretly the same person, have you seen them in the same room together? As I pointed out before, the main reason to engage in these attacks is to lock up the capacity of less-capitalized competitors in the payment forwarding business. Cases of slow payment resolution caused by intermediate nodes are more likely to be because of incompetence (crashing nodes, ISP disconnections, clumsy humans tripping on power supplies) than active malice. Thus, the primary motivated attackers are the ends of the payment: the payer and payee, who, in this attack, are coordinating with each other to lock up the funds of multiple other lesser-capacity nodes (and which might be a single node). To an extent, to protect against such attacks, we need to know the payer and payee and somehow judge their tr\*stworthiness --- but we want to not have to reveal their identities, since that works against our privacy. Hmmm. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
