{"type":"rich","version":"1.0","author_name":"npub1uyhgpz5nsfnvdlcqm3erjsdjasd9pdeaejeetwtkvumm6mp3ujlqxt9vwk","author_url":"https://nostr.ae/npub1uyhgpz5nsfnvdlcqm3erjsdjasd9pdeaejeetwtkvumm6mp3ujlqxt9vwk","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-11-21\n📝 Original message:\nDear Antoine and list,\n\nI think that another call to discuss jamming would be great. I would\nsuggest making it a repeating call every 2 weeks, starting from Monday the\n28th at 7 pm UTC.\n\nAntoine - Thank you for your work!\nI have a few questions to better understand the details.\n\n1. Are the tokens transferable between users? For example, if Ned is a\nrouting node, and Alice has some of their tokens, can she give these tokens\nto Bob?\nIf yes - could this lead to the creation of a secondary market?\nIf no - will that slow down the transaction flow that a new node can send?\n\n2. Do you have a recommended policy for the creation of tokens and their\nuse? Ideally, there will be a policy that would mitigate both slow and\nquick jamming, without harming usability too much.\n\n3. You write \"the reputation credentials to liquidity units translation can\nbe severed\" - does this mean that the value of the token changes? Is that\nin the spirit of changing the fees in a channel?\nIf this is the case, can't a routing node \"trick\" a user into buying many\ntokens and then bring the price up?\n\n4. How would these tokens work with blinded paths and other\nprivacy-preserving suggestions?\n\nThanks again,\nClara\n\nOn Sun, Nov 20, 2022 at 11:01 PM Antoine Riard \u003cantoine.riard at gmail.com\u003e\nwrote:\n\n\u003e Hi LN Devs,\n\u003e\n\u003e tl;dr A formalization of a reputation-based scheme to solve channel\n\u003e jamming is proposed. The system relies on \"credentials\" issued by routing\n\u003e hops and requested to be attached to each HTLC forward request. The\n\u003e \"credentials\" can be used by a reputation algorithm to reward/punish\n\u003e payment senders and allocate channel liquidity resources efficiently. The\n\u003e \"credentials\"  initial distribution can be bootstrapped leveraging one-time\n\u003e upfront fees paid toward the routing hops. Afterwards, the \"credentials\"\n\u003e subsequent distribution can rely on previous HTLC traffic.\n\u003e\n\u003e A protocol description can be found here, with few extensions already to\n\u003e the BOLTs:\n\u003e\n\u003e https://github.com/lightning/bolts/pull/1043\n\u003e\n\u003e There is also a work-in-progress proof-of-concept in LDK (on top of our\n\u003e coming soon^TM  HTLC intercepting API):\n\u003e\n\u003e https://github.com/lightningdevkit/rust-lightning/pull/1848\n\u003e\n\u003e This work builds on previous reputation-scheme research [0] [1]. It also\n\u003e integrates the more recent proposals of upfront fees as a straightforward\n\u003e mechanism to bootstrap the reputation system. Bootstrapping the system with\n\u003e more economically cost-effective privacy-preserving UTXO ownership proofs\n\u003e not only add another layer of engineering complexity, there is still a\n\u003e proof size vs proof generation/validation trade-off to arbiter between ZKP\n\u003e cryptosystems.\n\u003e\n\u003e Rather to seek for a game-theory equilibrium defined as a breakeven point\n\u003e as in the latest unconditional fee research [2], this proposal aims to use\n\u003e reputation credentials to allow HTLC traffic-shaping. This not only should\n\u003e protect against jamming situations (either malicious\n\u003e or spontaneous) but also allow active HTLC traffic-shaping, where a\n\u003e routing hop can allow extended channel liquidity lockups based on\n\u003e accumulated reputation (e.g for hold-invoices). This is also a reduced\n\u003e overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC\n\u003e forward behavior can be qualified as \"whitewashing\" from the routing hop\n\u003e viewpoint.\n\u003e\n\u003e It should be noted, this current reputation-credential architectural\n\u003e framework assumes credentials distribution at the endpoint of the network.\n\u003e However, the framework should be flexible enough for the credentials to be\n\u003e harvested by the LSPs, and then distributed in a secondary fashion to their\n\u003e spokes, when they need it, or even attached transparently thanks to\n\u003e trampoline. So one design intuition, there is no strong attachment of the\n\u003e reputation to the endpoint HTLC sender, even if the protocol is described\n\u003e in a \"flat\" view for now.\n\u003e\n\u003e Let's evaluate quickly this mitigation proposal against a few criterias\n\u003e emerged from recent research.\n\u003e\n\u003e The mitigation is effective, in the sense a routing hop can apply a\n\u003e proportional relationship between the acquisition of the reputation and the\n\u003e amount of liquidity resources credited in function of said reputation. In a\n\u003e period of steady state, the reputation acquisition cost can be downgraded\n\u003e to 0. In periods of channel congestion, the reputation credentials to\n\u003e liquidity units translation can be severed, in the limit of routing hop\n\u003e acceptable competitiveness.\n\u003e\n\u003e The mitigation is incentive-compatible, if the credentials are not honored\n\u003e by their issuers, the HTLC senders can evict them from the routing network\n\u003e view for a while. The successful usage of credentials can lead to more\n\u003e credentials allocated for longer and more capacity-intensive channel\n\u003e lockups. In case of HTLC failure, the failure source could be forgiven by\n\u003e routing hops to maintain the worthiness of the sender credentials.\n\u003e\n\u003e The mitigation can be made transparent from the user, as the credentials\n\u003e harvesting can be done automatically from a pre-allocated budget, similar\n\u003e to the fee-bumping reserves requirement introduced by anchor output. At the\n\u003e end of today, if we take modern browsers as an example, the average user\n\u003e doesn't check manually the TLS certificates (for what they're worth...).\n\u003e\n\u003e The mitigation can conserve high-level privacy, as the usage of blinded\n\u003e signature (or another equivalent cryptosystem breaking signature/message\n\u003e linking) should allow the credentials issued during a preliminary phase to\n\u003e be undistinguishable during the redeem/usage phase. New CPU/memory DoS\n\u003e vectors due to the credentials processing should be watched out.\n\u003e\n\u003e About the ease of implementation, there are few protocol messages to\n\u003e modify, a HTLC intercepting API is assumed as supported by the\n\u003e implementation, onion messages support is also implied, landing EC blinded\n\u003e signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms\n\u003e adaptations might be more serious but still reasonable. The\n\u003e \"credentials-to-liquidity\" allocation algorithms are likely the new real\n\u003e beast, though I don't think any reputation scheme can spare them.\n\u003e\n\u003e There could be a concern about the centralization inertia introduced by a\n\u003e reputation system.  Intuitively, the argument can be made that any\n\u003e historical tracking (such as routing buckets) favor established LN\n\u003e incumbents at the gain of efficiency. A counter-argument can be made, a new\n\u003e routing hop can lower the acquisition cost of its issued credentials to\n\u003e attract more HTLC traffic (accepting higher jamming risk).\n\u003e\n\u003e On the ecosystem impacts, it should be studied that this proposal would\n\u003e impact things like inbound channel routing fees [3], ratecard [4] or\n\u003e flow-control valve [5] and the whole liquidity toolchain. Hopefully, we\n\u003e don't significantly restrain the design space for future LN protocol\n\u003e upgrades.\n\u003e\n\u003e On the proposal modularity and flexibility, each routing node has\n\u003e oversight on its routing policy, acquisition methods, credentials to\n\u003e liquidity rate. New acquisition methods can be experimented or deployed\n\u003e when ready, e.g stakes certificates with only e2e upgrade. The credentials\n\u003e themselves could have \"innate\" expiration time if we use things like\n\u003e short-lived ZKP [6]. The credentials framework can be extended beyond\n\u003e solving jamming, as a generalized risk-management framework for Bitcoin\n\u003e decentralized financial network, e.g transaction signature exchange\n\u003e ordering in multi-party transactions [7] or finding reliable Coinjoin\n\u003e counterparties.\n\u003e\n\u003e Feedback welcome.\n\u003e\n\u003e Cheers,\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html\n\u003e [3]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html\n\u003e [4]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html\n\u003e [5]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html\n\u003e [6] https://eprint.iacr.org/2022/190.pdf\n\u003e [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221121/ae6ba7de/attachment.html\u003e"}