Introduce lightning-htlc-scorer crate as a jamming mitigation strategy

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!

[ariard]

This PR introduces a HTLCScorer, a new module to mitigate against channel jamming attacks and to allow a routing node to control its incoming liquidity flows. The strategy is an experimental implementation of previous channel jamming research ideas ("the Channel Jamming book" and "Unjamming Lightning: A Systematic Approach").

The HTLCScorer consumes the new Event::PaymentIntercept from #1835 (dependent on generic interception followups) and apply additional routing checks defined by a RoutingPolicy. Notably, this routing policy quotes a credential_to_liquidity_unit, i.e the number of credentials we require from a HTLC forward request to grant corresponding outbound channel liquidity. The credentials (SignedCredentials) are attached in the HTLC onion payload (NonFinalNodeAndCredentials) and stored until HTLC settlement (process_htlc_backward()). In function of the HTLC settlement result (either update_add_htlc / update_fail_htlc), we send back new counter-signed credentials.

Credentials redemption should be anonymized to maintain confidentiality of the payer from a routing hop viewpoint. The payer should be able to receive a significant amount of credentials for each challenge they solve without the routing hop being able to link the credential to a persistent identity (in this direction e.g IETF's Privacy Pass).

The original dissemination of the reputation credentials can be based on the payment of unconditional fees/upfront fees to the routing hops during an initial bootstrapping phase.

Working on BOLT extensions to define the credential data format, the routing policy fields, new BOLT error messages and new onion TLV records.

This PR is open as an experiment only, mostly to illustrate how a reputation-based channel jamming would architecturally plug with our current Event interfaces.

[TheBlueMatt]

Thanks for tackling this! Needs rebase now that #1835 has landed. Also, this needs to intercept all HTLCs, right? So we'll need to go ahead and extend #1835 to have a config knob for intercepting all HTLCs.

[ariard]

Addressing review comments received on the mailing list to work out a simplified proposal first. For sure, we'll need to intercept all the HTLCs without user signaling like current intercept scid! As simple as a intercept_all_htlcs knob checked in ChannelManager::forward_htlcs.

[ariard]

I'll pursue the development of this module in its own repository: https://github.com/ariard/lightning-risk-engine

Firstly, while I aim to target in priority compatibility with the Lightning Dev Kit architecture, it should still be a low-engineering bar for the module to be integrated with other Lightning nodes, assuming a bit of standardization of the HTLC intercepting APIs. I still would have to land changes to make HTLCIntercepted more generic and combine a CredentialsScorer with the existent ProbabilisticScorer.

Secondly, I would like to avoid the project slowly arriving to the same monorepo mess than Bitcoin Core where critical components (the p2p stack, the mempool, the validation engine, the script interpreter) are bundled with far far less critical components like the server indexes or the GUI code. Monorepo, once the project is mature with a sound review process, just slows down to death the development pace of complex new subsystems, requesting a bit of "whiteboardy" iterations.

Lastly, even if this jamming mitigation strategy sounds the most economically-efficient have been able to come up with after years of research, I still think there might not be a standard economically optimal jamming strategy, whatever your type of Lightning node or topology. Even if we do a lot of economic simulations (and I look forward to it once the specification is more mature!), from my experience taking part to mempool policy rules design, deploying mainet with real incentives at play can be the only way to corroborate designs with strong economic engineering factors in Bitcoin.

[TheBlueMatt]

That makes sense, looking forward to seeing the PR to add full HTLC interception and further work here!