Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch (Antoine Riard)

[Antoine Riard]

Hi Loki,

Thanks for raising awareness on this project.

I share the sentiment on the gradual generalization of Lightning onion
messaging as a transport network on its own for Bitcoin-specific traffic
such as offers, offline receive control flow or credentials tokens or even
in the future DLC offers. I don't know about the extension as a
fully-fledged anonymity network such as Tor or I2P, we'll have issues with
DoS too there [0] [1].

On a mechanism to improve the reliability of path-finding, have a look at
the recent fat errors proposal [1] (probably a needed piece for
reputational credentials too).

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003623.html
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003660.html
[2] https://github.com/lightning/bolts/pull/1044

Le ven. 2 déc. 2022 à 07:33, Loki Verloren via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> a écrit :

> This subject makes a strong argument, along with the onion routed
> messaging part of Bolt 12 for an independent, Lightning funded onion
> routing relay network, over which all such kinds of traffic and security
> can be provided.
>
> I'm working on such a project, which will be initially built to support
> LND/BTCD/Neutrino: https://github.com/Indra-Labs/indra One of its key
> innovations is a mechanism for path tracing, which enables the deduction of
> likely nodes that are currently not functioning correctly or malicious or
> offline or congested, via a process of deduction, while keeping the client
> originating traffic hidden from nodes in the path.
>
> Channels running across this overlay network would not be possible to jam
> and with many nodes a lot of traffic would pass through opaque tunnels,
> which would make jamming harder. The payment scheme in it also might work
> as a full solution to the adding of a cost against attempts to jam
> channels. My current idea for reputation is just a simple measure of client
> success ranking nodes by how recent and reliable they are, creating a loose
> consensus on the network of which nodes are better connected and
> dependable. Because it will use a median/zip merging process for evaluating
> the nodes it is hard for an adversary to damage the reputation of good
> nodes without also having to run a lot of nodes and for those nodes to also
> develop a good reputation.
>
> Anyway, just some thoughts on the subject, not sure how useful or correct
> they are at this point.
>
>
> Sent with Proton Mail  secure email.
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch (Antoine Riard)

[Loki Verloren via Lightning-dev]

This subject makes a strong argument, along with the onion routed messaging 
part of Bolt 12 for an independent, Lightning funded onion routing relay 
network, over which all such kinds of traffic and security can be provided.

I'm working on such a project, which will be initially built to support 
LND/BTCD/Neutrino: https://github.com/Indra-Labs/indra One of its key 
innovations is a mechanism for path tracing, which enables the deduction of 
likely nodes that are currently not functioning correctly or malicious or 
offline or congested, via a process of deduction, while keeping the client 
originating traffic hidden from nodes in the path.

Channels running across this overlay network would not be possible to jam and 
with many nodes a lot of traffic would pass through opaque tunnels, which would 
make jamming harder. The payment scheme in it also might work as a full 
solution to the adding of a cost against attempts to jam channels. My current 
idea for reputation is just a simple measure of client success ranking nodes by 
how recent and reliable they are, creating a loose consensus on the network of 
which nodes are better connected and dependable. Because it will use a 
median/zip merging process for evaluating the nodes it is hard for an adversary 
to damage the reputation of good nodes without also having to run a lot of 
nodes and for those nodes to also develop a good reputation. 

Anyway, just some thoughts on the subject, not sure how useful or correct they 
are at this point.



Sent with Proton Mail secure email.

publickey - stalker.loki@protonmail.ch - 0x96FE6FEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

Hi Zeeman,

I think it is correct to say that if any mechanism to protect against
channel jamming succeeds, the remaining instance of apparent channel
jamming might be accidental. This rate of accident might be still high due
to spontaneous congestion (i.e more HTLC senders than slots/liquidity
available for the core links of the network). With the present credential
tokens scheme the rate of spontaneous failure should still have to be
encumbered by some entity. By default it would be the HTLC sender, as is
the one attaching the tokens, and this sounds to be aligned with incentive
as is the one building a payment path of _reliable_ routing hop.

On the second issue, namely a node B who is a competitor of node A and
accepting node A credentials to provoke a jamming attack against A, I don't
think this is plausible. As long as node A is requesting its _own_ tokens
to accept HTLC forward, there is a compensation for the risk. The behavior
of node B accepting node A to drain traffic through node A, in an attempt
to jam it, would in the present situation benefit node A due to the
credentials acquisition cost.

There is a different idea, I think you're describing, the trust-minimized
exchange of credentials tokens between receivers. Effectively here we can
imagine a Chaumian bank-style construction where the tokens are transferred
in a privacy-fashion, and double-spend flagged out by the bank. However,
this wouldn't prevent a token double-spend against another bank. So it
sounds to me you need some kind of underlying reputation or enforcement
mechanism to make the economics of the bank work ? I.e the bank being a LSP
and force-closing channels in case of double-spend.

It should be noted, even if we assume federation of Chaumian banks leading
to a global secondary market for token transfers, the routing hops should
be still economically safe against jamming attacks, as long as the token
acquisition cost is paid at issuance.

Best,
Antoine

Le jeu. 1 déc. 2022 à 07:28, ZmnSCPxj  a écrit :

