Hold fees #843
Hold fees #843
Conversation
joostjager
force-pushed
the
hold-fees
branch
from
7596b3d
to
de6c917
Compare
There was a problem hiding this comment.
Overall I am uncertain about the proposal itself and whether this is effective in mitigating the issue of spam (most arguments have been brought up in the replies on the mailing list)
Under the assumption we wish to move forward with this proposal or in this direction I think we should at least express the hold_duration and hold_fees in blocks instead of days
| @@ -805,6 +813,8 @@ is destined, is described in [BOLT #4](04-onion-routing.md). | |||
| * [`sha256`:`payment_hash`] | |||
| * [`u32`:`cltv_expiry`] | |||
| * [`1366*byte`:`onion_routing_packet`] | |||
| * [`u64`:`hold_fee_rate_day`] | |||
There was a problem hiding this comment.
why not per block?
There was a problem hiding this comment.
I've chosen time because it matches the actual cost of locked funds closely. Blocks probably works just as well though.
| @@ -829,6 +839,8 @@ A sending node: | |||
| its commitment transaction, it cannot pay the fee for the updated local or | |||
| remote transaction at the current `feerate_per_kw` while maintaining its | |||
| channel reserve. | |||
| - SHOULD NOT offer a combination of `amount_msat`, `cltv_expiry`, `hold_fee_rate_day` and `hold_fee_discount` such that the remote node cannot pay the hold fee for the longest possible hold duration. The longest possible hold duration is the `cltv_expiry` delta in blocks multiplied by ten minutes. This must also take into account all currently outstanding htlcs. | |||
There was a problem hiding this comment.
See the above comment. It seems strange to do this artificial conversion between wall clock time and block time when we already have cltv_expiry as the upper hold duration and a perfect time stamping server on the base layer.
There was a problem hiding this comment.
Yes, agreed that this causes friction for the calculation of the max hold fee.
| @@ -950,6 +965,7 @@ A node: | |||
| commitment transactions: | |||
| - MUST NOT send an `update_fulfill_htlc`, `update_fail_htlc`, or | |||
| `update_fail_malformed_htlc`. | |||
| - MUST set `hold_fee` to the hold fees that it owes the sending node. Let `hold_duration_days` be the actual time that the htlc was held, expressed in days. This value is calculated as `hold_fee_rate_day` (from `update_add_htlc`) * `hold_duration_days` - `hold_fee_discount` (also from `update_add_htlc`). Example: `hold_fee_rate_day`=200, `hold_fee_discount`=3, `hold_duration_days`=0.02 (30 minutes). Then `hold_fee` is 200 * 0.02 - 3 = 1 sat. `hold_fee` can be negative in which case the sending node owes the receiving node. | |||
There was a problem hiding this comment.
in the case of minutes it is easy to compute the hold_duration_days but in reality there will be seconds and even milliseconds involved thus my repeated suggestion to stick with a hold_duration_blocks as the number of blocks since the htlc was offered and the current hight. It might still be tricky to negotiate the hold_duration_blocks if a new block is just being propagated. Nodes might either allow a grace period of a couple seconds or we need some mechanism to renegotiate this value.
There was a problem hiding this comment.
Indeed, either way there must be a grace period. For regular lightning payments, there is a similar grace delta added by the sender to accommodate for blocks that are produced while the payment is in flight.
A per-block rate doesn't have the granularity of a per-time rate, but perhaps that isn't a problem. To combat spam, the minimum hold fee that the sender needs to pay to each node must be sufficiently high. Charging for a second of hold time is probably not enough, if it is even possible to express in msat.
| @@ -263,6 +263,10 @@ It is formatted according to the Type-Length-Value format defined in [BOLT #1](0 | |||
| 2. data: | |||
| * [`32*byte`:`payment_secret`] | |||
| * [`tu64`:`total_msat`] | |||
| 1. type: 10 (`hold_fee`) | |||
There was a problem hiding this comment.
Doesn't that conflict with onion messages in #759
There was a problem hiding this comment.
This PR is only conceptual at this stage.
| - For every non-final node: | ||
| - MUST include `short_channel_id` | ||
| - MUST NOT include `payment_data` | ||
| - MUST set `hold_fee_rate_day` so that difference between incoming and outgoing `hold_fee_rate_day` for the receiving node is at least the expected value based on the receiving node's channel policy. |
There was a problem hiding this comment.
I do not understand this sentence and thus not the requirement. Is that related to hold_fee_rate_ppm_day from BOLT 7 if so why not including hold_fee_rate_base_day? (while I probably just missed some point here I of course iterate that I would set those rates in blocks instead of days)
There was a problem hiding this comment.
A node is paying a hold fee to the next node and receiving a hold fee from its predecessor. The idea of this sentence is to point out that a node must make sure that the difference between fees paid and fees received covers the hold fee that they require for themselves.
Similar to forwarding a lightning payment where nodes must make sure that the difference between incoming and outgoing amount is at least their desired routing fee.
|
Superseded by #1071? |
This is a rough initial set of changes that outlines the idea put forward in the mailing list post Hold fee rates as DoS protection (channel spamming and jamming).