Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2022-12-02T01:07:09+00:00


Summary:

Antoine Riard proposes a reputation-based scheme for solving channel jamming in the Lightning Network. The scheme involves using credentials issued by routing hops to allocate channel liquidity efficiently and reward/punish payment senders. Critics raise concerns about the management of decentralized reputation systems and the potential for innocent parties to be blamed in attacks. Antoine suggests fleshing out the proposal, seeking community feedback, and iterating until consensus is reached.The proposed reputation system uses credentials attached to each HTLC forward request to protect against channel jamming. These credentials can be acquired through upfront fees or based on previous HTLC traffic. Node operators have flexibility in determining acquisition costs, expiration height, and binding with liquidity units. The system is effective if node operators require credentials of worthiness equivalent to routing fees.There are concerns about attackers gaming the reputation system and introducing centralization inertia. However, new routing hops can lower acquisition costs to attract more traffic. The proposal should be studied for its impact on inbound channel routing fees and the overall liquidity toolchain.The reputation-based scheme can be implemented with few modifications to the protocol. It requires support for HTLC intercepting API, onion messages, and EC blinded signature. The proposed framework can also serve as a generalized risk-management framework for Bitcoin decentralized financial networks.Feedback on the proposal is welcomed, and the proposed protocol and work-in-progress proof-of-concept can be found on GitHub. Further research and community feedback are necessary to refine and validate the proposal.In a conversation between Antoine Riard and David A. Harding, there is an issue with credential tampering by intermediary nodes in a classic payment path. This scenario allows malicious nodes to waste the sender's credentials allocated on downstream hops. Blinded paths are suggested as an alternative solution, using per-hop shared secrets or blinded onion routes for fresh credentials refill. Privacy concerns arise due to the quantity of credentials being a potential privacy leak.The potential for denial-of-service (DoS) attacks on the Lightning Network is discussed in a mailing list discussion. Malicious nodes could harvest tokens from other Lightning Service Providers (LSPs) and use them to launch wide attacks, reducing the reputation of competitor LSPs. However, credential tokens are blinded, making it impossible for forwarding nodes to determine the origin of payments and blame another node.Antoine Riard suggests using onion messages and blinded paths for token dissemination and renewal rounds in Lightning Network transactions. The current design assumes tokens are attached to the HTLC during forwarding, but an alternative design could detach them, with the HTLC onion only containing a reference to the tokens.Michael Folkson expresses skepticism about embedding a reputation layer or credentials into the Lightning protocol, believing that decentralized reputation systems are too risky to be managed by protocol developers. Antoine Riard discusses the economic aspects of new tokens and their secondary markets, suggesting that routing hops would increase the liquidity value of their credentials until the failure rate affects their routing income.The current reputation-credential framework assumes distribution at the endpoint of the network, but it should be flexible enough for credentials to be harvested by LSPs and distributed in a secondary fashion. There are concerns about competitor LSPs applying to be a spoke on their rival's network and jamming up payments, reducing their competitor's reputation.In an email conversation, Antoine Riard proposes a "staking"/reputational credentials policy to save on unconditional fees in the Lightning Network. The policy suggests strict binding between acquisition cost and channel liquidity routed, with higher returns achieved through an adjusted ratio of credentials to liquidity. A "pure reputation" system could be layered on top, allocating more liquidity based on identity quality. Proving UTXO ownership without revealing additional information is a challenge in this system.Clara Shikhelman questions the benefits of using tokens compared to unconditional fees and requests a recommended policy for token quantity, rate issuance, token acquisition cost, and adaptations to channel congestion. Antoine agrees that a recommended policy is needed and proposes refining the credentials architectural framework.Antoine's proposed solution involves a "staking"/reputational credentials system that allows past HTLC routing success to be converted into more allocated credentials. This system maintains a 0-risk HTLC forwarding acceptance by tying credentials acquisition cost to channel liquidity routed. A "pure reputation" layer can be added, allocating more liquidity based on identity quality. The challenge lies in proving UTXO ownership without revealing additional information. Clara raises concerns about the lack of a recommended policy and requests a timeline for presenting one. Antoine focuses on refining the credentials architectural framework and considers dynamic routing policy and active risk-management as more advanced questions.Clara proposes a call to discuss a recommended policy for the Lightning Network. Antoine responds with a detailed explanation of his proposal, including using credentials issued by routing hops and adjusting them based on local channel congestion or network data. He mentions the possibility of a reputation layer and addresses Clara's questions about token transferability, recommended policies, secondary markets, and privacy concerns.


Updated on: 2023-08-01T00:51:27.716675+00:00