Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-12 🗒️ Summary of this message: Lightning ...
📅 Original date posted:2023-01-12
🗒️ Summary of this message: Lightning Network developers are documenting a protocol architecture for mitigating channel jamming with Staking Credentials, enabling deployment within a reputation or monetary strategy. The architecture separates the credentials issuance phase from the redemption phase and abstracts participants to answer multiple types of Lightning deployment. The credentials redemption mechanism covers diverse Lightning channel counterparty risks, with a primary focus on HTLC jamming. The module is designed to be uncoupled from LDK architecture specifics and generic to minimize interdependencies with independent advances in channel types/transaction-relay policy.
📝 Original message:
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230112/7ab3d050/attachment.html>;
🗒️ Summary of this message: Lightning Network developers are documenting a protocol architecture for mitigating channel jamming with Staking Credentials, enabling deployment within a reputation or monetary strategy. The architecture separates the credentials issuance phase from the redemption phase and abstracts participants to answer multiple types of Lightning deployment. The credentials redemption mechanism covers diverse Lightning channel counterparty risks, with a primary focus on HTLC jamming. The module is designed to be uncoupled from LDK architecture specifics and generic to minimize interdependencies with independent advances in channel types/transaction-relay policy.
📝 Original message:
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230112/7ab3d050/attachment.html>;