Add API to change HTLC relay parameters about rust-lightning HOT 7 CLOSED

Confused about how htlc_minimum_msat is described in BOLT but came up with a theory. Could you guys please check on this?

In the Requirement section for channel_update in BOLT7,

- MUST set htlc_minimum_msat to the minimum HTLC value (in millisatoshi) that the final node will accept.

The final seems to be defined as the final recipient of the message. So the above condition sounds strange. Perhaps 'the minimum HTLC value in the peer(the other end of the channel) node'?

In BOLT4,
'amount_below_minimum' onion error is raised when

The HTLC amount was below the htlc_minimum_msat of the channel from the processing node.

and

if the HTLC amount is less than the currently specified minimum amount:
report the amount of the incoming HTLC and the current channel setting for the outgoing channel.

Then the HTLC amount here must mean amt_to_forward in the onion packet(while still reporting the incoming amount).

Since there is no message to notify the changes of their own htlc_mimimum_msat between peers, 'htlc_mimimum_msat' is fixed after the initial announcement in open/accept, so we don't need API to change it. And, so is fixed the htlc_minimum_msat field in channel_update.

from rust-lightning.

Seems to agree with you doesn't make sense as final node isn't known by origin node at channel_update build-time, it's a broadcast all if I get it right.

So htlc_minimum_msat seems currently static in channel_update but in the future maybe nodes'll be able to renegotiate this parameter if they want to respond to a channel capacity increase..

from rust-lightning.

Found #477 in RFC repo addresses my first concern in BOLT #7.

- MUST set htlc_minimum_msat to the minimum HTLC value (in millisatoshi) that the final node will accept.

'the final node' => 'channel peer'

from rust-lightning.

re: htlc_minimum_msat - indeed, the spec is confusing (and wrong).

re: ChannelUpdate firing - indeed, we should have an API to change things such as fee_proportional_millionths which would, by side effect, generate channel_updates. Don't think we really want a channel_update-generation API specifically because those should only be sent when there is an actual update.

from rust-lightning.

Tagging this good-first-issue, at least for the fee-update parts - having an api to change forwarding_fee_proportional_millionths, forwarding_fee_base_msat, and cltv_expiry_delta should be relatively straightforward and also a pretty huge win in terms of missing functionality. We already have all the logic to regenerate channel_updates, so we basically just need to have an api to change these values and then generate an update.

from rust-lightning.

Tagging 0.1 cause apparently we have some users who want this sooner rather than later.

from rust-lightning.

Working on this.

from rust-lightning.