>
> Good morning Antoine,
>
> > About secondary-markets, the credentials themselves are subject to the
> classic double-spend problem. E.g, Alice can transfer her "Ned" credentials
> both to Bob and Caroll, without any of them getting knowledge of the
> duplication. So it could be expected secondary markets to only happen
> between LSP and their spokes (where "trust" relationships already exist),
> as such harder to formalize.
>
> If this is a problem, would the use of the WabiSabi technique help?
> If my understanding was correct, the WabiSabi paper described a Chaumian
> bank that issues coins of variable amount, with clients able to merge and
> split coins without revealing the amount to the bank/issuer, while allowing
> for non-double-spendable transfer of coins by having the bank sign off on
> all transfers between clients (without the bank becoming aware of the value
> being transferred or the pseudonyms of either client).
>
>
> If transfer of tokens can be made non-double-spendable, then it may be
> feasible for a forwarding node to accept tokens issued by a different
> forwarding node, if the sender also transfers control of those tokens to
> the forwarding node.
> i.e. if a sender has credentials for node A but needs to forward via node
> B, then node B may be willing to accept credentials issued by node A.
> This is similar to the situation where "free banks", in the absence of a
> central bank, are willing to accept paper bearer bonds issued by another
> bank, as this lets them attack the other bank by withdrawing the value
> backing the bond and attempt to trigger a bank run on that other bank (and
> thus remove them from competition).
> Similarly, node B who is a competitor of node A may be willing to accept
> credentials issued by node A, in a forward that goes through node B, as the
> transferred credentials would allow node B to perform a jamming attack on
> node A (and thus remove them from competition).
> Both node A and B can then peacefully resolve the difference without
> attacking via a "clearing house" where they reveal how much of the
> credential issued by the other they have, in much the same way as free
> banks would resolve paper bearer bonds.
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

Hi Dave & Zeeman,

As the credentials tokens should be blinded during countersigning and then
wrapped inside HTLC onions, the routing hops cannot use them to assign
blame. Instead the jamming attack prevention efficiency relies on
misbehaving senders exhausting their supply of scarce and costly tokens. A
naive blinding should still enable delegation -- Bob can share his Ned's
tokens with Mallory, and she could consume them to waste Ned routing
liquidity. However Bob should have borne the acquisition cost.

This delegation could happen in a trampoline flow, where Bob attaches
on-the-flight his Ned tokens to Alice's HTLC. This naive attachment
shouldn't leak the delegation fact itself to the routing hops.

About the economic relationships between LSPs and their clients, it sounds
effectively possible the token harvesting to be done at the LSP-level,
where over-supply of tokens are resold to the LSP in exchange of other
advantages (e.g discount on JIT channels). This over-supply can be assigned
to newer clients, devoid of credentials token, at condition there is still
a costly bound enforced by the LSP, to avoid a jamming adversary exploiting
the cost asymmetry (e.g presence of channels). This asymmetry exploitation
would be detrimental to the _LSP zone_, not the tokens issuer routing hop,
as the original compensation must have been paid by the LSP.

It should be noted, a reasonable routing policy might be to additionally
reward HTLC on "favorable" incoming links, as a means to incentive the
maintenance of the open link. However this creates asymmetry if the
incoming link operator allows free credential tokens earned by its clients.

On the jamming vectors opened by an adversary having collected a large
stock of tokens, the routing hops should be still economically "safe", as
long as there is a strict equality between the credentials acquisition cost
and the routing fees. E.g wasting liquidity worth 1000 sats of routing fees
should have been compensated by credentials worth 1000 sats, therefore the
routing hops still earn an income. Note, one of the insights of
"staking/reputational" credentials is to pour the original HTLC forwarding
risk on the sender, while making this risk "fine-grained" and "flexible" in
its allocation.

While the routing fees would vary in function of multiple factors (e.g
network-wide channels congestion) the credentials token acquisition cost
should stay identical, otherwise you're offering exploitable asymmetries to
an attacker.

On the argument that jamming would be solved as the attacker has to
sacrifice opportunity costs of its own liquidity, I think such a position
forgets few elements. Such as the fact one channel can tied up liquidity
for many links, jammed channel might have higher return rate than attacker
liquidity due to routing algorithms historical data, the damage inflicted
might be merchant goods themselves far beyond the attacker opportunity
costs, the opportunity cost between attacker and victims might not be
symmetric because the attacker have large liquidity reserves (e.g an
attacker blocking new incumbents).

Best,
Antoine

Le lun. 28 nov. 2022 à 06:50, ZmnSCPxj  a écrit :

> Good morning David,
>
> > On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:
> >
> > > If I am an LSP, and I know my competitor LSP distributes their
> > > credentials, then I can simply apply to be a spoke on my competitor
> > > and then make several payments to my node, which I then jam up.
> > > This reduces the reputation of my competitor LSP.
> >
> >
> > I don't think this how Riard's credentials work. The credential tokens
> > are blinded, so forwarding nodes can't use them to determine the origin
> > of the payment---thus they can't assign blame.
> >
> > As I understand them, credential tokens prevent DoS by each token only
> > allowing the one-time creation of a single HTLC, so any failed payment
> > reduces the sender's supply of tokens. That means, if Mallory becomes a
> > client of Bob's and Bob lets Mallory use some of his tokens, Mallory can
> > destroy those tokens. Although that's bad for Bob, he can easily limit
> > the damage by not giving Mallory more tokens after too many failures.
> > If Bob obtained his tokens at a low cost (e.g. by sending many payments
> > that were successful and receiving back >100% of the tokens he used to
> >
> > make those payments) and if Alice has to pay a similar or greater cost
> > to become a client of Bob's (e.g. onchain channel open costs), then the
> > attack should not be economically rational.
>
> The usual response is to subsequently attack the mitigation, this is a
> general technique that works on pretty much anything.
>
> Mallory can run multiple nodes.
> Mallory can then initially buy a small number of tokens.
> Then Mallory sends payments back and forth ensuring success, receiving
> back >100% tokens used.
> This gives Mallory a large number of tokens.
>
> Finally, Mallory launches a wide attack on the network by using its
> 

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[ZmnSCPxj via Lightning-dev]

