[Lightning-dev] Lack of capacity field in channel_announcement makes life difficult. Why is it not there?

Christian Decker decker.christian at gmail.com
Sun Jul 29 14:38:30 UTC 2018


They are orthogonal, I agree, but we should judge their merits
independently, and not batch the discussions out of convenience.
In the case of the htlc_maximum_msat I think it will not be
controversial, but it should get its own proposal and discussion.

Cheers,
Christian
On Sun, Jul 29, 2018 at 4:17 PM Robert Olsson <robban at robtex.com> wrote:
>
> Christian,
>
> Ok, it definitely makes sense to include the exact fixed capacity in channel_announcement for the reason you mentioned, and more.
>
> However, can we do both while we are at it? The ideas are not mutually exclusive, and for successful routing, i think the channel_update-approach is much more of a boost.
>
> Regards,
> Robert
>
>
> On Sun, Jul 29, 2018 at 4:59 PM, Christian Decker <decker.christian at gmail.com> wrote:
>>
>> 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
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


More information about the Lightning-dev mailing list