Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-21 📝 Original message: Hi LN Devs, tl;dr A ...
📅 Original date posted:2022-11-21
📝 Original message:
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/20221120/2a736ba2/attachment.html>;
📝 Original message:
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/20221120/2a736ba2/attachment.html>;