This repository was archived by the owner on Jan 10, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 29
This repository was archived by the owner on Jan 10, 2025. It is now read-only.
[Draft] Reputation spec #12
Copy link
Copy link
Closed
Description
While working on [https://github.com/BitcoinAndLightningLayerSpecs/lsp/blob/main/liquidity-marketplace-spec.md](liquidity marketplace spec) we established the need for node reputation systems and this issue is an initial outline (based on the few discussions we had around this) to start the conversation
Discussions around reputation and solving channel jamming:
https://github.com/microlancer/LNREP
lightning/bolts#1043
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
Node reputation is a metric with which we express various objective and subjective attributes that describe node behavior.
Problems:
- not all data is objective (latency, node management)
- how to establish trust for data, specially one that is self attested and unverifiable
- establishing web of trust by signing the attestations (reputation of reputation provider?)
- how to incentivize good behavior?
- historical data is important and not everyone has it so you'll need to trust someone
- how to express the reputation (one number vs data vs multiple numbers different weighted)
reputation:
- objective attributes
- (historical) channel age
- node age
- number of chans
- chan size distribution
- fees
- historical fee movements
- capacity
- centrality/graph positioning
- relative attributes
- latency
- node management
- (historical) well balanced channels
- (historical) node uptime
- graph positioning
- subjective attributes
- abiding by agreed upon ToS (example channel duration/fee schedule for channel leases)
Metadata
Metadata
Assignees
Labels
No labels