Hi, This is unclear on which criterias the endorsement decision is made >
A node endorses an HTLC if and only if it came from a neighbour that has reputation 1 that endorsed it. > Additionally, this is unclear how the available liquidity/slots on a given > outbound channel are initially distributed between all the inbound channels > (e.g proportional to the capacity) and how they're balanced once the > inbound channels start to accumulate reputation. > The quotas are for any incoming HTLC that is either from a neighbour with reputation 0, or is not endorsed. For each channel, the quotas are independent of other channels and independent of the neighbour that forwarded the HTLC. > I don't know if this local reputation scheme precises how reputation is > slashed in case of HTLC failure, and if any "grace" amount/rate is granted > to the inbound channel counterparty, e.g Alice. > > Independently of those considerations, I think this local reputation > scheme might suffer from exploitable reputation asymmetries by a jamming > adversary. > Let's say you have the topology: > > Alice - Bob - Caroll - Dave > > Alice accumulated a reputation of 1 towards Bob and same for Bob towards > Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up > 2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him > before relay to Caroll, Alice can now inflict a 50 sat damage to Caroll, > while only encumbering the lower-priced reputational cost towards Bob. > > This concern could hold in case of asymmetries arising from the dynamic > adjustment of routing fees during an evaluated period of time. E.g both Bob > and Caroll requires routing fees of 1000 msat. Alice builds up a reputation > of 1 towards Bob during this period N. At period N+1, Caroll bumps her > routing fees to 2000 msat. From now on, Alice can exploit this asymmetry. > In general, if Bob is a low flow node (resulting in it having a low threshold for reputation), he cannot have a high reputation with Carroll as he will never forward enough. Taking into account the differences in fees is interesting, but should be checked further.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
