{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-11-21\n📝 Original message:\nHi LN Devs,\n\ntl;dr A formalization of a reputation-based scheme to solve channel jamming\nis proposed. The system relies on \"credentials\" issued by routing hops and\nrequested to be attached to each HTLC forward request. The \"credentials\"\ncan be used by a reputation algorithm to reward/punish payment senders and\nallocate channel liquidity resources efficiently. The \"credentials\"\ninitial distribution can be bootstrapped leveraging one-time upfront fees\npaid toward the routing hops. Afterwards, the \"credentials\" subsequent\ndistribution can rely on previous HTLC traffic.\n\nA protocol description can be found here, with few extensions already to\nthe BOLTs:\n\nhttps://github.com/lightning/bolts/pull/1043\n\nThere is also a work-in-progress proof-of-concept in LDK (on top of our\ncoming soon^TM  HTLC intercepting API):\n\nhttps://github.com/lightningdevkit/rust-lightning/pull/1848\n\nThis work builds on previous reputation-scheme research [0] [1]. It also\nintegrates the more recent proposals of upfront fees as a straightforward\nmechanism to bootstrap the reputation system. Bootstrapping the system with\nmore economically cost-effective privacy-preserving UTXO ownership proofs\nnot only add another layer of engineering complexity, there is still a\nproof size vs proof generation/validation trade-off to arbiter between ZKP\ncryptosystems.\n\nRather to seek for a game-theory equilibrium defined as a breakeven point\nas in the latest unconditional fee research [2], this proposal aims to use\nreputation credentials to allow HTLC traffic-shaping. This not only should\nprotect against jamming situations (either malicious\nor spontaneous) but also allow active HTLC traffic-shaping, where a routing\nhop can allow extended channel liquidity lockups based on accumulated\nreputation (e.g for hold-invoices). This is also a reduced overhead cost,\nas upfront fees are only paid at bootstrap, or when the HTLC forward\nbehavior can be qualified as \"whitewashing\" from the routing hop viewpoint.\n\nIt should be noted, this current reputation-credential architectural\nframework assumes credentials distribution at the endpoint of the network.\nHowever, the framework should be flexible enough for the credentials to be\nharvested by the LSPs, and then distributed in a secondary fashion to their\nspokes, when they need it, or even attached transparently thanks to\ntrampoline. So one design intuition, there is no strong attachment of the\nreputation to the endpoint HTLC sender, even if the protocol is described\nin a \"flat\" view for now.\n\nLet's evaluate quickly this mitigation proposal against a few criterias\nemerged from recent research.\n\nThe mitigation is effective, in the sense a routing hop can apply a\nproportional relationship between the acquisition of the reputation and the\namount of liquidity resources credited in function of said reputation. In a\nperiod of steady state, the reputation acquisition cost can be downgraded\nto 0. In periods of channel congestion, the reputation credentials to\nliquidity units translation can be severed, in the limit of routing hop\nacceptable competitiveness.\n\nThe mitigation is incentive-compatible, if the credentials are not honored\nby their issuers, the HTLC senders can evict them from the routing network\nview for a while. The successful usage of credentials can lead to more\ncredentials allocated for longer and more capacity-intensive channel\nlockups. In case of HTLC failure, the failure source could be forgiven by\nrouting hops to maintain the worthiness of the sender credentials.\n\nThe mitigation can be made transparent from the user, as the credentials\nharvesting can be done automatically from a pre-allocated budget, similar\nto the fee-bumping reserves requirement introduced by anchor output. At the\nend of today, if we take modern browsers as an example, the average user\ndoesn't check manually the TLS certificates (for what they're worth...).\n\nThe mitigation can conserve high-level privacy, as the usage of blinded\nsignature (or another equivalent cryptosystem breaking signature/message\nlinking) should allow the credentials issued during a preliminary phase to\nbe undistinguishable during the redeem/usage phase. New CPU/memory DoS\nvectors due to the credentials processing should be watched out.\n\nAbout the ease of implementation, there are few protocol messages to\nmodify, a HTLC intercepting API is assumed as supported by the\nimplementation, onion messages support is also implied, landing EC blinded\nsignature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms\nadaptations might be more serious but still reasonable. The\n\"credentials-to-liquidity\" allocation algorithms are likely the new real\nbeast, though I don't think any reputation scheme can spare them.\n\nThere could be a concern about the centralization inertia introduced by a\nreputation system.  Intuitively, the argument can be made that any\nhistorical tracking (such as routing buckets) favor established LN\nincumbents at the gain of efficiency. A counter-argument can be made, a new\nrouting hop can lower the acquisition cost of its issued credentials to\nattract more HTLC traffic (accepting higher jamming risk).\n\nOn the ecosystem impacts, it should be studied that this proposal would\nimpact things like inbound channel routing fees [3], ratecard [4] or\nflow-control valve [5] and the whole liquidity toolchain. Hopefully, we\ndon't significantly restrain the design space for future LN protocol\nupgrades.\n\nOn the proposal modularity and flexibility, each routing node has oversight\non its routing policy, acquisition methods, credentials to liquidity rate.\nNew acquisition methods can be experimented or deployed when ready, e.g\nstakes certificates with only e2e upgrade. The credentials themselves could\nhave \"innate\" expiration time if we use things like short-lived ZKP [6].\nThe credentials framework can be extended beyond solving jamming, as a\ngeneralized risk-management framework for Bitcoin decentralized financial\nnetwork, e.g transaction signature exchange ordering in multi-party\ntransactions [7] or finding reliable Coinjoin counterparties.\n\nFeedback welcome.\n\nCheers,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html\n[1]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html\n[2]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html\n[3]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html\n[4]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html\n[5]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html\n[6] https://eprint.iacr.org/2022/190.pdf\n[7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221120/2a736ba2/attachment.html\u003e"}