Robert Olsson [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-29 📝 Original message: Christian, Ok, it ...
📅 Original date posted:2018-07-29
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180729/6612244b/attachment.html>;
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180729/6612244b/attachment.html>;