TL;DR
=
* This post presents a channel protocol that's optimized for use within channel
factories.
* The protocol allows HTLCs to be resolved on-chain:
* without making the expiry of the HTLC depend on the time to close the
factory, and
* without closing the factory.
* The key ides is the
A simple but imperfect way to deal with channel jamming and spamming is to
install a lightning firewall such as circuitbreaker [1]. It allows you to
set limits like a maximum number of pending htlcs (fight jamming) and/or a
rate limit (fight spamming). Incoming htlcs that exceed one of the limits
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
Hi Antoine,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
> limits, in opposition to the "static" ones declared to your counterparty
> during channel opening (within the protocol-limit of 483). On top, you can
> rate-limit the HTLCs forwards based on the incoming
Hi Joost,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
limits, in opposition to the "static" ones declared to your counterparty
during channel opening (within the protocol-limit of 483). On top, you can
rate-limit the HTLCs forwards based on the incoming source.
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
