rich1.0npub1uyhgpz5nsfnvdlcqm3erjsdjasd9pdeaejeetwtkvumm6mp3ujlqxt9vwkhttps://nostr.ae/npub1uyhgpz5nsfnvdlcqm3erjsdjasd9pdeaejeetwtkvumm6mp3ujlqxt9vwknjumphttps://nostr.ae📅 Original date posted:2022-11-21 📝 Original message: 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/ae6ba7de/attachment.html>