I agree that having to look in the blockchain should not be a requirement
for light wallets.
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]
It shouldn't be an issue for older implementations to handle an added 8
bytes, they simply won't read the last 8 bytes.
New implementations can easily read old ones, and setting
htlc_maxmimum_msat internally to a default value.
Implementations that do lookup in blockchain can easily check that
htlc_maximum_msat doesn't exceed the real capacity, and discard those
messages if they see fit.
By simply adding 8 bytes at the end it should be an easy fix that is/should
be compatible with current implementations (devs:please verify your parsing
code, i haven't).
We also have flexibility to adjust these values just as we adjust the
disable flag or fees.
That means we could optionally perodically announce this value to reflect
the average local balance, and thereby make it much easier for
implementations to avoid for instance channels with low or 0 balance.
Even if not periodically gossiped it would help in many cases.
Consider an AMP payment of 100k going thru a channel which only has 50k
local balance. The node already responds with an error with an attached
type258 message.
Let it reflect the current local balance in htlc_maximum_msat, so the AMP
implementation can directly try 50k instead.
Without that info in the error, the AMP implementation would have to try
90k, 80k, 70k, 60k, 50k before getting through, taking up time and
resources.
Other implementations of it would be to set it in order to traffic control
without having to signal it as disabled, and thereby passively balance
channels, or making sure most funds end up on whatever desired side before
closing on-chain. And there are other things you can do once we have this.
I think it would be a simple 8-byte fix with huge advantages and
possibilities.
Regarding abuse:
Nodes checking blockchain can discard erroneous messages. If the messages
slip thru to a wallet that doesn't verify, how much could this possibly
hurt and where? Today for instance Eclair assumes all channels are wide
enough anyhows.
Regarding bandwidth:
Nodes should not broadcast updates after every packet, but do it wisely.
And optionally. You could just announce the original capacity.
Regarding privacy concerns:
Use cases such as revealing local balances are of course totally optional
and does not need to be activated for those node owners that prefer ppl to
instead use repeated trial-and-error probing to discover the local balance.
I'm currently working on a tool for that, but if this proposal is adopted
i'll obviously scrap that project.
Best regards
Robert Olsson
On Sun, Jul 29, 2018 at 3:59 PM, Артём Литвинович <theart...@gmail.com>
wrote:
> 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
>
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