Good morning Antoine,

> About secondary-markets, the credentials themselves are subject to the 
> classic double-spend problem. E.g, Alice can transfer her "Ned" credentials 
> both to Bob and Caroll, without any of them getting knowledge of the 
> duplication. So it could be expected secondary markets to only happen between 
> LSP and their spokes (where "trust" relationships already exist), as such 
> harder to formalize.

If this is a problem, would the use of the WabiSabi technique help?
If my understanding was correct, the WabiSabi paper described a Chaumian bank 
that issues coins of variable amount, with clients able to merge and split 
coins without revealing the amount to the bank/issuer, while allowing for 
non-double-spendable transfer of coins by having the bank sign off on all 
transfers between clients (without the bank becoming aware of the value being 
transferred or the pseudonyms of either client).


If transfer of tokens can be made non-double-spendable, then it may be feasible 
for a forwarding node to accept tokens issued by a different forwarding node, 
if the sender also transfers control of those tokens to the forwarding node.
i.e. if a sender has credentials for node A but needs to forward via node B, 
then node B may be willing to accept credentials issued by node A.
This is similar to the situation where "free banks", in the absence of a 
central bank, are willing to accept paper bearer bonds issued by another bank, 
as this lets them attack the other bank by withdrawing the value backing the 
bond and attempt to trigger a bank run on that other bank (and thus remove them 
from competition).
Similarly, node B who is a competitor of node A may be willing to accept 
credentials issued by node A, in a forward that goes through node B, as the 
transferred credentials would allow node B to perform a jamming attack on node 
A (and thus remove them from competition).
Both node A and B can then peacefully resolve the difference without attacking 
via a "clearing house" where they reveal how much of the credential issued by 
the other they have, in much the same way as free banks would resolve paper 
bearer bonds.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[ZmnSCPxj via Lightning-dev]

Good morning Antoin, Dave, et al.,


> Hi Dave,
> 
> I think the issue you're describing about credential tampering by 
> intermediary nodes is correct. If Alice controls Y along the path 
> W->X->Y->Zed, she can waste the credentials value provided. Indeed, this 
> issue generalizes for any classic payment path, where a routing node can 
> waste the senders credentials allocated on the downstream hops.

Of note is that jamming attacks are mounted by routing nodes against other 
routing nodes, and a routing node will not *deliberately* attack a payment that 
goes through them --- doing so sacrifices the potential for fees.
It still remains the case that accidents can happen, and Y could fail 
completely by accident and cause accidental failure.
Indeed, if any mechanism to protect against channel jamming succeeds, then the 
remaining instances of apparent channel jamming will be accidental.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

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 
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 

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Michael Folkson via Lightning-dev]

