Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-21 📝 Original message: Dear Antoine and list, I ...
📅 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>;
📝 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>;