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

[Christian Decker]

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  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 
>  wrote:
>>
>> Robert Olsson  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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Артём Литвинович]

Greetings.

What was the rationale for not including channel capacity into the
channel_announcement message?

As things stand now, the only way to determine it is to check the
blockchain, which is hard for mobile and/or light wallets.
Even worse, the data is only there in the form of short_channel_id, which
is incompatible with most block explorer APIs.

In other words, having to have access to the blockchain turns a
route-finding tool from a simple program into a thing laden with many
dependencies in order to fetch and parse the transactions.
Not knowing the capacity of the channels drops routing success rates
dramatically, especially for larger payments.

Is there a good reason to force us to do so that i'm missing?


-Artem
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev