Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-29 📝 Original message: Robert Olsson <robban at ...
📅 Original date posted:2018-07-29
📝 Original message:
Robert Olsson <robban at robtex.com> writes:
> I think however it would be much better and flexible to append a max to
> channel_update. We already have htlc_minimum_msat there and could add
> htlc_maximum_msat to show capacity (minus fees)
> Like this:
>
>
> 1. type: 258 (channel_update)
> 2. data:
> - [64:signature]
> - [32:chain_hash]
> - [8:short_channel_id]
> - [4:timestamp]
> - [2:flags]
> - [2:cltv_expiry_delta]
> - [8:htlc_minimum_msat]
> - [4:fee_base_msat]
> - [4:fee_proportional_millionths]
>
> - [8:htlc_maximum_msat]
This isn't about maximum HTLC value, rather Артём is talking about
adding the total channel capacity to the channel_announcement. That is a
perfectly reasonable idea, as it allows us to safe an on-chain lookup
(incidentally that is the main reason we started tracking an internal
UTXO set so we can stop asking bitcoind for full blocks just to check a
channel's capacity).
The channel's capacity is also fixed for the existence of that channel
(splice-in and splice-out will result in new short channel IDs), so the
announcement is exactly the right place to put this.
Cheers,
Christian
📝 Original message:
Robert Olsson <robban at robtex.com> writes:
> I think however it would be much better and flexible to append a max to
> channel_update. We already have htlc_minimum_msat there and could add
> htlc_maximum_msat to show capacity (minus fees)
> Like this:
>
>
> 1. type: 258 (channel_update)
> 2. data:
> - [64:signature]
> - [32:chain_hash]
> - [8:short_channel_id]
> - [4:timestamp]
> - [2:flags]
> - [2:cltv_expiry_delta]
> - [8:htlc_minimum_msat]
> - [4:fee_base_msat]
> - [4:fee_proportional_millionths]
>
> - [8:htlc_maximum_msat]
This isn't about maximum HTLC value, rather Артём is talking about
adding the total channel capacity to the channel_announcement. That is a
perfectly reasonable idea, as it allows us to safe an on-chain lookup
(incidentally that is the main reason we started tracking an internal
UTXO set so we can stop asking bitcoind for full blocks just to check a
channel's capacity).
The channel's capacity is also fixed for the existence of that channel
(splice-in and splice-out will result in new short channel IDs), so the
announcement is exactly the right place to put this.
Cheers,
Christian