Hi Antoine
I've got a lot to catch up on re channel jamming but just to say I'm deeply
skeptical about attempting to embed a reputation layer or reputation
credentials into the Lightning protocol. Admittedly I'm somewhat of a curious
amateur in the field of reputation systems but a number of people (me included)
have had to look into reputation systems in the past for projects/startups they
were working on and centralized​​ reputation systems are absolute minefields to
manage effectively though some corporations do manage it. Decentralized
reputation systems baked into a protocol is just a step too far. All you need
is one edge case where the attacker can ensure an innocent party is blamed and
the reputation system falls apart. The protocol developer is in the position of
assessing who is telling the truth out of two opposing viewpoints on Reddit etc.
I do think reputation systems will play a key part in a future Lightning
Network (to some extent they already are with sites like 1ML and Amboss) but
they won't be managed by protocol devs, they will be managed by multiple
flavors of companies and projects (hopefully open source but most likely closed
source too, for profit, non-profit etc) who are free to use whatever metrics
and weigh those metrics however they like. The protocol just can't afford to
expand into areas where there is case by case judgment and statistical analysis
required. It will become bloated, ineffective and put protocol developers in
the position of deciding who ultimately receives routing fees rather than just
enabling payments can get from A to B. Identity is easier, you either control a
private key or you don't. Reputation is much more difficult, there will be some
attacks where a probabilistic assessment will need to be made on who the
perpetrator of the attack was. You don't add that to the (already long) list of
protocol developers' responsibilities.
So feel free to continue to explore reputation and reputation systems but a
strong warning that this is likely not solved at the protocol level. Decisions
protocol developers make will impact what data can be collected and how easy
that data is to collect (there are already some tricky trade-offs with regards
to privacy, routing success and transparency for when things go wrong) but
beyond that protocol developers should leave it to others. I've included some
links to some additional reading on reputation systems in case you are
interested.
Thanks
Michael
[0]:
https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/
[1]:
https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175
[2]: https://www.bitrated.com/faq
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--- Original Message ---
On Monday, November 21st, 2022 at 06:01, Antoine Riard
wrote:
> Hi LN Devs,
>
> tl;dr A formalization of a reputation-based scheme to solve channel jamming
> is proposed. The system relies on "credentials" issued by routing hops and
> requested to be attached to each HTLC forward request. The "credentials" can
> be used by a reputation algorithm to reward/punish payment senders and
> allocate channel liquidity resources efficiently. The "credentials" initial
> distribution can be bootstrapped leveraging one-time upfront fees paid toward
> the routing hops. Afterwards, the "credentials" subsequent distribution can
> rely on previous HTLC traffic.
>
> A protocol description can be found here, with few extensions already to the
> BOLTs:
>
> https://github.com/lightning/bolts/pull/1043
>
> There is also a work-in-progress proof-of-concept in LDK (on top of our
> coming soon^TM HTLC intercepting API):
>
> https://github.com/lightningdevkit/rust-lightning/pull/1848
>
> This work builds on previous reputation-scheme research [0] [1]. It also
> integrates the more recent proposals of upfront fees as a straightforward
> mechanism to bootstrap the reputation system. Bootstrapping the system with
> more economically cost-effective privacy-preserving UTXO ownership proofs not
> only add another layer of engineering complexity, there is still a proof size
> vs proof generation/validation trade-off to arbiter between ZKP cryptosystems.
>
> Rather to seek for a game-theory equilibrium defined as a breakeven point as
> in the latest unconditional fee research [2], this proposal aims to use
> reputation credentials to allow HTLC traffic-shaping. This not only should
> protect against jamming situations (either malicious
> or spontaneous) but also allow active HTLC traffic-shaping, where a routing
> hop can allow extended channel liquidity lockups based on accumulated
> reputation (e.g for hold-invoices). This is also a reduced overhead cost, as
> upfront fees are only paid at bootstrap, or when the HTLC forward behavior
> can be qualifie
