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
