Antoine Riard [ARCHIVE] on Nostr: đź“… Original date posted:2022-11-30 đź“ť Original message: Hi Michael, > I'm not ...
đź“… Original date posted:2022-11-30
đź“ť Original message:
Hi Michael,
> I'm not sure why harming routing nodes is any less of a concern than harming the experience of say edge nodes when introducing game-able systems with uncertainty over the edge cases. Especially when iteration of that system might never lead to a solution we are happy with. A whack-a-mole type thing where plugging one hole creates another hole.
The "staking/reputational" credential system I'm devising allows a
routing hop to adopt a 0-risk HTLC forwarding acceptance policy.
Indeed, one can pick up the credential acquisition cost to be equal to
the routing fees, the routing hop is always paid
in advance for the HTLC forward. Exploitable deviation of this
"0-risk" policy should be considered as implementation bugs.
If you can point me precisely where the current proposal is broken or
if you can raise concrete safety risks, we can correct them. As the
thread name said, the protocol is at the stage of a sketch, and it
doesn't pretend more.
> I was under the impression that routing algorithms weren't part of the Lightning protocol spec (BOLTs)? Each Lightning implementation could ship with totally different default routing algorithms (perhaps a> lready do?) and it wouldn't matter. There is no cross implementation compatibility issue with how each Lightning node selects channel counterparties, how it selects routes for payments and tracks which routes did and didn't work.
This is a correct statement. As you were raising a future concern than
"protocol developers [could be] in the position of deciding who
ultimately receives routing fees", reality today they're already. Of
course, anyone can come up with a new routing
algorithm suiting better their needs, than the default one (at least
for LDK we just have a generic `Score` interface). Doing so, they
would probably have to become themselves "protocol developer" so we
might be back to step one. To qualify more
the root concern, at least one I can understand, I think you're
saying, is that routing algorithms should be far more under scrutiny
of the community, as they do have a major influence on the state of
the LN market/"economy".
> I guess we're back into the world of setting defaults and options here that we've just been through with mempoolfullrbf :) If say a LDK user wants to opt into using this reputation system then that's their> prerogative assuming it is merged into say a LDK release. Personally I would want to opt out of this reputation system and do my own assessments of reputations of Lightning nodes and risks I was taking. A> t least until a point when I was comfortable with it which I may never be.
All I can say LDK is many light-years ahead of Core in term of
flexibility (while acknowledging system philosophy difference between
layers), and I think any jamming mitigation strategy should be its own
independent module (as current PoC is doing, see
LDK #1848), what we can do best to lower opt out cost for the user.
Beyond, if you have further questions on this proposed credentials
system to clarify the proposal and what is confusing you I'm
listening.
> Sure I'll take a look. But recall I am worried about edge cases and ways for an attacker to game a reputation system which requires me to get to your level of understanding of channel jamming attacks (whic> h will take me a while given you've written a book [0] about them with Gleb). And I suspect even you and Gleb wouldn't be confident saying that you understand all the edge cases of jamming attacks let alon> e the edge cases of gaming a reputation layer on top.
And with regards to hypothetical edge cases, best we can do in this
direction is flesh out a protocol sketch, ask for wide community
feedback, try to break it ourselves, integrate the lessons piece by
piece, propose a new iteration, and doing it over
and over until we reach a level of consistency and soundness
convincing as many stakeholders as we can in the community. If you can
think about a better process for Bitcoin protocol development, I'll
let you lead by example.
> As I said in my previous post I think this is an interesting area and I can see why you are exploring reputation. Just very skeptical that this is a thing that is ever part of the protocol, is used by all > of the major Lightning implementations, is on by default in all those Lightning implementations etc. And even if it was I would want to opt out of it.
Worst-case scenario if this proposal is never adopted, I hope we would
have learnt a lot on channel jamming and Lightning liquidity flows as
a community. One is better attached to the process, rather than the
outcome.
Best,
Antoine
Le mar. 29 nov. 2022 Ă 11:25, Michael Folkson <michaelfolkson at protonmail.com>
a Ă©crit :
> > Therefore, in case of loopholes in the system damages are effectively
> borne by the routing hops, without throwing the whole system down.
>
> I'm not sure why harming routing nodes is any less of a concern than
> harming the experience of say edge nodes when introducing game-able systems
> with uncertainty over the edge cases. Especially when iteration of that
> system might never lead to a solution we are happy with. A whack-a-mole
> type thing where plugging one hole creates another hole.
>
> > On the second point, we already have today's reputation systems in
> Lightning, namely the routing algorithms keeping track of the performance
> of the routing hops, and their liquidity.
>
> I was under the impression that routing algorithms weren't part of the
> Lightning protocol spec (BOLTs)? Each Lightning implementation could ship
> with totally different default routing algorithms (perhaps already do?) and
> it wouldn't matter. There is no cross implementation compatibility issue
> with how each Lightning node selects channel counterparties, how it selects
> routes for payments and tracks which routes did and didn't work.
>
> > On the third point, the protocol defer to the node operators all the
> decisions on the credential acquisition costs, expiration height, binding
> with liquidity units, or even allow additional routing policy checks.
>
> I guess we're back into the world of setting defaults and options here
> that we've just been through with mempoolfullrbf :) If say a LDK user wants
> to opt into using this reputation system then that's their prerogative
> assuming it is merged into say a LDK release. Personally I would want to
> opt out of this reputation system and do my own assessments of reputations
> of Lightning nodes and risks I was taking. At least until a point when I
> was comfortable with it which I may never be.
>
> > I hope you'll take time to browse the proposal as detailed more in
> depth here: https://github.com/lightning/bolts/pull/1043
>
> Sure I'll take a look. But recall I am worried about edge cases and ways
> for an attacker to game a reputation system which requires me to get to
> your level of understanding of channel jamming attacks (which will take me
> a while given you've written a book [0] about them with Gleb). And I
> suspect even you and Gleb wouldn't be confident saying that you understand
> all the edge cases of jamming attacks let alone the edge cases of gaming a
> reputation layer on top.
>
> As I said in my previous post I think this is an interesting area and I
> can see why you are exploring reputation. Just very skeptical that this is
> a thing that is ever part of the protocol, is used by all of the major
> Lightning implementations, is on by default in all those Lightning
> implementations etc. And even if it was I would want to opt out of it.
>
> Thanks
> Michael
>
> [0]: https://jamming-dev.github.io/book/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Monday, November 28th, 2022 at 23:34, Antoine Riard <
> antoine.riard at gmail.com> wrote:
>
> Hi Michael,
>
> Thanks for the feedback,
>
> On the first point, I think it should be underscored how much this
> proposed credential system, while labeled a reputational one, belongs more
> to a monetary strategy (after the fact should be called "staking"
> credentials). Indeed, there is a direct link between the credentials and a
> cost expressed in satoshis. Therefore, in case of loopholes in the system
> damages are effectively borne by the routing hops, without throwing the
> whole system down. Note, the default policy should be some 0-risk HTLC
> forward acceptance.
>
> On the second point, we already have today's reputation systems in
> Lightning, namely the routing algorithms keeping track of the performance
> of the routing hops, and their liquidity. That information is used in a
> continuous fashion to improve payment-path building. And while those
> algorithms are doing probabilistic estimation of the balance distribution,
> the proposed credential system is not all relying on past statistics for
> its effectiveness (as long as the node operators are requiring credentials
> of worthiness equivalent to routing fees).
>
> On the third point, the protocol defer to the node operators all the
> decisions on the credential acquisition costs, expiration height, binding
> with liquidity units, or even allow additional routing policy checks.
> Flexibility is offered to the node operators, without the protocol
> developers trying to do any "centralized" decision on the cost of the
> credentials or whatever.
>
> From my understanding, the critics you're raising, while potentially
> correct for the reputation systems links you're including, does not bind to
> any concrete point of my proposal. I hope you'll take time to browse the
> proposal as detailed more in depth here:
> https://github.com/lightning/bolts/pull/1043
>
> Best,
> Antoine
>
> Le sam. 26 nov. 2022 Ă 05:53, Michael Folkson <
> michaelfolkson at protonmail.com> a Ă©crit :
>
>> Hi Antoine
>>
>> I've got a lot to catch up on re channel jamming but just to say I'm
>> deeply skeptical about attempting to embed a reputation layer or reputation
>> credentials into the Lightning protocol. Admittedly I'm somewhat of a
>> curious amateur in the field of reputation systems but a number of people
>> (me included) have had to look into reputation systems in the past for
>> projects/startups they were working on and *centralized​*​ reputation
>> systems are absolute minefields to manage effectively though some
>> corporations do manage it. Decentralized reputation systems baked into a
>> protocol is just a step too far. All you need is one edge case where the
>> attacker can ensure an innocent party is blamed and the reputation system
>> falls apart. The protocol developer is in the position of assessing who is
>> telling the truth out of two opposing viewpoints on Reddit etc.
>>
>> I do think reputation systems will play a key part in a future Lightning
>> Network (to some extent they already are with sites like 1ML and Amboss)
>> but they won't be managed by protocol devs, they will be managed by
>> multiple flavors of companies and projects (hopefully open source but most
>> likely closed source too, for profit, non-profit etc) who are free to use
>> whatever metrics and weigh those metrics however they like. The protocol
>> just can't afford to expand into areas where there is case by case judgment
>> and statistical analysis required. It will become bloated, ineffective and
>> put protocol developers in the position of deciding who ultimately receives
>> routing fees rather than just enabling payments can get from A to B.
>> Identity is easier, you either control a private key or you don't.
>> Reputation is much more difficult, there will be some attacks where a
>> probabilistic assessment will need to be made on who the perpetrator of the
>> attack was. You don't add that to the (already long) list of protocol
>> developers' responsibilities.
>>
>> So feel free to continue to explore reputation and reputation systems but
>> a strong warning that this is likely not solved at the protocol level.
>> Decisions protocol developers make will impact what data can be collected
>> and how easy that data is to collect (there are already some tricky
>> trade-offs with regards to privacy, routing success and transparency for
>> when things go wrong) but beyond that protocol developers should leave it
>> to others. I've included some links to some additional reading on
>> reputation systems in case you are interested.
>>
>> Thanks
>> Michael
>>
>> [0]:
>> https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/
>> [1]:
>> https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175
>> [2]: https://www.bitrated.com/faq
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Monday, November 21st, 2022 at 06:01, 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221129/b2f3c432/attachment-0001.html>;
đź“ť Original message:
Hi Michael,
> I'm not sure why harming routing nodes is any less of a concern than harming the experience of say edge nodes when introducing game-able systems with uncertainty over the edge cases. Especially when iteration of that system might never lead to a solution we are happy with. A whack-a-mole type thing where plugging one hole creates another hole.
The "staking/reputational" credential system I'm devising allows a
routing hop to adopt a 0-risk HTLC forwarding acceptance policy.
Indeed, one can pick up the credential acquisition cost to be equal to
the routing fees, the routing hop is always paid
in advance for the HTLC forward. Exploitable deviation of this
"0-risk" policy should be considered as implementation bugs.
If you can point me precisely where the current proposal is broken or
if you can raise concrete safety risks, we can correct them. As the
thread name said, the protocol is at the stage of a sketch, and it
doesn't pretend more.
> I was under the impression that routing algorithms weren't part of the Lightning protocol spec (BOLTs)? Each Lightning implementation could ship with totally different default routing algorithms (perhaps a> lready do?) and it wouldn't matter. There is no cross implementation compatibility issue with how each Lightning node selects channel counterparties, how it selects routes for payments and tracks which routes did and didn't work.
This is a correct statement. As you were raising a future concern than
"protocol developers [could be] in the position of deciding who
ultimately receives routing fees", reality today they're already. Of
course, anyone can come up with a new routing
algorithm suiting better their needs, than the default one (at least
for LDK we just have a generic `Score` interface). Doing so, they
would probably have to become themselves "protocol developer" so we
might be back to step one. To qualify more
the root concern, at least one I can understand, I think you're
saying, is that routing algorithms should be far more under scrutiny
of the community, as they do have a major influence on the state of
the LN market/"economy".
> I guess we're back into the world of setting defaults and options here that we've just been through with mempoolfullrbf :) If say a LDK user wants to opt into using this reputation system then that's their> prerogative assuming it is merged into say a LDK release. Personally I would want to opt out of this reputation system and do my own assessments of reputations of Lightning nodes and risks I was taking. A> t least until a point when I was comfortable with it which I may never be.
All I can say LDK is many light-years ahead of Core in term of
flexibility (while acknowledging system philosophy difference between
layers), and I think any jamming mitigation strategy should be its own
independent module (as current PoC is doing, see
LDK #1848), what we can do best to lower opt out cost for the user.
Beyond, if you have further questions on this proposed credentials
system to clarify the proposal and what is confusing you I'm
listening.
> Sure I'll take a look. But recall I am worried about edge cases and ways for an attacker to game a reputation system which requires me to get to your level of understanding of channel jamming attacks (whic> h will take me a while given you've written a book [0] about them with Gleb). And I suspect even you and Gleb wouldn't be confident saying that you understand all the edge cases of jamming attacks let alon> e the edge cases of gaming a reputation layer on top.
And with regards to hypothetical edge cases, best we can do in this
direction is flesh out a protocol sketch, ask for wide community
feedback, try to break it ourselves, integrate the lessons piece by
piece, propose a new iteration, and doing it over
and over until we reach a level of consistency and soundness
convincing as many stakeholders as we can in the community. If you can
think about a better process for Bitcoin protocol development, I'll
let you lead by example.
> As I said in my previous post I think this is an interesting area and I can see why you are exploring reputation. Just very skeptical that this is a thing that is ever part of the protocol, is used by all > of the major Lightning implementations, is on by default in all those Lightning implementations etc. And even if it was I would want to opt out of it.
Worst-case scenario if this proposal is never adopted, I hope we would
have learnt a lot on channel jamming and Lightning liquidity flows as
a community. One is better attached to the process, rather than the
outcome.
Best,
Antoine
Le mar. 29 nov. 2022 Ă 11:25, Michael Folkson <michaelfolkson at protonmail.com>
a Ă©crit :
> > Therefore, in case of loopholes in the system damages are effectively
> borne by the routing hops, without throwing the whole system down.
>
> I'm not sure why harming routing nodes is any less of a concern than
> harming the experience of say edge nodes when introducing game-able systems
> with uncertainty over the edge cases. Especially when iteration of that
> system might never lead to a solution we are happy with. A whack-a-mole
> type thing where plugging one hole creates another hole.
>
> > On the second point, we already have today's reputation systems in
> Lightning, namely the routing algorithms keeping track of the performance
> of the routing hops, and their liquidity.
>
> I was under the impression that routing algorithms weren't part of the
> Lightning protocol spec (BOLTs)? Each Lightning implementation could ship
> with totally different default routing algorithms (perhaps already do?) and
> it wouldn't matter. There is no cross implementation compatibility issue
> with how each Lightning node selects channel counterparties, how it selects
> routes for payments and tracks which routes did and didn't work.
>
> > On the third point, the protocol defer to the node operators all the
> decisions on the credential acquisition costs, expiration height, binding
> with liquidity units, or even allow additional routing policy checks.
>
> I guess we're back into the world of setting defaults and options here
> that we've just been through with mempoolfullrbf :) If say a LDK user wants
> to opt into using this reputation system then that's their prerogative
> assuming it is merged into say a LDK release. Personally I would want to
> opt out of this reputation system and do my own assessments of reputations
> of Lightning nodes and risks I was taking. At least until a point when I
> was comfortable with it which I may never be.
>
> > I hope you'll take time to browse the proposal as detailed more in
> depth here: https://github.com/lightning/bolts/pull/1043
>
> Sure I'll take a look. But recall I am worried about edge cases and ways
> for an attacker to game a reputation system which requires me to get to
> your level of understanding of channel jamming attacks (which will take me
> a while given you've written a book [0] about them with Gleb). And I
> suspect even you and Gleb wouldn't be confident saying that you understand
> all the edge cases of jamming attacks let alone the edge cases of gaming a
> reputation layer on top.
>
> As I said in my previous post I think this is an interesting area and I
> can see why you are exploring reputation. Just very skeptical that this is
> a thing that is ever part of the protocol, is used by all of the major
> Lightning implementations, is on by default in all those Lightning
> implementations etc. And even if it was I would want to opt out of it.
>
> Thanks
> Michael
>
> [0]: https://jamming-dev.github.io/book/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Monday, November 28th, 2022 at 23:34, Antoine Riard <
> antoine.riard at gmail.com> wrote:
>
> Hi Michael,
>
> Thanks for the feedback,
>
> On the first point, I think it should be underscored how much this
> proposed credential system, while labeled a reputational one, belongs more
> to a monetary strategy (after the fact should be called "staking"
> credentials). Indeed, there is a direct link between the credentials and a
> cost expressed in satoshis. Therefore, in case of loopholes in the system
> damages are effectively borne by the routing hops, without throwing the
> whole system down. Note, the default policy should be some 0-risk HTLC
> forward acceptance.
>
> On the second point, we already have today's reputation systems in
> Lightning, namely the routing algorithms keeping track of the performance
> of the routing hops, and their liquidity. That information is used in a
> continuous fashion to improve payment-path building. And while those
> algorithms are doing probabilistic estimation of the balance distribution,
> the proposed credential system is not all relying on past statistics for
> its effectiveness (as long as the node operators are requiring credentials
> of worthiness equivalent to routing fees).
>
> On the third point, the protocol defer to the node operators all the
> decisions on the credential acquisition costs, expiration height, binding
> with liquidity units, or even allow additional routing policy checks.
> Flexibility is offered to the node operators, without the protocol
> developers trying to do any "centralized" decision on the cost of the
> credentials or whatever.
>
> From my understanding, the critics you're raising, while potentially
> correct for the reputation systems links you're including, does not bind to
> any concrete point of my proposal. I hope you'll take time to browse the
> proposal as detailed more in depth here:
> https://github.com/lightning/bolts/pull/1043
>
> Best,
> Antoine
>
> Le sam. 26 nov. 2022 Ă 05:53, Michael Folkson <
> michaelfolkson at protonmail.com> a Ă©crit :
>
>> Hi Antoine
>>
>> I've got a lot to catch up on re channel jamming but just to say I'm
>> deeply skeptical about attempting to embed a reputation layer or reputation
>> credentials into the Lightning protocol. Admittedly I'm somewhat of a
>> curious amateur in the field of reputation systems but a number of people
>> (me included) have had to look into reputation systems in the past for
>> projects/startups they were working on and *centralized​*​ reputation
>> systems are absolute minefields to manage effectively though some
>> corporations do manage it. Decentralized reputation systems baked into a
>> protocol is just a step too far. All you need is one edge case where the
>> attacker can ensure an innocent party is blamed and the reputation system
>> falls apart. The protocol developer is in the position of assessing who is
>> telling the truth out of two opposing viewpoints on Reddit etc.
>>
>> I do think reputation systems will play a key part in a future Lightning
>> Network (to some extent they already are with sites like 1ML and Amboss)
>> but they won't be managed by protocol devs, they will be managed by
>> multiple flavors of companies and projects (hopefully open source but most
>> likely closed source too, for profit, non-profit etc) who are free to use
>> whatever metrics and weigh those metrics however they like. The protocol
>> just can't afford to expand into areas where there is case by case judgment
>> and statistical analysis required. It will become bloated, ineffective and
>> put protocol developers in the position of deciding who ultimately receives
>> routing fees rather than just enabling payments can get from A to B.
>> Identity is easier, you either control a private key or you don't.
>> Reputation is much more difficult, there will be some attacks where a
>> probabilistic assessment will need to be made on who the perpetrator of the
>> attack was. You don't add that to the (already long) list of protocol
>> developers' responsibilities.
>>
>> So feel free to continue to explore reputation and reputation systems but
>> a strong warning that this is likely not solved at the protocol level.
>> Decisions protocol developers make will impact what data can be collected
>> and how easy that data is to collect (there are already some tricky
>> trade-offs with regards to privacy, routing success and transparency for
>> when things go wrong) but beyond that protocol developers should leave it
>> to others. I've included some links to some additional reading on
>> reputation systems in case you are interested.
>>
>> Thanks
>> Michael
>>
>> [0]:
>> https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/
>> [1]:
>> https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175
>> [2]: https://www.bitrated.com/faq
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Monday, November 21st, 2022 at 06:01, 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221129/b2f3c432/attachment-0001.html>;