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 <rob...@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.christ...@gmail.com> wrote: >> >> Robert Olsson <rob...@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@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