--- Log opened Mon Aug 23 00:00:46 2021
00:41 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 252 seconds]
02:50 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
03:25 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has joined #c-lightning
03:29 < mschmoock> does someone know how I get a channels capacity using gossmap code?
03:40 < mschmoock> Do I have to query the Blockchain for each channels funding TX to know that or is there a better way?
03:48 -!- jonatack [~jonatack@user/jonatack] has joined #c-lightning
04:01 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
04:03 < darosior> mschmoock: i am not familiar with the gossmap code but FWIW we already do a `gettxout` when receiving a channel announcement so perhaps the utxo value (returned by `gettxout`) is stored in the gossmap along with the channel announcement?
04:05 < cdecker[m]> The gossmap stores the capacity of the channel after the node_announcement, which can then be loaded via gossmap client libraries. https://github.com/ElementsProject/lightning/blob/48473eb3e994d72e0088ab7a2f0a3fb15d819da3/gossipd/gossip_store_wire.csv#L7-L9
04:05 < cdecker[m]> The C gossmap will read those values into memory, checking the Python gossmap now
04:06 < rusty> mschmoock: you can use htlc_max as a useful approxmation, since almost all channel updates add that now.
04:15 < vincenzopalazzo> Guys stupid question, the new version of the package pyln-sec it is update with the new c-lightning version? because I'm getting the following warning `ERROR: pyln-bolt1 1.0.1.137 has requirement pyln.proto==0.8.4, but you'll have pyln-proto 0.10.1 which is incompatible.` but it think this is over with the following PR https://github.com/ElementsProject/lightning/pull/4679/files
04:19 < cdecker[m]> That's because the version on pypi is really old, and still predates that PR. I'll look into automating deployments of the pypi artifacts via GH actions
04:31 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.]
04:33 < vincenzopalazzo> Christian Decker: Thanks for this :) I'm try to fix the warning in lnprototest
04:36 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
04:40 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 240 seconds]
05:22 < mschmoock> cdecker[m]: the route.c uses  common/gossmap.c  line 1078 to determine if a HTLC would fir in a channel. But htlc_max is an optional value and when not set will be zero 0. Am I right that this will return false for all channels that do not set htlc_max? I do not know how many channels there are without htlx_max, but there are some. can we ignore them?
05:22 < mschmoock> *would fit
05:25 < mschmoock> also htlc_max does not really tell us about total channel capacity. or do all nodes if they set this set it to the maximum capacity and not some smaller value?
05:25 < cdecker[m]> Line 493 looks to me like it's setting htlc_max to uint16_max, which should be close enough
05:25 < mschmoock> :D
05:25 < cdecker[m]> Well, max_htlc is the maximum we can pass through it, so no point in having the extra precision.
05:26 < mschmoock> sure, for routing parts of a payment this is sufficient information
05:26 < cdecker[m]> Like I said, if you need the actual size, you can read the message that follows the channel announcement and that'll just be a single u64 that indicates the size
05:26 < mschmoock> but I want to use the pyln-client gossmap stuff to do fee adjustments and rebalances etc, so it would be good to have the channel capacity as well
05:27 < mschmoock> cdecker[m]: thx, will try
05:31 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 244 seconds]
06:02 < cdecker[m]> Agreed, memory is less of an issue with python, but maybe we can build multiple specialized gossmap implementations (through mixins maybe) that retains more or less in memory.
06:10 < mschmoock> Yes, the one we work on right now isnt very optimized yet :]
07:07 -!- jonatack [~jonatack@user/jonatack] has joined #c-lightning
07:16 < mschmoock> cdecker[m]: like this? https://github.com/rustyrussell/lightning/pull/7/commits/969c90df84be18603c69f272f4496b4cb1e19855
08:49 < mschmoock> cdecker[m]: now its this due to rebase   https://github.com/rustyrussell/lightning/pull/7/commits/bea93dfa024fc4b4f90979f2b1742a053e485c89
08:49 < mschmoock> nvm, seems to work
08:49 < mschmoock> thx <3
08:49 < cdecker[m]> Sorry for the delay, was stuck in phone calls :-)
08:49 < cdecker[m]> I'll take a look asap
08:53 < mschmoock> pretty straight forward. thanks for the hint
12:13 -!- nathanael [~nathanael@user/nathanael] has quit [Quit: connection reset by purr]
12:21 -!- nathanael [~nathanael@user/nathanael] has joined #c-lightning
12:58 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
13:00 < michaelfolkson> Jitsi link?
13:01 < michaelfolkson> Is it the same every time?
13:01 < rusty> Hello everyone! The biweekly c-lightning (dev) meeting is in um, 0 minutes at https://meet.jit.si/CLightning-Open-Meeting
14:37 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 250 seconds]
15:54 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
16:03 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
16:04 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
16:37 -!- rusty [~rusty@tro1759202.lnk.telstra.net] has joined #c-lightning
16:55 -!- rusty [~rusty@tro1759202.lnk.telstra.net] has quit [Ping timeout: 248 seconds]
17:04 -!- rusty [~rusty@203.221.41.134] has joined #c-lightning
18:12 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
18:22 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 250 seconds]
18:35 -!- belcher [~belcher@user/belcher] has joined #c-lightning
18:56 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
22:41 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 250 seconds]
23:05 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has joined #c-lightning
--- Log closed Tue Aug 24 00:00:47 2021