--- Log opened Mon Oct 12 00:00:44 2020 00:03 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning 00:07 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds] 00:45 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning 01:51 -!- jonatack [~jon@134.19.179.147] has quit [Ping timeout: 244 seconds] 02:04 -!- kexkey [~kexkey@91.193.6.10] has quit [Ping timeout: 265 seconds] 02:35 -!- jonatack [~jon@37.166.80.90] has joined #c-lightning 02:52 -!- jonatack [~jon@37.166.80.90] has quit [Read error: Connection reset by peer] 03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 03:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning 03:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 03:48 < m-schmoock> darosior: have you seen my comment: https://github.com/lightningd/plugins/pull/147#pullrequestreview-497893100 03:49 < m-schmoock> also, after some discussions on the last meeting, I recommend only setting custom fees if inbalance exceeds a high value i.e > 80% in order leak less information about channel balances 04:02 < m-schmoock> also added this 04:06 < darosior> hm? What was discussed during last meeting ? 04:06 < darosior> Taking a look to your comment now 04:09 < darosior> Ok i don't get the rationale, continuing the discussion there. 04:09 < m-schmoock> we briefly touched it in terms of privacy leak 04:09 < m-schmoock> rusty added that it might be sane to only set custom fees if imbalance is high enough 04:10 < zmnscpxj__> my own thinking is to set three possible values, low-med-high, and set fees according to imbalance 04:10 < m-schmoock> because otherwise, by looking at all channels and their fees, we leak out almost all information about out channel balance +-1.5 % 04:10 < zmnscpxj__> with hysteresis at the boundaries between fees 04:11 < m-schmoock> zmnscpxj__: low-mid-high seems good but how to determine these values (same goes for the floating value). can we measure some kind of "good" fee in terms of channel usage / time ? 04:12 < m-schmoock> because only then it is somehow useful to set fees at all 04:12 < zmnscpxj__> what I am doing in my automated node manager is to get the median of all the peers of your peer and use it as the basis 04:12 < zmnscpxj__> not sure how to adjust it for the low and high tho. 1/2 and 2x maybe? 04:12 < m-schmoock> something like that 04:13 < zmnscpxj__> sampling at irregular intervals also helps reduce leaks IMO, but I might be wrong 04:15 < m-schmoock> setting an appropriate base fee can be done not only with direct peers but also with their peers... 04:15 < m-schmoock> ah 04:15 < m-schmoock> you already said taht 04:15 < m-schmoock> :D 04:15 < zmnscpxj__> haha 04:15 < zmnscpxj__> seemed to make sense to me 04:15 < m-schmoock> indeed 04:15 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver] 04:16 < m-schmoock> we should add that to the feeadjuster 04:16 < zmnscpxj__> since you are competing with the peers of your peer, sort of 04:16 < m-schmoock> yup 04:16 < zmnscpxj__> But it seems to me that every node is very likely to be its own little snowflake with its own unique connectivity 04:17 < zmnscpxj__> and it might be able to afford to increase its fee relative to its competitors in some situations 04:17 < zmnscpxj__> been studying price theory as well, LOL 04:17 < m-schmoock> human action 04:17 < m-schmoock> ln action :D 04:17 < zmnscpxj__> but not sure how best to derive the best price without having to make the auto node manager be an experimenter by itself 04:18 < zmnscpxj__> i.e. set the price lower, run for a bit, set the price higher, run for a bit, see which one gets better raw income 04:18 < zmnscpxj__> because economics wise, there is an optimal price for any service you make 04:19 < zmnscpxj__> but then the network around you is changing as well, possibly disrupting your experiments and making it diverge from purity 04:19 < zmnscpxj__> oh well 04:19 < zmnscpxj__> the"median of peers of peer" is a reasonable starting point IMO 04:22 < darosior> FWIW i don't think it is :) 04:22 < zmnscpxj__> how so 04:22 < zmnscpxj__> ? 04:22 < darosior> From my own experience setting really high fees when you are a consequent router is the more reasonnable 04:22 < darosior> Like way more than all your peers 04:23 < zmnscpxj__> "consequent router" means what? 04:23 < darosior> I mean i've been testing different economic strategies on a ~70-100 channels node for months 04:24 < zmnscpxj__> okay, so what does "consequent router" mean? larger than your competitors? 04:25 < darosior> Ah, i meant like big enough to do some stats.. 04:25 < zmnscpxj__> hmmm 04:25 < zmnscpxj__> you mean you look at channels with high fee/second and bump their fees up? Is that it? 04:26 < zmnscpxj__> or...? 04:26 < darosior> I mean i've been increasing the base and ppm fees for a while, nothing based on my peers 04:27 < darosior> Actually if i did, my (required atm..) rebalancings would cost me way too much 04:27 < darosior> Hence my plugin 04:27 < zmnscpxj__> ah 04:28 < zmnscpxj__> but it seems to me that this approximates as well what I described: if you have been getting a lot of fees from outgoing forwards on a channel, that channel is also likely to be depleted and your plugin would bump up its fees by a good amount 04:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 04:29 < darosior> Yeah, and exponentially discount its usage in the other way 04:29 < darosior> Which, i expect would reduce my rebalancing cost 04:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning 04:30 < zmnscpxj__> I see 04:30 < zmnscpxj__> <--- was pretty bored of managing nodes, which is why he started an auto node manager 04:31 < darosior> I also expect that: the more connected the node is, the more it is efficient. On my personal small node (~20 chann something like that) i don't get enough forwarding request for it to make any diff 04:31 < zmnscpxj__> I once got a forward on a node with 20mBTC in 4 channels, that was weird 04:32 < zmnscpxj__> so a high-connectivity node can afford to increase its fees as well? 04:32 < darosior> "was pretty bored of managing nodes, which is why he started an auto node manager" => I definitely understand that x) 04:33 < zmnscpxj__> I should probably make an alpha release and announce it at this point 04:33 < zmnscpxj__> maybe some time this month 04:33 < darosior> Would be great, maybe talk to Matt too for some feedback 04:33 < darosior> He went really deep with his node management ^^ 04:34 < zmnscpxj__> Matt Corallo? 04:34 < darosior> No 04:34 < zmnscpxj__> which Matt? 04:34 < darosior> whitslack 04:34 < zmnscpxj__> ok 04:34 < darosior> https://github.com/whitslack 04:36 < zmnscpxj__> okthx 04:40 -!- jonatack [~jon@109.232.227.138] has joined #c-lightning 04:48 -!- jonatack [~jon@109.232.227.138] has quit [Ping timeout: 256 seconds] 04:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning 04:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Client Quit] 04:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning 04:52 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving] 04:54 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning 04:59 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 260 seconds] 05:02 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds] 05:23 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning 05:27 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 260 seconds] 05:30 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:2fc:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 260 seconds] 05:41 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning 06:11 -!- jasan [~jasan@just.do.nothing.bublina.eu.org] has quit [Quit: Bye!] 06:24 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver] 06:34 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:2fc:ea40:f2ff:fe85:d2dc] has joined #c-lightning 06:45 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning 07:04 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 07:37 < m-schmoock> darosior: maybe you should add a threshold option one can configure and lets discuss the default for that value if should be 25, 30 or even 50 or whatever percentage. I just dont feel comfortable to have a plugin that more or less discoloses all channel balance with a very high degree of accuracy 07:38 < darosior> I think you overstate it 07:38 < darosior> But sure, i agree it should be configurable 07:40 < m-schmoock> :) 07:44 < m-schmoock> setting fee default value can/should be done in a separate plugin 07:51 < az0re> Yeah, and exponentially discount its usage in the other way 07:51 < az0re> Wait, maybe I misunderstand: I thought the feerate you set only applies to outgoing forwards on that channel 07:51 < darosior> Yeah 07:52 < darosior> But you likely have other ones 07:52 < az0re> So isn't it up to your channel peer to discount the feerate to balance out the channel? 07:52 < darosior> You direct the user of your liquidity to other channels 07:52 < az0re> Not sure what you mean there 07:52 < az0re> How do you direct someone to other channels? 08:00 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 08:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 08:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning 08:07 < darosior> I mean: likely the wallet constructing is not going to use this channel as outgoing (or pay a huge fee, so fine with that) but instead they could use it as incoming and use one of your other channels as the outgoing one (which'd been discounted during the last forward event) 08:08 < darosior> az0re: btw is this a coincidence or is your pseudo related to the Azore islands ? 08:19 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning 08:28 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 08:28 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning 08:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds] 08:34 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds] 08:39 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning 08:57 -!- cltrbreak_MAD2 is now known as ctrlbreak 09:19 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 09:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 10:05 < az0re> Right, makes sense 10:05 < az0re> Not really related 11:13 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver] 11:32 -!- ksedgwic_ [~ksedgwic@157-131-253-103.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal] 11:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 265 seconds] 11:37 -!- ksedgwic [~ksedgwic@157-131-253-103.fiber.dynamic.sonic.net] has joined #c-lightning 11:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 12:02 -!- reallll [~belcher@unaffiliated/belcher] has joined #c-lightning 12:04 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 12:04 < ark> rusty: 12:05 < ark> could you look at the log? 12:06 -!- reallll is now known as belcher 12:18 < rusty> ark: sorry, #lightning-dev meeting RN. Let me take a look... 12:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning 12:21 < rusty> ark: gah, that 0bin link expired, sorry. I grabbed it from the logs, as I was offline when you pasted it. 12:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] 13:11 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 13:11 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 13:17 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 244 seconds] 13:20 -!- jonatack [~jon@104.254.90.235] has joined #c-lightning 13:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 15:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 15:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning 15:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 16:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 16:12 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning [] 16:12 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning 16:56 -!- polydin [~george@136.49.254.169] has joined #c-lightning 16:57 -!- polydin [~george@136.49.254.169] has quit [Client Quit] 17:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 17:02 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 18:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 19:13 -!- grubles [~unknown@unaffiliated/grubles] has quit [Ping timeout: 256 seconds] 19:13 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning 19:17 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds] 19:36 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 20:06 -!- ark [~juan@89.32.80.84] has quit [Ping timeout: 240 seconds] 21:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 21:46 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection] 22:05 -!- polydin [~george@136.49.254.169] has joined #c-lightning 22:06 -!- polydin [~george@136.49.254.169] has quit [Client Quit] 23:31 -!- jasan [~jasan@just.do.nothing.bublina.eu.org] has joined #c-lightning 23:33 < jasan> Good morning! Vincenzo is not here? I am wondering what gradle task should I use to build APK out of current sources. I tried "assemble" now. Will try "build" next. --- Log closed Tue Oct 13 00:00:45 2020