You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We must allow node operators to run plain blip-0004 without our
experimental reputation recorder. It's also a stop-gap in case
there is a bug in it that can be exploited.
We also refactor to introduce more types and documentation, without
changing the reputation algorithm itself.
We also fix a few issues mentioned on the main PR comments.
Copy file name to clipboardExpand all lines: docs/release-notes/eclair-vnext.md
+16-8Lines changed: 16 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -26,20 +26,28 @@ Eclair will not allow remote peers to open new obsolete channels that do not sup
26
26
27
27
### Local reputation and HTLC endorsement
28
28
29
-
To protect against jamming attacks, eclair gives a reputation to its neighbors and uses to decide if a HTLC should be relayed given how congested is the outgoing channel.
30
-
The reputation is basically how much this node paid us in fees divided by how much they should have paid us for the liquidity and slots that they blocked.
29
+
To protect against jamming attacks, eclair gives a reputation to its neighbors and uses it to decide if a HTLC should be relayed given how congested the outgoing channel is.
30
+
The reputation is basically how much this node paid us in fees divided by how much they should have paid us for the liquidity and slots that they blocked.
31
31
The reputation is per incoming node and endorsement level.
32
32
The confidence that the HTLC will be fulfilled is transmitted to the next node using the endorsement TLV of the `update_add_htlc` message.
33
+
Note that HTLCs that are considered dangerous are still relayed: this is the first phase of a network-wide experimentation aimed at collecting data.
33
34
34
35
To configure, edit `eclair.conf`:
36
+
35
37
```eclair.conf
36
-
eclair.local-reputation {
37
-
# Reputation decays with the following half life to emphasize recent behavior.
38
+
// We assign reputations to our peers to prioritize payments during congestion.
39
+
// The reputation is computed as fees paid divided by what should have been paid if all payments were successful.
40
+
eclair.peer-reputation {
41
+
// Set this parameter to false to disable the reputation algorithm and simply relay the incoming endorsement
42
+
// value, as described by https://github.com/lightning/blips/blob/master/blip-0004.md,
43
+
enabled = true
44
+
// Reputation decays with the following half life to emphasize recent behavior.
38
45
half-life = 7 days
39
-
# HTLCs that stay pending for longer than this get penalized
40
-
good-htlc-duration = 12 seconds
41
-
# How much to penalize pending HLTCs. A pending HTLC is considered equivalent to this many fast-failing HTLCs.
42
-
pending-multiplier = 1000
46
+
// Payments that stay pending for longer than this get penalized
47
+
max-relay-duration = 12 seconds
48
+
// Pending payments are counted as failed, and because they could potentially stay pending for a very long time,
49
+
// the following multiplier is applied.
50
+
pending-multiplier = 1000 // A pending payment counts as a thousand failed ones.
Some(system.spawn(Behaviors.supervise(ReputationRecorder(nodeParams.relayParams.peerReputationConfig, Map.empty)).onFailure(typed.SupervisorStrategy.resume), name ="reputation-recorder"))
context.log.debug(s"spawning a new handler with relayId=$relayId to nextNodeId={} with channels={}", nextNodeId_opt.getOrElse(""), nextChannels.keys.mkString(","))
84
-
context.spawn(ChannelRelay.apply(nodeParams, register, reputationRecorder, nextChannels, originNode, relayId, channelRelayPacket), name = relayId.toString)
84
+
context.spawn(ChannelRelay.apply(nodeParams, register, reputationRecorder_opt, nextChannels, originNode, relayId, channelRelayPacket), name = relayId.toString)
0 commit comments