{"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 Clara,\n\nThanks for reading!\n\n\u003e I think that another call to discuss jamming would be great. I would\n\u003e suggest making it a repeating call every 2 weeks, starting from Monday the\n\u003e 28th at 7 pm UTC.\n\nCool to take the initiative, the schedule works for me, however this slot\nmight conflict with the Core Lightning engineering call ? I remember we\nmoved the LDK meeting time from 7pm to 5pm, as we had folks willing to\nattend both.\n\n\u003e 1. Are the tokens transferable between users? For example, if Ned is a\n\u003e routing node, and Alice has some of their tokens, can she give these\ntokens\n\u003e to Bob?\n\u003e If yes - could this lead to the creation of a secondary market?\n\u003e If no - will that slow down the transaction flow that a new node can send?\n\nCurrent version of the proposal, there is nothing preventing the tokens to\nbe transferred between the users, Alice can give these tokens to Bob. We\ncould make them binding to the prover, by requesting a new round where\nAlice registers a pubkey towards Ned, and all tokens should be\ncounter-authenticated by Ned at forward. Ned would flag out the\ndouble-usage of tokens, ideally in a ZKP-way. Still I think this would\nnever prevent Alice from sharing her key material with Bob. So I'm not sure\nwe can prevent a secondary-market, and it might be even more valuable if we\nwould like LSPs to collect tokens for their spokes nodes to simplify UX.\n\nThat said, beyond unlinkability between the blinded message and the\ncleartext tokens/signatures, I think all the properties should be open to\nmore research.\n\n\u003e 2. Do you have a recommended policy for the creation of tokens and their\n\u003e use? Ideally, there will be a policy that would mitigate both slow and\n\u003e quick jamming, without harming usability too much.\n\nIf by recommend policy, you mean the set of algorithms that should guide\nthe token quantity, rate issuance, token acquisition cost, and the\nadaptations in function of the local channel congestion, or even the\ngossips of the other routing nodes, not at all. Just intuition, I think a\nsimple model should start from enforcing a proportionality between token\nacquisition costs and the available channels liquidity, then you can add\nmore factors in function of your risk model.\n\nAbout the slow/quick jamming distinction, I still believe a good\nanti-jamming solution should aim to solve things in a continuous fashion,\nrather than a discrete one. That way binds better to the reality of\ndiffering hold time Lightning HTLC: simple payment, offline receive,\nhold-invoice,  swaps, etc...\n\n\u003e 3. You write \"the reputation credentials to liquidity units translation\ncan\n\u003e be severed\" - does this mean that the value of the token changes? Is that\n\u003e in the spirit of changing the fees in a channel?\n\u003e If this is the case, can't a routing node \"trick\" a user into buying many\n\u003e tokens and then bring the price up?\n\nYes, the \"liquidity value\" of the tokens is currently left as a floating\nparameter. This is a good question if it should be fixed and only the\nrouting fees should fluctuate in function of channel congestion, or\nfloating e.g when the global quantity of tokens are required to re-dilute\ntheir current values to maintain some proportion between acquisition cost\nand available liquidity.\n\nFor sure, a routing node could \"trick\" a user into buying many tokens and\nthen break the promise of not only bringing the price up but also plainly\nreject HTLC forward requests satisfying the announced routing policy.\nThough note the user's routing algorithms could penalize in retorsion the\nnode, if the routing policy gossiped isn't respected.\n\n\u003e 4. How would these tokens work with blinded paths and other\n\u003e privacy-preserving suggestions?\n\nPrimarily, the tokens could use the new onion messages and blinded paths\nfor the dissemination and renewal rounds. Current design assumes they're\nattached to the HTLC during forward along the payment path, though I think\none design alternative could be completely detached, and the HTLC onion\njust contains a ref to the tokens.\n\n\nZooming out, after submitting this proposal to the mailing list yesterday,\nI thought how much a token/credentials system bootstrapped on pre-paid fees\nshould be classified into monetary strategy or a reputation-based strategy,\nand it turns out as there is an acquisition cost associated to the tokens,\nin fact it might belong more to the monetary strategy classification. So I\nwonder now if the usage of the reputation in the proposal title isn't\nmisleading and if a \"breakeven point\" isn't still implied (\"the\nproportionality\" seeked). From a history of ideas standpoint, a\nreputation-based strategy was more the Stakes Certificate solution\noriginally proposed in 2020. Though this proposal reuses the liquidity\nunits/credit score introduced there.\n\nI think more and more we should have a \"two-tier\" mitigation strategy,\nwhere the base tier is strictly defined in \"pure fees\" terms, and then\nlayered on top of a reputation system. A routing node could deviate from\nthe zero risk \"pure fees\" ones to increase its routing fees returns, by\nrelying more on assumptions like \"Past HTLC senders behave well if there is\na proportionality between reputation cost and amount of liquidity resources\nallocated in function of said-reputation\".\n\nLooking forward to pursuing discussions during calls!\n\nBest,\nAntoine\n\nLe lun. 21 nov. 2022 à 13:16, Clara Shikhelman \u003cclara.shikhelman at gmail.com\u003e\na écrit :\n\n\u003e Dear Antoine and list,\n\u003e\n\u003e I think that another call to discuss jamming would be great. I would\n\u003e suggest making it a repeating call every 2 weeks, starting from Monday the\n\u003e 28th at 7 pm UTC.\n\u003e\n\u003e Antoine - Thank you for your work!\n\u003e I have a few questions to better understand the details.\n\u003e\n\u003e 1. Are the tokens transferable between users? For example, if Ned is a\n\u003e routing node, and Alice has some of their tokens, can she give these tokens\n\u003e to Bob?\n\u003e If yes - could this lead to the creation of a secondary market?\n\u003e If no - will that slow down the transaction flow that a new node can send?\n\u003e\n\u003e 2. Do you have a recommended policy for the creation of tokens and their\n\u003e use? Ideally, there will be a policy that would mitigate both slow and\n\u003e quick jamming, without harming usability too much.\n\u003e\n\u003e 3. You write \"the reputation credentials to liquidity units translation\n\u003e can be severed\" - does this mean that the value of the token changes? Is\n\u003e that in the spirit of changing the fees in a channel?\n\u003e If this is the case, can't a routing node \"trick\" a user into buying many\n\u003e tokens and then bring the price up?\n\u003e\n\u003e 4. How would these tokens work with blinded paths and other\n\u003e privacy-preserving suggestions?\n\u003e\n\u003e Thanks again,\n\u003e Clara\n\u003e\n\u003e On Sun, Nov 20, 2022 at 11:01 PM Antoine Riard \u003cantoine.riard at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hi LN Devs,\n\u003e\u003e\n\u003e\u003e tl;dr A formalization of a reputation-based scheme to solve channel\n\u003e\u003e jamming is proposed. The system relies on \"credentials\" issued by routing\n\u003e\u003e hops and requested to be attached to each HTLC forward request. The\n\u003e\u003e \"credentials\" can be used by a reputation algorithm to reward/punish\n\u003e\u003e payment senders and allocate channel liquidity resources efficiently. The\n\u003e\u003e \"credentials\"  initial distribution can be bootstrapped leveraging one-time\n\u003e\u003e upfront fees paid toward the routing hops. Afterwards, the \"credentials\"\n\u003e\u003e subsequent distribution can rely on previous HTLC traffic.\n\u003e\u003e\n\u003e\u003e A protocol description can be found here, with few extensions already to\n\u003e\u003e the BOLTs:\n\u003e\u003e\n\u003e\u003e https://github.com/lightning/bolts/pull/1043\n\u003e\u003e\n\u003e\u003e There is also a work-in-progress proof-of-concept in LDK (on top of our\n\u003e\u003e coming soon^TM  HTLC intercepting API):\n\u003e\u003e\n\u003e\u003e https://github.com/lightningdevkit/rust-lightning/pull/1848\n\u003e\u003e\n\u003e\u003e This work builds on previous reputation-scheme research [0] [1]. It also\n\u003e\u003e integrates the more recent proposals of upfront fees as a straightforward\n\u003e\u003e mechanism to bootstrap the reputation system. Bootstrapping the system with\n\u003e\u003e more economically cost-effective privacy-preserving UTXO ownership proofs\n\u003e\u003e not only add another layer of engineering complexity, there is still a\n\u003e\u003e proof size vs proof generation/validation trade-off to arbiter between ZKP\n\u003e\u003e cryptosystems.\n\u003e\u003e\n\u003e\u003e Rather to seek for a game-theory equilibrium defined as a breakeven point\n\u003e\u003e as in the latest unconditional fee research [2], this proposal aims to use\n\u003e\u003e reputation credentials to allow HTLC traffic-shaping. This not only should\n\u003e\u003e protect against jamming situations (either malicious\n\u003e\u003e or spontaneous) but also allow active HTLC traffic-shaping, where a\n\u003e\u003e routing hop can allow extended channel liquidity lockups based on\n\u003e\u003e accumulated reputation (e.g for hold-invoices). This is also a reduced\n\u003e\u003e overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC\n\u003e\u003e forward behavior can be qualified as \"whitewashing\" from the routing hop\n\u003e\u003e viewpoint.\n\u003e\u003e\n\u003e\u003e It should be noted, this current reputation-credential architectural\n\u003e\u003e framework assumes credentials distribution at the endpoint of the network.\n\u003e\u003e However, the framework should be flexible enough for the credentials to be\n\u003e\u003e harvested by the LSPs, and then distributed in a secondary fashion to their\n\u003e\u003e spokes, when they need it, or even attached transparently thanks to\n\u003e\u003e trampoline. So one design intuition, there is no strong attachment of the\n\u003e\u003e reputation to the endpoint HTLC sender, even if the protocol is described\n\u003e\u003e in a \"flat\" view for now.\n\u003e\u003e\n\u003e\u003e Let's evaluate quickly this mitigation proposal against a few criterias\n\u003e\u003e emerged from recent research.\n\u003e\u003e\n\u003e\u003e The mitigation is effective, in the sense a routing hop can apply a\n\u003e\u003e proportional relationship between the acquisition of the reputation and the\n\u003e\u003e amount of liquidity resources credited in function of said reputation. In a\n\u003e\u003e period of steady state, the reputation acquisition cost can be downgraded\n\u003e\u003e to 0. In periods of channel congestion, the reputation credentials to\n\u003e\u003e liquidity units translation can be severed, in the limit of routing hop\n\u003e\u003e acceptable competitiveness.\n\u003e\u003e\n\u003e\u003e The mitigation is incentive-compatible, if the credentials are not\n\u003e\u003e honored by their issuers, the HTLC senders can evict them from the routing\n\u003e\u003e network view for a while. The successful usage of credentials can lead to\n\u003e\u003e more credentials allocated for longer and more capacity-intensive channel\n\u003e\u003e lockups. In case of HTLC failure, the failure source could be forgiven by\n\u003e\u003e routing hops to maintain the worthiness of the sender credentials.\n\u003e\u003e\n\u003e\u003e The mitigation can be made transparent from the user, as the credentials\n\u003e\u003e harvesting can be done automatically from a pre-allocated budget, similar\n\u003e\u003e to the fee-bumping reserves requirement introduced by anchor output. At the\n\u003e\u003e end of today, if we take modern browsers as an example, the average user\n\u003e\u003e doesn't check manually the TLS certificates (for what they're worth...).\n\u003e\u003e\n\u003e\u003e The mitigation can conserve high-level privacy, as the usage of blinded\n\u003e\u003e signature (or another equivalent cryptosystem breaking signature/message\n\u003e\u003e linking) should allow the credentials issued during a preliminary phase to\n\u003e\u003e be undistinguishable during the redeem/usage phase. New CPU/memory DoS\n\u003e\u003e vectors due to the credentials processing should be watched out.\n\u003e\u003e\n\u003e\u003e About the ease of implementation, there are few protocol messages to\n\u003e\u003e modify, a HTLC intercepting API is assumed as supported by the\n\u003e\u003e implementation, onion messages support is also implied, landing EC blinded\n\u003e\u003e signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms\n\u003e\u003e adaptations might be more serious but still reasonable. The\n\u003e\u003e \"credentials-to-liquidity\" allocation algorithms are likely the new real\n\u003e\u003e beast, though I don't think any reputation scheme can spare them.\n\u003e\u003e\n\u003e\u003e There could be a concern about the centralization inertia introduced by a\n\u003e\u003e reputation system.  Intuitively, the argument can be made that any\n\u003e\u003e historical tracking (such as routing buckets) favor established LN\n\u003e\u003e incumbents at the gain of efficiency. A counter-argument can be made, a new\n\u003e\u003e routing hop can lower the acquisition cost of its issued credentials to\n\u003e\u003e attract more HTLC traffic (accepting higher jamming risk).\n\u003e\u003e\n\u003e\u003e On the ecosystem impacts, it should be studied that this proposal would\n\u003e\u003e impact things like inbound channel routing fees [3], ratecard [4] or\n\u003e\u003e flow-control valve [5] and the whole liquidity toolchain. Hopefully, we\n\u003e\u003e don't significantly restrain the design space for future LN protocol\n\u003e\u003e upgrades.\n\u003e\u003e\n\u003e\u003e On the proposal modularity and flexibility, each routing node has\n\u003e\u003e oversight on its routing policy, acquisition methods, credentials to\n\u003e\u003e liquidity rate. New acquisition methods can be experimented or deployed\n\u003e\u003e when ready, e.g stakes certificates with only e2e upgrade. The credentials\n\u003e\u003e themselves could have \"innate\" expiration time if we use things like\n\u003e\u003e short-lived ZKP [6]. The credentials framework can be extended beyond\n\u003e\u003e solving jamming, as a generalized risk-management framework for Bitcoin\n\u003e\u003e decentralized financial network, e.g transaction signature exchange\n\u003e\u003e ordering in multi-party transactions [7] or finding reliable Coinjoin\n\u003e\u003e counterparties.\n\u003e\u003e\n\u003e\u003e Feedback welcome.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Antoine\n\u003e\u003e\n\u003e\u003e [0]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html\n\u003e\u003e [1]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html\n\u003e\u003e [2]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html\n\u003e\u003e [3]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html\n\u003e\u003e [4]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html\n\u003e\u003e [5]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html\n\u003e\u003e [6] https://eprint.iacr.org/2022/190.pdf\n\u003e\u003e [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221121/d1e83ac2/attachment-0001.html\u003e"}