Hi LN devs, Following the November proposal of mitigating channel jamming with Reputation Credentials, started to document the protocol architecture. After feedback on the naming protocol itself, I switched to Staking Credentials. In fact the proposed architecture enables mitigations deployment both within a reputation strategy or a monetary strategy in function of the base collateral considered (proof-of-utxo ownership or on-chain/off-chain payments).
The main advance is the clear separation of the credentials issuance phase from the redemption phase. Participants in the architecture have been abstracted to answer multiple types of Lightning deployment: credentials issuance and redemption fully-sourced on the client-side, issuance delegation where the credentials mining is delegated to a LSP, redemption delegation where the credentials are attached on the fly to a HTLC by a hop supporting trampoline. Abstraction has been done also on the routing-hop side, where the credentials issuer can be dissociated from the routing hop against which it can be redeemed (to allow "phantom node" style of deployment [0]). The credentials redemption mechanism itself has been abstracted to cover diverse Lightning channel counterparty risks, with a primary focus on HTLC jamming. Beyond, the redemption flow could be easily deployed to solve the risk asymmetries brought by the signature release flow in the context of dual-funding/splicing. Architecture document is available here: https://github.com/ariard/lightning-rfc/blob/2022-11-reputation-credentials/60-staking-credentials-archi.md Credential issuance phase, redemption phase, onion communication channels as credential transport protocol, credentials data format, cryptographic primitives used for unlinking and recommendations for risk-management strategy (among others) should land in their own documents with time. Next focus on advancing the work-in-progress implementation: https://github.com/ariard/lightning-risk-engine Module is designed to be uncoupled from LDK architecture specifics and generic to minimize interdependencies with independent advances in channel types/transaction-relay policy. Cheers, Antoine [0] https://lightningdevkit.org/blog/introducing-phantom-node-payments/
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
