rich1.0npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddhttps://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddnjumphttps://nostr.ae📅 Original date posted:2022-11-21 📝 Original message: Hi Clara, Thanks for reading! > I think that another call to discuss jamming would be great. I would > suggest making it a repeating call every 2 weeks, starting from Monday the > 28th at 7 pm UTC. Cool to take the initiative, the schedule works for me, however this slot might conflict with the Core Lightning engineering call ? I remember we moved the LDK meeting time from 7pm to 5pm, as we had folks willing to attend both. > 1. Are the tokens transferable between users? For example, if Ned is a > routing node, and Alice has some of their tokens, can she give these tokens > to Bob? > If yes - could this lead to the creation of a secondary market? > If no - will that slow down the transaction flow that a new node can send? Current version of the proposal, there is nothing preventing the tokens to be transferred between the users, Alice can give these tokens to Bob. We could make them binding to the prover, by requesting a new round where Alice registers a pubkey towards Ned, and all tokens should be counter-authenticated by Ned at forward. Ned would flag out the double-usage of tokens, ideally in a ZKP-way. Still I think this would never prevent Alice from sharing her key material with Bob. So I'm not sure we can prevent a secondary-market, and it might be even more valuable if we would like LSPs to collect tokens for their spokes nodes to simplify UX. That said, beyond unlinkability between the blinded message and the cleartext tokens/signatures, I think all the properties should be open to more research. > 2. Do you have a recommended policy for the creation of tokens and their > use? Ideally, there will be a policy that would mitigate both slow and > quick jamming, without harming usability too much. If by recommend policy, you mean the set of algorithms that should guide the token quantity, rate issuance, token acquisition cost, and the adaptations in function of the local channel congestion, or even the gossips of the other routing nodes, not at all. Just intuition, I think a simple model should start from enforcing a proportionality between token acquisition costs and the available channels liquidity, then you can add more factors in function of your risk model. About the slow/quick jamming distinction, I still believe a good anti-jamming solution should aim to solve things in a continuous fashion, rather than a discrete one. That way binds better to the reality of differing hold time Lightning HTLC: simple payment, offline receive, hold-invoice, swaps, etc... > 3. You write "the reputation credentials to liquidity units translation can > be severed" - does this mean that the value of the token changes? Is that > in the spirit of changing the fees in a channel? > If this is the case, can't a routing node "trick" a user into buying many > tokens and then bring the price up? Yes, the "liquidity value" of the tokens is currently left as a floating parameter. This is a good question if it should be fixed and only the routing fees should fluctuate in function of channel congestion, or floating e.g when the global quantity of tokens are required to re-dilute their current values to maintain some proportion between acquisition cost and available liquidity. For sure, a routing node could "trick" a user into buying many tokens and then break the promise of not only bringing the price up but also plainly reject HTLC forward requests satisfying the announced routing policy. Though note the user's routing algorithms could penalize in retorsion the node, if the routing policy gossiped isn't respected. > 4. How would these tokens work with blinded paths and other > privacy-preserving suggestions? Primarily, the tokens could use the new onion messages and blinded paths for the dissemination and renewal rounds. Current design assumes they're attached to the HTLC during forward along the payment path, though I think one design alternative could be completely detached, and the HTLC onion just contains a ref to the tokens. Zooming out, after submitting this proposal to the mailing list yesterday, I thought how much a token/credentials system bootstrapped on pre-paid fees should be classified into monetary strategy or a reputation-based strategy, and it turns out as there is an acquisition cost associated to the tokens, in fact it might belong more to the monetary strategy classification. So I wonder now if the usage of the reputation in the proposal title isn't misleading and if a "breakeven point" isn't still implied ("the proportionality" seeked). From a history of ideas standpoint, a reputation-based strategy was more the Stakes Certificate solution originally proposed in 2020. Though this proposal reuses the liquidity units/credit score introduced there. I think more and more we should have a "two-tier" mitigation strategy, where the base tier is strictly defined in "pure fees" terms, and then layered on top of a reputation system. A routing node could deviate from the zero risk "pure fees" ones to increase its routing fees returns, by relying more on assumptions like "Past HTLC senders behave well if there is a proportionality between reputation cost and amount of liquidity resources allocated in function of said-reputation". Looking forward to pursuing discussions during calls! Best, Antoine Le lun. 21 nov. 2022 à 13:16, Clara Shikhelman <clara.shikhelman at gmail.com> a écrit : > Dear Antoine and list, > > I think that another call to discuss jamming would be great. I would > suggest making it a repeating call every 2 weeks, starting from Monday the > 28th at 7 pm UTC. > > Antoine - Thank you for your work! > I have a few questions to better understand the details. > > 1. Are the tokens transferable between users? For example, if Ned is a > routing node, and Alice has some of their tokens, can she give these tokens > to Bob? > If yes - could this lead to the creation of a secondary market? > If no - will that slow down the transaction flow that a new node can send? > > 2. Do you have a recommended policy for the creation of tokens and their > use? Ideally, there will be a policy that would mitigate both slow and > quick jamming, without harming usability too much. > > 3. You write "the reputation credentials to liquidity units translation > can be severed" - does this mean that the value of the token changes? Is > that in the spirit of changing the fees in a channel? > If this is the case, can't a routing node "trick" a user into buying many > tokens and then bring the price up? > > 4. How would these tokens work with blinded paths and other > privacy-preserving suggestions? > > Thanks again, > Clara > > On Sun, Nov 20, 2022 at 11:01 PM Antoine Riard <antoine.riard at gmail.com> > 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 qualified as "whitewashing" from the routing hop >> viewpoint. >> >> It should be noted, this current reputation-credential architectural >> framework assumes credentials distribution at the endpoint of the network. >> However, the framework should be flexible enough for the credentials to be >> harvested by the LSPs, and then distributed in a secondary fashion to their >> spokes, when they need it, or even attached transparently thanks to >> trampoline. So one design intuition, there is no strong attachment of the >> reputation to the endpoint HTLC sender, even if the protocol is described >> in a "flat" view for now. >> >> Let's evaluate quickly this mitigation proposal against a few criterias >> emerged from recent research. >> >> The mitigation is effective, in the sense a routing hop can apply a >> proportional relationship between the acquisition of the reputation and the >> amount of liquidity resources credited in function of said reputation. In a >> period of steady state, the reputation acquisition cost can be downgraded >> to 0. In periods of channel congestion, the reputation credentials to >> liquidity units translation can be severed, in the limit of routing hop >> acceptable competitiveness. >> >> The mitigation is incentive-compatible, if the credentials are not >> honored by their issuers, the HTLC senders can evict them from the routing >> network view for a while. The successful usage of credentials can lead to >> more credentials allocated for longer and more capacity-intensive channel >> lockups. In case of HTLC failure, the failure source could be forgiven by >> routing hops to maintain the worthiness of the sender credentials. >> >> The mitigation can be made transparent from the user, as the credentials >> harvesting can be done automatically from a pre-allocated budget, similar >> to the fee-bumping reserves requirement introduced by anchor output. At the >> end of today, if we take modern browsers as an example, the average user >> doesn't check manually the TLS certificates (for what they're worth...). >> >> The mitigation can conserve high-level privacy, as the usage of blinded >> signature (or another equivalent cryptosystem breaking signature/message >> linking) should allow the credentials issued during a preliminary phase to >> be undistinguishable during the redeem/usage phase. New CPU/memory DoS >> vectors due to the credentials processing should be watched out. >> >> About the ease of implementation, there are few protocol messages to >> modify, a HTLC intercepting API is assumed as supported by the >> implementation, onion messages support is also implied, landing EC blinded >> signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms >> adaptations might be more serious but still reasonable. The >> "credentials-to-liquidity" allocation algorithms are likely the new real >> beast, though I don't think any reputation scheme can spare them. >> >> There could be a concern about the centralization inertia introduced by a >> reputation system. Intuitively, the argument can be made that any >> historical tracking (such as routing buckets) favor established LN >> incumbents at the gain of efficiency. A counter-argument can be made, a new >> routing hop can lower the acquisition cost of its issued credentials to >> attract more HTLC traffic (accepting higher jamming risk). >> >> On the ecosystem impacts, it should be studied that this proposal would >> impact things like inbound channel routing fees [3], ratecard [4] or >> flow-control valve [5] and the whole liquidity toolchain. Hopefully, we >> don't significantly restrain the design space for future LN protocol >> upgrades. >> >> On the proposal modularity and flexibility, each routing node has >> oversight on its routing policy, acquisition methods, credentials to >> liquidity rate. New acquisition methods can be experimented or deployed >> when ready, e.g stakes certificates with only e2e upgrade. The credentials >> themselves could have "innate" expiration time if we use things like >> short-lived ZKP [6]. The credentials framework can be extended beyond >> solving jamming, as a generalized risk-management framework for Bitcoin >> decentralized financial network, e.g transaction signature exchange >> ordering in multi-party transactions [7] or finding reliable Coinjoin >> counterparties. >> >> Feedback welcome. >> >> Cheers, >> Antoine >> >> [0] >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html >> [1] >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html >> [2] >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html >> [3] >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html >> [4] >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html >> [5] >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html >> [6] https://eprint.iacr.org/2022/190.pdf >> [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242 >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221121/d1e83ac2/attachment-0001.html>