> 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](http://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 
 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
>
> 

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

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 
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.ri...@gmail.com> wrote:
>
> Hi LN Devs,
>
> tl;dr A formalization of a reputation-based scheme to 

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

Hi Dave,

I think the issue you're describing about credential tampering by
intermediary nodes is correct. If Alice controls Y along the path
W->X->Y->Zed, she can waste the credentials value provided. Indeed, this
issue generalizes for any classic payment path, where a routing node can
waste the senders  credentials allocated on the downstream hops.

As discussed on the corresponding BOLT proposal, "staking/reputational"
credentials are probably be dependent on fat errors to assign payment path
failure correctly:
https://github.com/lightning/bolts/pull/1043#discussion_r1029938977
(even further in the case of blinded path, the senders might need another
round with the recipient to share a subset of the fat error).

Note the usage of blinded path in the aforementioned comment is about
sending back fresh credentials if the HTLC succeeds. One alternative is to
use the per-hop shared secret and wrap them in the return HTLC onion.
Another alternative, a blinded onion route could be registered at HTLC
forward phase, and this blinded path is leveraged for the fresh credentials
refill (I think the quantity of credentials could be a privacy-leak itself,
that you would like to mask).

Best,
Antoine

Le sam. 26 nov. 2022 à 15:48, David A. Harding  a écrit :

> On 2022-11-21 14:26, Antoine Riard wrote:
> >> Clara Shikhelman wrote:
> >> 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.
>
> I'm not sure I understand this answer, so I'll explain in my own words
> and kindly ask that you tell me if I'm wrong or missing something
> important.
>
> If Alice wants to pay Zed using a blinded path where Zed chooses
> terminal channels W->X->Y->Zed, then Zed will need to provide to Alice
> the encrypted credential tokens for X, and Y.  In theory, if Alice
> controls node Y, she can prevent the HTLC from settling and so waste the
> value of Zed's provided tokens for node X.  However, Alice shouldn't
> know where Zed's node is in the LN topography and can't be assured that
> he'll forward through her secondary node, so the attack is uncertain to
> work.  The attack may also have a cost---Alice may need to buy
> credential tokens for node W and the hops leading to it from her primary
> node---with that cost mitigating the chance of the attack and the
> likelihood that it would be profitable.
>
> Thank you both for the interesting proposal and the insightful
> questions!,
>
> -Dave
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[ZmnSCPxj via Lightning-dev]

Good morning David,

> On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:
> 
> > If I am an LSP, and I know my competitor LSP distributes their
> > credentials, then I can simply apply to be a spoke on my competitor
> > and then make several payments to my node, which I then jam up.
> > This reduces the reputation of my competitor LSP.
> 
> 
> I don't think this how Riard's credentials work. The credential tokens
> are blinded, so forwarding nodes can't use them to determine the origin
> of the payment---thus they can't assign blame.
> 
> As I understand them, credential tokens prevent DoS by each token only
> allowing the one-time creation of a single HTLC, so any failed payment
> reduces the sender's supply of tokens. That means, if Mallory becomes a
> client of Bob's and Bob lets Mallory use some of his tokens, Mallory can
> destroy those tokens. Although that's bad for Bob, he can easily limit
> the damage by not giving Mallory more tokens after too many failures.
> If Bob obtained his tokens at a low cost (e.g. by sending many payments
> that were successful and receiving back >100% of the tokens he used to
> 
> make those payments) and if Alice has to pay a similar or greater cost
> to become a client of Bob's (e.g. onchain channel open costs), then the
> attack should not be economically rational.

The usual response is to subsequently attack the mitigation, this is a general 
technique that works on pretty much anything.

Mallory can run multiple nodes.
Mallory can then initially buy a small number of tokens.
Then Mallory sends payments back and forth ensuring success, receiving back 
>100% tokens used.
This gives Mallory a large number of tokens.

Finally, Mallory launches a wide attack on the network by using its harvested 
tokens (from the >100% token return from successful payment resolution), 
trading off reputation for whatever they might gain by attacking the LN.

Unless forwarding nodes charge a large fee on successful resolution of 
payments, such that the >100% return on tokens is equal to the cost of buying 
the extra tokens "fresh", then this makes launching the attack cheaper.


> > Thus all reputation still rests with ultimate senders, who have to
> > convince LSPs to sell their reputation to them, because they might
> > secretly be competitor LSPs who have incentive to drain their
> > reputation.
> > 
> > If the price of sold reputation is too high, then it is no different
> > from upfront fees.
> > 
> > If the price of sold reputation is too low, then I can drain the
> > reputation of competitor LSPs.
> 
> 
> I think the statement at the top about reputation resting with ultimate
> senders is true but two conditionals below it are not quite right. If
> an LSP helps many clients make successful payments, those clients may
> (at no additional cost to them beyond the forwarding fees they already
> paid) receive more credential tokens than they'll ever need. By
> allowing the LSP to instead use those tokens for other clients
> ("harvesting" them), it's possible for those later clients to avoid
> paying for credential tokens---this is equivalent to free upfront fees.
> As long as the LSP can prevent a client from using too many tokens, and
> requires the client pay other inescapable costs, then it shouldn't be
> possible for a competitor to substantially drain the token capital of a
> LSP without losing a substantial amount of its own money.

It is helpful to consider that jamming attacks require that jamming attackers 
tie up their funds on Lightning too.
So while a jamming attacker can impose opportunity costs on the rest of the 
network, it also sacrifices opportunity to instead use the same funds in 
forwarding.
Thus a jamming attacker can impose costs on others by also losing a substantial 
amount (in terms of lost opportunity to instead use the same locked funds to 
earn forwarding fees), meaning that if you are going to make that argument, 
then the original problem was already solved by its own structure.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[David A. Harding]

On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:

If I am an LSP, and I know my competitor LSP distributes their
credentials, then I can simply apply to be a spoke on my competitor
and then make several payments to my node, which I then jam up.
This reduces the reputation of my competitor LSP.


I don't think this how Riard's credentials work.  The credential tokens 
are blinded, so forwarding nodes can't use them to determine the origin 
of the payment---thus they can't assign blame.


As I understand them, credential tokens prevent DoS by each token only 
allowing the one-time creation of a single HTLC, so any failed payment 
reduces the sender's supply of tokens.  That means, if Mallory becomes a 
client of Bob's and Bob lets Mallory use some of his tokens, Mallory can 
destroy those tokens.  Although that's bad for Bob, he can easily limit 
the damage by not giving Mallory more tokens after too many failures.  
If Bob obtained his tokens at a low cost (e.g. by sending many payments 
that were successful and receiving back >100% of the tokens he used to 
make those payments) and if Alice has to pay a similar or greater cost 
to become a client of Bob's (e.g. onchain channel open costs), then the 
attack should not be economically rational.



This is even worse if my competitor LSP attaches their credentials on
trampolines, I do not even need to apply to be a spoke on my
competitor that way.


I think the analysis for trampolines is the same: as long as Bob only 
attaches credential tokens to trampoline payments where he knows the 
origin has paid a cost (or will need to pay a cost) to abuse his 
service, he can prevent any attack from becoming economically rational.



Thus all reputation still rests with ultimate senders, who have to
convince LSPs to sell their reputation to them, because they might
secretly be competitor LSPs who have incentive to drain their
reputation.

If the price of sold reputation is too high, then it is no different
from upfront fees.

If the price of sold reputation is too low, then I can drain the
reputation of competitor LSPs.


I think the statement at the top about reputation resting with ultimate 
senders is true but two conditionals below it are not quite right.  If 
an LSP helps many clients make successful payments, those clients may 
(at no additional cost to them beyond the forwarding fees they already 
paid) receive more credential tokens than they'll ever need.  By 
allowing the LSP to instead use those tokens for other clients 
("harvesting" them), it's possible for those later clients to avoid 
paying for credential tokens---this is equivalent to free upfront fees.  
As long as the LSP can prevent a client from using too many tokens, and 
requires the client pay other inescapable costs, then it shouldn't be 
possible for a competitor to substantially drain the token capital of a 
LSP without losing a substantial amount of its own money.


-Dave
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[David A. Harding]

On 2022-11-21 14:26, Antoine Riard wrote:

Clara Shikhelman wrote:
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.


I'm not sure I understand this answer, so I'll explain in my own words 
and kindly ask that you tell me if I'm wrong or missing something 
important.


If Alice wants to pay Zed using a blinded path where Zed chooses 
terminal channels W->X->Y->Zed, then Zed will need to provide to Alice 
the encrypted credential tokens for X, and Y.  In theory, if Alice 
controls node Y, she can prevent the HTLC from settling and so waste the 
value of Zed's provided tokens for node X.  However, Alice shouldn't 
know where Zed's node is in the LN topography and can't be assured that 
he'll forward through her secondary node, so the attack is uncertain to 
work.  The attack may also have a cost---Alice may need to buy 
credential tokens for node W and the hops leading to it from her primary 
node---with that cost mitigating the chance of the attack and the 
likelihood that it would be profitable.


Thank you both for the interesting proposal and the insightful 
questions!,


-Dave
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Michael Folkson via Lightning-dev]

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](http://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 
 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 

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

Hi Clara,

> Have you done any work on the economic aspects of the new tokens and their
> secondary markets?

About the economic aspects, while I think 0-risk HTLC forwarding acceptance
would require credentials cost to perfectly bind to the routing fees, in an
open market like the LN routing one it is expected routing hops to bump the
liquidity value of their credentials. As such increase their forwarded HTLC
traffic volume, until the failure rate downgrades their routing income
beyond their opportunity costs. How the market of HTLC senders would react
to the liquidity value bump of their credentials, and how a routing node
should pick up this bump to reach their income target is a good research
question, I think.

About secondary-markets, the credentials themselves are subject to the
classic double-spend problem. E.g, Alice can transfer her "Ned" credentials
both to Bob and Caroll, without any of them getting knowledge of the
duplication. So it could be expected secondary markets to only happen
between LSP and their spokes (where "trust" relationships already exist),
as such harder to formalize.

Best,
Antoine

Le ven. 25 nov. 2022 à 10:40, Clara Shikhelman 
a écrit :

> Cool, thanks for that.
>
> Have you done any work on the economic aspects of the new tokens and their
> secondary markets?
>
> On Thu, Nov 24, 2022, 21:22 Antoine Riard  wrote:
>
>> Hi Clara,
>>
>> The main benefit of this "staking"/reputational credentials is to save on
>> unconditional fees paid by HTLC senders. They benefit from their past HTLC
>> routing success in terms of more credentials allocated to them, and as such
>> minimize the overhead cost of their future HTLC sends, or allow them to
>> lock liquidity for longer periods. From a routing node viewpoint, a 0-risk
>> HTLC forwarding acceptance can be maintained by requesting strict binding
>> between credentials acquisition cost and channel liquidity routed. If
>> higher returns are seeked, the ratio credentials to liquidity can be
>> adjusted, of course coming with higher risks, and I think this is where the
>> model built for the current unconditional fees proposal could be useful (if
>> we integrate the channel congestion rate factor, I believe).
>>
>> On top of this monetary paradigm, we can layer a "pure reputation"
>> system, where in function of the quality of the identities (e.g
>> proof-of-utxo-ownership), HTLC senders are allocated more significant
>> liquidity slots. Here, the real bottleneck is the cryptosystem, i.e proving
>> a UTXO ownership without revealing any other information. The rationale of
>> this "pure reputation" system, we could even save more in
>> upfront/unconditional fees in the steady state of the network (however such
>> a probabilistic model breaks hard in presence of attackers).
>>
>> Best,
>> Antoine
>>
>> Le jeu. 24 nov. 2022 à 09:45, Clara Shikhelman <
>> clara.shikhel...@gmail.com> a écrit :
>>
>>> Hi Antoine,
>>>
>>> It sounds like unconditional fees cover most of what this policy does,
>>> without the extra risks that come from creating a new token. Is there a
>>> clear benefit to using a token compared to unconditional fees and
>>> local reputation?
>>>
>>> Best,
>>> Clara
>>>
>>> On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard 
>>> wrote:
>>>
 Hi Clara,

 I think the simplest recommended policy you can devise is credential
 shown to the routing hop should cover for full routing fees, therefore the
 routing hop benefits from a zero-jamming risk situation. Then you can
 appreciate the "liquidity value" credentials requested in function of your
 local channel congestion rate, or even network data. Increasing your
 returns in exchange of higher risk exposure. And even more, you can lay on
 top a reputation layer, where the reputation scores are fully fungible
 against monetary credentials, in the acceptance of a HTLC forward request.

 So I think I agree with you a recommended policy is needed, let's just
 start with a simple one! And refine it with time once we sense we have
 solid foundations.

 Best,
 Antoine


 Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman <
 clara.shikhel...@gmail.com> a écrit :

> Hi Antoine,
>
> To discuss your proposed solution in detail, I think that some kind of
> recommended policy is needed. If presenting one is a low priority, and
> waiting for other things, my main concern is that it will just never 
> happen
> ("any decade now" kind of situation).
>
> Best,
> Clara
>
> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard 
> wrote:
>
>> Hi Clara,
>>
>> Shared the mail on #lightning-dev Libera chat to get more feedback on
>> schedule.
>>
>> > Do you have a timeline in mind for presenting such a policy?
>>
>> See the comments on the BOLT #1043  PR, for now I'm thinking more to
>> refine the proposed credentials architectural framework.

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[ZmnSCPxj via Lightning-dev]

Good morning Antoine,

> 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.

This seems incorrect.

If I am an LSP, and I know my competitor LSP distributes their credentials, 
then I can simply apply to be a spoke on my competitor and then make several 
payments to my node, which I then jam up.
This reduces the reputation of my competitor LSP.

This is even worse if my competitor LSP attaches their credentials on 
trampolines, I do not even need to apply to be a spoke on my competitor that 
way.

Thus in both cases the competitor LSP needs to have a similar way of ensuring 
that their spokes / trampoline requesters are not also trying to jam *them* in 
order to drain their reputation.
Thus all reputation still rests with ultimate senders, who have to convince 
LSPs to sell their reputation to them, because they might secretly be 
competitor LSPs who have incentive to drain their reputation.

If the price of sold reputation is too high, then it is no different from 
upfront fees.

If the price of sold reputation is too low, then I can drain the reputation of 
competitor LSPs.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

Cool, thanks for that.

Have you done any work on the economic aspects of the new tokens and their
secondary markets?

On Thu, Nov 24, 2022, 21:22 Antoine Riard  wrote:

> Hi Clara,
>
> The main benefit of this "staking"/reputational credentials is to save on
> unconditional fees paid by HTLC senders. They benefit from their past HTLC
> routing success in terms of more credentials allocated to them, and as such
> minimize the overhead cost of their future HTLC sends, or allow them to
> lock liquidity for longer periods. From a routing node viewpoint, a 0-risk
> HTLC forwarding acceptance can be maintained by requesting strict binding
> between credentials acquisition cost and channel liquidity routed. If
> higher returns are seeked, the ratio credentials to liquidity can be
> adjusted, of course coming with higher risks, and I think this is where the
> model built for the current unconditional fees proposal could be useful (if
> we integrate the channel congestion rate factor, I believe).
>
> On top of this monetary paradigm, we can layer a "pure reputation" system,
> where in function of the quality of the identities (e.g
> proof-of-utxo-ownership), HTLC senders are allocated more significant
> liquidity slots. Here, the real bottleneck is the cryptosystem, i.e proving
> a UTXO ownership without revealing any other information. The rationale of
> this "pure reputation" system, we could even save more in
> upfront/unconditional fees in the steady state of the network (however such
> a probabilistic model breaks hard in presence of attackers).
>
> Best,
> Antoine
>
> Le jeu. 24 nov. 2022 à 09:45, Clara Shikhelman 
> a écrit :
>
>> Hi Antoine,
>>
>> It sounds like unconditional fees cover most of what this policy does,
>> without the extra risks that come from creating a new token. Is there a
>> clear benefit to using a token compared to unconditional fees and
>> local reputation?
>>
>> Best,
>> Clara
>>
>> On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard 
>> wrote:
>>
>>> Hi Clara,
>>>
>>> I think the simplest recommended policy you can devise is credential
>>> shown to the routing hop should cover for full routing fees, therefore the
>>> routing hop benefits from a zero-jamming risk situation. Then you can
>>> appreciate the "liquidity value" credentials requested in function of your
>>> local channel congestion rate, or even network data. Increasing your
>>> returns in exchange of higher risk exposure. And even more, you can lay on
>>> top a reputation layer, where the reputation scores are fully fungible
>>> against monetary credentials, in the acceptance of a HTLC forward request.
>>>
>>> So I think I agree with you a recommended policy is needed, let's just
>>> start with a simple one! And refine it with time once we sense we have
>>> solid foundations.
>>>
>>> Best,
>>> Antoine
>>>
>>>
>>> Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman <
>>> clara.shikhel...@gmail.com> a écrit :
>>>
 Hi Antoine,

 To discuss your proposed solution in detail, I think that some kind of
 recommended policy is needed. If presenting one is a low priority, and
 waiting for other things, my main concern is that it will just never happen
 ("any decade now" kind of situation).

 Best,
 Clara

 On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard 
 wrote:

> Hi Clara,
>
> Shared the mail on #lightning-dev Libera chat to get more feedback on
> schedule.
>
> > Do you have a timeline in mind for presenting such a policy?
>
> See the comments on the BOLT #1043  PR, for now I'm thinking more to
> refine the proposed credentials architectural framework.
> I think dynamic routing policy in function of channel congestion rate,
> and you combine that with reputation to do active risk-management are far
> more advanced questions.
>
> Best,
> Antoine
>
> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
> clara.shikhel...@gmail.com> a écrit :
>
>> Dear All,
>>
>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for
>> you, please reach out!
>>
>> Thanks for your quick and detailed response, Antoine.
>>
>> 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.
>>>
>>
>> Do you have a timeline in mind for presenting such a policy?
>>
>> Looking forward to discussing this further over the phone call, will
>> make some inquiries to make sure the time works for most people.
>>
>> Best,
>> Clara
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

Hi Clara,

The main benefit of this "staking"/reputational credentials is to save on
unconditional fees paid by HTLC senders. They benefit from their past HTLC
routing success in terms of more credentials allocated to them, and as such
minimize the overhead cost of their future HTLC sends, or allow them to
lock liquidity for longer periods. From a routing node viewpoint, a 0-risk
HTLC forwarding acceptance can be maintained by requesting strict binding
between credentials acquisition cost and channel liquidity routed. If
higher returns are seeked, the ratio credentials to liquidity can be
adjusted, of course coming with higher risks, and I think this is where the
model built for the current unconditional fees proposal could be useful (if
we integrate the channel congestion rate factor, I believe).

On top of this monetary paradigm, we can layer a "pure reputation" system,
where in function of the quality of the identities (e.g
proof-of-utxo-ownership), HTLC senders are allocated more significant
liquidity slots. Here, the real bottleneck is the cryptosystem, i.e proving
a UTXO ownership without revealing any other information. The rationale of
this "pure reputation" system, we could even save more in
upfront/unconditional fees in the steady state of the network (however such
a probabilistic model breaks hard in presence of attackers).

Best,
Antoine

Le jeu. 24 nov. 2022 à 09:45, Clara Shikhelman 
a écrit :

> Hi Antoine,
>
> It sounds like unconditional fees cover most of what this policy does,
> without the extra risks that come from creating a new token. Is there a
> clear benefit to using a token compared to unconditional fees and
> local reputation?
>
> Best,
> Clara
>
> On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard 
> wrote:
>
>> Hi Clara,
>>
>> I think the simplest recommended policy you can devise is credential
>> shown to the routing hop should cover for full routing fees, therefore the
>> routing hop benefits from a zero-jamming risk situation. Then you can
>> appreciate the "liquidity value" credentials requested in function of your
>> local channel congestion rate, or even network data. Increasing your
>> returns in exchange of higher risk exposure. And even more, you can lay on
>> top a reputation layer, where the reputation scores are fully fungible
>> against monetary credentials, in the acceptance of a HTLC forward request.
>>
>> So I think I agree with you a recommended policy is needed, let's just
>> start with a simple one! And refine it with time once we sense we have
>> solid foundations.
>>
>> Best,
>> Antoine
>>
>>
>> Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman <
>> clara.shikhel...@gmail.com> a écrit :
>>
>>> Hi Antoine,
>>>
>>> To discuss your proposed solution in detail, I think that some kind of
>>> recommended policy is needed. If presenting one is a low priority, and
>>> waiting for other things, my main concern is that it will just never happen
>>> ("any decade now" kind of situation).
>>>
>>> Best,
>>> Clara
>>>
>>> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard 
>>> wrote:
>>>
 Hi Clara,

 Shared the mail on #lightning-dev Libera chat to get more feedback on
 schedule.

 > Do you have a timeline in mind for presenting such a policy?

 See the comments on the BOLT #1043  PR, for now I'm thinking more to
 refine the proposed credentials architectural framework.
 I think dynamic routing policy in function of channel congestion rate,
 and you combine that with reputation to do active risk-management are far
 more advanced questions.

 Best,
 Antoine

 Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
 clara.shikhel...@gmail.com> a écrit :

> Dear All,
>
> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for
> you, please reach out!
>
> Thanks for your quick and detailed response, Antoine.
>
> 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.
>>
>
> Do you have a timeline in mind for presenting such a policy?
>
> Looking forward to discussing this further over the phone call, will
> make some inquiries to make sure the time works for most people.
>
> Best,
> Clara
>

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

Hi Antoine,

It sounds like unconditional fees cover most of what this policy does,
without the extra risks that come from creating a new token. Is there a
clear benefit to using a token compared to unconditional fees and
local reputation?

Best,
Clara

On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard 
wrote:

> Hi Clara,
>
> I think the simplest recommended policy you can devise is credential shown
> to the routing hop should cover for full routing fees, therefore the
> routing hop benefits from a zero-jamming risk situation. Then you can
> appreciate the "liquidity value" credentials requested in function of your
> local channel congestion rate, or even network data. Increasing your
> returns in exchange of higher risk exposure. And even more, you can lay on
> top a reputation layer, where the reputation scores are fully fungible
> against monetary credentials, in the acceptance of a HTLC forward request.
>
> So I think I agree with you a recommended policy is needed, let's just
> start with a simple one! And refine it with time once we sense we have
> solid foundations.
>
> Best,
> Antoine
>
>
> Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman 
> a écrit :
>
>> Hi Antoine,
>>
>> To discuss your proposed solution in detail, I think that some kind of
>> recommended policy is needed. If presenting one is a low priority, and
>> waiting for other things, my main concern is that it will just never happen
>> ("any decade now" kind of situation).
>>
>> Best,
>> Clara
>>
>> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard 
>> wrote:
>>
>>> Hi Clara,
>>>
>>> Shared the mail on #lightning-dev Libera chat to get more feedback on
>>> schedule.
>>>
>>> > Do you have a timeline in mind for presenting such a policy?
>>>
>>> See the comments on the BOLT #1043  PR, for now I'm thinking more to
>>> refine the proposed credentials architectural framework.
>>> I think dynamic routing policy in function of channel congestion rate,
>>> and you combine that with reputation to do active risk-management are far
>>> more advanced questions.
>>>
>>> Best,
>>> Antoine
>>>
>>> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
>>> clara.shikhel...@gmail.com> a écrit :
>>>
 Dear All,

 If the call time (Monday the 28th at 7 pm UTC) doesn't work out for
 you, please reach out!

 Thanks for your quick and detailed response, Antoine.

 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.
>

 Do you have a timeline in mind for presenting such a policy?

 Looking forward to discussing this further over the phone call, will
 make some inquiries to make sure the time works for most people.

 Best,
 Clara

>>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

Hi Clara,

I think the simplest recommended policy you can devise is credential shown
to the routing hop should cover for full routing fees, therefore the
routing hop benefits from a zero-jamming risk situation. Then you can
appreciate the "liquidity value" credentials requested in function of your
local channel congestion rate, or even network data. Increasing your
returns in exchange of higher risk exposure. And even more, you can lay on
top a reputation layer, where the reputation scores are fully fungible
against monetary credentials, in the acceptance of a HTLC forward request.

So I think I agree with you a recommended policy is needed, let's just
start with a simple one! And refine it with time once we sense we have
solid foundations.

Best,
Antoine


Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman 
a écrit :

> Hi Antoine,
>
> To discuss your proposed solution in detail, I think that some kind of
> recommended policy is needed. If presenting one is a low priority, and
> waiting for other things, my main concern is that it will just never happen
> ("any decade now" kind of situation).
>
> Best,
> Clara
>
> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard 
> wrote:
>
>> Hi Clara,
>>
>> Shared the mail on #lightning-dev Libera chat to get more feedback on
>> schedule.
>>
>> > Do you have a timeline in mind for presenting such a policy?
>>
>> See the comments on the BOLT #1043  PR, for now I'm thinking more to
>> refine the proposed credentials architectural framework.
>> I think dynamic routing policy in function of channel congestion rate,
>> and you combine that with reputation to do active risk-management are far
>> more advanced questions.
>>
>> Best,
>> Antoine
>>
>> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
>> clara.shikhel...@gmail.com> a écrit :
>>
>>> Dear All,
>>>
>>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
>>> please reach out!
>>>
>>> Thanks for your quick and detailed response, Antoine.
>>>
>>> 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.

>>>
>>> Do you have a timeline in mind for presenting such a policy?
>>>
>>> Looking forward to discussing this further over the phone call, will
>>> make some inquiries to make sure the time works for most people.
>>>
>>> Best,
>>> Clara
>>>
>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

Hi Antoine,

To discuss your proposed solution in detail, I think that some kind of
recommended policy is needed. If presenting one is a low priority, and
waiting for other things, my main concern is that it will just never happen
("any decade now" kind of situation).

Best,
Clara

On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard 
wrote:

> Hi Clara,
>
> Shared the mail on #lightning-dev Libera chat to get more feedback on
> schedule.
>
> > Do you have a timeline in mind for presenting such a policy?
>
> See the comments on the BOLT #1043  PR, for now I'm thinking more to
> refine the proposed credentials architectural framework.
> I think dynamic routing policy in function of channel congestion rate, and
> you combine that with reputation to do active risk-management are far more
> advanced questions.
>
> Best,
> Antoine
>
> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman 
> a écrit :
>
>> Dear All,
>>
>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
>> please reach out!
>>
>> Thanks for your quick and detailed response, Antoine.
>>
>> 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.
>>>
>>
>> Do you have a timeline in mind for presenting such a policy?
>>
>> Looking forward to discussing this further over the phone call, will make
>> some inquiries to make sure the time works for most people.
>>
>> Best,
>> Clara
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

Hi Clara,

Shared the mail on #lightning-dev Libera chat to get more feedback on
schedule.

> Do you have a timeline in mind for presenting such a policy?

See the comments on the BOLT #1043  PR, for now I'm thinking more to refine
the proposed credentials architectural framework.
I think dynamic routing policy in function of channel congestion rate, and
you combine that with reputation to do active risk-management are far more
advanced questions.

Best,
Antoine

Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman 
a écrit :

> Dear All,
>
> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
> please reach out!
>
> Thanks for your quick and detailed response, Antoine.
>
> 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.
>>
>
> Do you have a timeline in mind for presenting such a policy?
>
> Looking forward to discussing this further over the phone call, will make
> some inquiries to make sure the time works for most people.
>
> Best,
> Clara
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

Dear All,

If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
please reach out!

Thanks for your quick and detailed response, Antoine.

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.
>

Do you have a timeline in mind for presenting such a policy?

Looking forward to discussing this further over the phone call, will make
some inquiries to make sure the time works for most people.

Best,
Clara
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Antoine Riard]

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 

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

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 
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