--- Log opened Tue Oct 06 00:00:38 2020 00:18 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning 00:33 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection] 00:51 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Ping timeout: 240 seconds] 00:52 -!- alko89 [~alko89@unaffiliated/alko89] has joined #c-lightning 00:57 -!- kexkey [~kexkey@89.36.78.150] has quit [Ping timeout: 240 seconds] 01:46 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning 01:54 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 02:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 02:22 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 02:42 < az0re> What the actual fuck?! The mempool is 6MB right now, and a channel peer close a channel. In `listpeers`, I see: "CLOSINGD_SIGEXCHANGE:We agreed on a closing fee of 1XXXX satoshi for tx:..." 02:42 -!- jonatack [~jon@37.167.72.239] has joined #c-lightning 02:42 < az0re> Why the FUCK is C-Lightning willingly agreeing to pay over 10ksats for a simple transaction with one utxo in and two outputs?! 02:43 < az0re> This is very, very broken 02:43 < az0re> Seriously that transaction should have been no more than 1ksat 02:43 < az0re> And it's *well over* 10x that 02:44 <@cdecker> Well, your peer is asking for a close, and we need to have reasonable fees to get confirmed, if there's a proposal on how to handle it in the future you're free to propose a change 02:44 <@cdecker> Were you the funder of the channel? 02:44 < az0re> Yes 02:44 < az0re> Sure, reasonable fees to get confirmed, great 02:44 < az0re> well over 10ksat is *not* reasonable right now 02:44 < az0re> at all 02:44 < az0re> not even close 02:45 <@cdecker> Ok, then propose a better fee estimation mechanism for this kind of transaction 02:45 < az0re> What are the constraints? 02:45 < az0re> If it's totally up to me to choose, I choose 1 sat/vbyte and wait around indefinitely 02:46 <@cdecker> It needs to be based on bitcoind's estimates, it needs to confirm in a reasonable time (6-12 hours) and it must not be gameable by your peer 02:46 <@cdecker> Sure, you do that, but those transactions are pruned out of the mempool almost immediately, so they'll never confirm 02:46 < az0re> Why does it need to confirm in 6-12 hours? Will the peer broadcast a unilateral close? 02:47 < az0re> You say that but my experience dictates otherwise :) 02:47 <@cdecker> Eventually they'll do that, yes 02:50 < az0re> Here's a pulled-out-my-ass heuristic: three modes -- fast, normal, slow. Take 0.5MB, 2MB, 7.5MB off the top of the mempool and copy what feerate is used at that point. 02:50 < az0re> I choose the mode, and my node refuses to agree to rates higher than that 02:57 < az0re> I guess the lightning protocol does not allow for this (or does it?) but it feels wrong to me that my channel peer can come along after I carefully minimized the channel funding feerate and convince me to pay a gigantic fee whenever they want to cash out the channel I funded. There is a sort of moral hazard here; they do not pay the fee and so they have no incentive to minimize fee rates. I think the channel peer needs to have some skin in 02:57 < az0re> the game; they need to share the channel commitment fees. 02:58 < az0re> I get that since I'm opening the channel, it can't cost them to close it. But if I send some payment through that channel, they should start picking up the fee, up to maybe 50% or even 100% if the channel capacity is totally lopsided on their end. 03:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 03:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning 03:03 < az0re> For real, I just paid about as much for this stupid commitment tx as I've paid in the last dozen onchain transactions. At that point: Why even use the lightning network? My fees are lower if I stick to onchain transactions! 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:15 < az0re> It's ~50x the funding tx feerate, BTW. Total insanity. 03:23 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning 03:33 -!- Netsplit *.net <-> *.split quits: jasan 03:34 -!- Netsplit over, joins: jasan 03:48 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has quit [Quit: WeeChat 2.9] 03:48 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has joined #c-lightning 03:52 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has quit [Client Quit] 04:01 -!- jajomojo [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has joined #c-lightning 04:01 -!- jajomojo is now known as jsarenik 04:02 -!- jsarenik [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has quit [Client Quit] 04:06 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 04:32 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 04:49 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has joined #c-lightning 04:54 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has quit [Client Quit] 04:55 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has joined #c-lightning 04:56 < darosior> cdecker: oh just noticed https://github.com/ElementsProject/lightning/issues/4110 is good first issue 04:56 < darosior> We can do other way around instead if you prefer: a new contributor can do it and i review (happy with both) 04:57 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has quit [Client Quit] 04:57 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has joined #c-lightning 04:58 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has quit [Client Quit] 05:05 <@cdecker> No problem, we have more good firsts than we have first time contributors :-) 05:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 05:11 -!- jasan [~jasan@gateway/tor-sasl/jasan] has joined #c-lightning 05:12 -!- jonatack [~jon@37.167.72.239] has quit [Read error: Connection reset by peer] 05:13 -!- jasan [~jasan@gateway/tor-sasl/jasan] has quit [Client Quit] 05:13 -!- jasan [~jasan@gateway/tor-sasl/jasan] has joined #c-lightning 05:15 -!- jasan is now known as jasan_ 05:15 -!- jasan_ is now known as jasan 05:18 -!- jasan is now known as jasan_ 05:18 -!- jasan_ is now known as jasan 05:18 -!- jasan [~jasan@gateway/tor-sasl/jasan] has quit [Remote host closed the connection] 05:19 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has joined #c-lightning 05:20 -!- jasan is now known as jasan_ 05:22 -!- jasan_ [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has quit [Client Quit] 05:22 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has joined #c-lightning 05:24 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has quit [Client Quit] 05:24 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has joined #c-lightning 05:25 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has quit [Client Quit] 05:26 -!- jasan [~jasan@gateway/tor-sasl/jasan] has joined #c-lightning 05:57 -!- jasan [~jasan@gateway/tor-sasl/jasan] has quit [Quit: jasan] 05:59 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has joined #c-lightning 06:01 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has quit [Client Quit] 06:01 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has joined #c-lightning 06:04 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has quit [Client Quit] 06:05 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has joined #c-lightning 06:12 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning [] 06:12 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning 06:13 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has quit [Quit: ZNC - http://znc.in] 06:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning 06:58 -!- justan0theruser is now known as justanotheruser 07:03 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning 07:11 -!- jasan [~jasan@2001:470:6f:200:49c7:2cef:13c7:4e2b] has quit [Quit: jasan] 07:11 -!- jasan [~jasan@love.people.use.things.eat.food.bublina.eu.org] has joined #c-lightning 07:17 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has joined #c-lightning 07:21 -!- kexkey [~kexkey@37.120.205.214] has joined #c-lightning 07:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 07:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning 08:43 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 08:44 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 09:04 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 256 seconds] 09:12 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver] 09:59 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.7.5 - https://znc.in] 10:01 -!- alko89 [~alko89@unaffiliated/alko89] has joined #c-lightning 10:11 -!- jasan [~jasan@love.people.use.things.eat.food.bublina.eu.org] has quit [Quit: Bye!] 11:46 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 11:48 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 12:05 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 12:06 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 12:14 -!- queip [~queip@unaffiliated/rezurus] has quit [Quit: bye, freenode] 12:15 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning 12:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 13:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 13:40 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection] 13:42 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning 13:56 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning 13:58 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds] 14:07 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds] 14:22 -!- ark [59205054@89.32.80.84] has joined #c-lightning 14:22 < ark> hello 14:24 < ark> When forwarding payments I get the following error "Adding HTLC too slow: killing connection" 14:25 < ark> I've been looking at the code to see what that might be. But I can't find the reason why the 30-second timeout skips 14:25 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning [] 14:26 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning 14:45 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 14:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 14:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 14:57 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning 14:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 15:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:07 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection] 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:18 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #c-lightning 15:20 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 260 seconds] 15:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 15:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #c-lightning [] 15:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 15:37 < rusty> ark: does it take over 30 seconds? 15:37 < rusty> ark: it can happen if the peer doesn't respond to a ping, too. 15:38 < rusty> ark: i.e. if we haven't heard from the peer recently, we send a ping to test it's still alive. But either way, it should get 30 seconds before it fails the HTLC 15:42 < rusty> az0re: that's v. weird. We use the 'estimatefee 4 economical' output from bitcoind as our start point for negotiation. 15:42 < rusty> az0re: propose we drop that to slow (100 economical) for mutual close, given how overzealous bitcoind is? 15:43 < az0re> Not sure exactly what these terms represent 15:44 < az0re> I guess `slow` is a lower fee rate than `economical` at iso-mempool, so yes, I support that in general 15:44 < rusty> az0re: bitcoind tries to estimate given how many blocks you want your tx in, and whether you want to be conservative (i.e. overpay) or economical. 15:44 < az0re> But more fundamentally I think the fee estimation is just broken 15:44 < az0re> So economical is a 4 block target? 15:44 < rusty> az0re: but yes, fee estimation in bitcoind is kind of doing the impossible. 15:45 < rusty> az0re: you can ask for 'estimtesmartfee 4 economical' or 'estimatesmartfee 4 conservative' 15:45 < az0re> Gotcha 15:46 < az0re> let me play with bitcoin-cli and see what the results are for `4 economical` and `100 economical` and how sane they look 15:47 < rusty> az0re: try 10 econ too, I think that's probably what we should be using for opening (we use 4 economical, and TBH it's a bit aggressive) 15:49 < az0re> So 4 economical seems way too high, even at current mempool 15:49 < rusty> FWIW< I get: 0.00110515 for 4, 0.00106561 for 10, 0.00003016 for 100 15:49 < az0re> Mine matches closely 15:50 < rusty> az0re: yeah, it's way too aggressive :( 15:50 < az0re> 100 is, what, 3 sat/byte? Probably a bit too low at current mempool 15:50 < az0re> 10 economical is nearly as high as 100 15:51 < az0re> I feel like goldilocks lol 15:51 < az0re> maybe 30 economical? 15:52 < az0re> 50 economical is the same as 100; 20 is the same as 10 15:52 < az0re> 10 economical is nearly as high as 100 15:52 < az0re> sorry, that should be "nearly as high as 4" 15:57 < rusty> az0re: yeah, mine drops around 50... 15:58 < az0re> 30 economical gives me: { 15:58 < az0re> "feerate": 0.00061896, 15:58 < az0re> "blocks": 30 15:58 < az0re> } 15:58 < az0re> I think that's about right at the moment 15:58 < az0re> Maybe I should just keep getting estimates for a while to get a good sense of the best choice in all mempool conditions 15:59 < rusty> 25: 0.00101600, 15:59 < rusty> 26: 0.00096645, 15:59 < rusty> 27: 0.00068221, 15:59 < az0re> Maybe a bit high, still, 40 gives 0.00053476 15:59 < rusty> 48: 0.00050569, 15:59 < rusty> 49: 0.00004021, 15:59 < rusty> 50: 0.00004021, 16:00 < rusty> 49 is the magic number... I suspect, as you do, the magic moves however. 16:00 < az0re> lol at 48->49 16:00 < az0re> Yup, I'll keep an eye on it 16:01 < rusty> $ bitcoin-cli estimatesmartfee 49 ECONOMICAL 16:01 < rusty> { 16:01 < rusty> "feerate": "¯\_(ツ)_/¯", 16:01 < rusty> "blocks": 49 16:01 < rusty> } 16:01 < az0re> In the meantime, where in the code is the relevant knob? I'd like to change to 40 in the meantime 16:01 < az0re> lol 16:01 < az0re> pretty much 16:02 < rusty> az0re: it's actually a plugin, you can write your own. But meanwhile, look at plugins/bcli.c 16:02 < az0re> Will do, thanks 16:03 < rusty> az0re: so, on my infinite todo list is to write the CPFP code, so we can drop these fees dramatically if the peer supports anchor outputs (which allows you to push txs using CPFP) 16:03 < az0re> Unfortunately I am totally ignorant about anchor outputs 16:03 < az0re> I know child pays for parent, but not sure about anchor outputs 16:04 < az0re> But dramatically dropping fees sounds good :) 16:04 < rusty> az0re: that's ok, it's already implemented. We basically add a couple of outputs to the commitment tx, for each side to use to use CPFP 16:04 < ark> rusty: According to the logs it is what it looks like. But the problem is that it does not only come out with that channel, but with a lot 16:05 < rusty> ark: how slow is your machine? Or network? 16:06 < ark> It is an rpi3, and well the network is quite fast. In addition to being directly connected by network cable 16:07 < rusty> ark: hmm, ok, that should work fine. 16:07 < rusty> ark: I will fire up my rpi and see if I can spot any obvious issues 16:08 < ark> If I pass the log to you in debug mode, could it help? 16:08 < rusty> ark: yeah, use 0bin or send via email to rusty@blockstream.com maybe? 16:09 < ark> Perfect 16:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 16:12 < az0re> bbl 16:12 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Quit: Leaving] 16:14 < ark> https://0bin.net/paste/cGCPOEtH#1tJ4BHAtv0qMjAVYqOAqByuM5Na5X0Ru8KR-cRUcTZM 17:00 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 17:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 17:16 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning 17:17 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 17:18 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 17:37 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 17:41 -!- niftynei changed the topic of #c-lightning to: Next meeting here @8PM UTC Monday Oct 19! Chat about the C-lightning implementation: https://github.com/ElementsProject/lightning https://lists.ozlabs.org/listinfo/c-lightning Current Version: https://github.com/ElementsProject/lightning/releases/tag/v0.9.1 Logs at http://gnusha.org/c-lightning/ Dev Roadmap: https://github.com/ElementsProject/lightning/wiki 17:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 19:23 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning 19:28 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 20:37 < az0re> rusty: So it looks like I should change (from git HEAD) plugins/bcli.c:560 to `params[0] = "49";` (or whatever we end up using) to change the fee estimation for the `normal` rate. And also I should change plugins/bcli.c:517 to something like `stash->slow * bitcoind->max_fee_multiplier);` to reduce the maximium feerate my node is willing to negotiate. 20:37 < az0re> Does that sound about right? 20:39 < rusty> az0re: it does, but beware the second change. If a peer tries to set more than that, we *close the channel*; I would leave it alone. 20:39 < rusty> (Rememebr, they're paying the fees, except for HTLC transacitons where we pay some) 20:39 < rusty> (If they're not paying the fees, they can't update them) 20:40 < az0re> Hmmm 20:40 < az0re> Maybe I misunderstand the context of this negotiation 20:40 < az0re> I thought this was for a mutual close 20:41 < zmnscpxj__> used for both 20:41 < zmnscpxj__> though the second change is only for unilateral 20:41 < zmnscpxj__> what are you trying to do? 20:42 < az0re> I'm trying to avoid paying excessive fees 20:42 < az0re> I can control the funding tx feerate just fine 20:43 < zmnscpxj__> for a channel you opened 20:43 < zmnscpxj__> ? 20:43 < az0re> Yes 20:43 < zmnscpxj__> well, for a mutual close, this is a negotiation 20:43 < az0re> So I have two goals: 20:43 < az0re> 1) Avoid agreeing to excessive fees in a mutual close negotiation 20:43 < az0re> 2) Limit the size of the allowable unilateral close feerate to something bigger but still not so extreme 20:44 < az0re> I got burned by both already... 20:44 < zmnscpxj__> ah 20:44 < zmnscpxj__> these are very hard problems actually 20:44 < az0re> :-\ 20:44 < zmnscpxj__> first, if the non-opener side has an HTLC it is interested in, that is on the channel you opened 20:44 < zmnscpxj__> and *you* go offline 20:45 < zmnscpxj__> it has to have a unilateral close *you* signed that it can make appear onchain quickly, i.e. high fee 20:45 < rusty> az0re: well, I have a patch I'm working on now whch changes the default close rate to slow (i.e. 100 ECONOMICAL). 20:45 < zmnscpxj__> rusty: mutual close? 20:45 < az0re> That's fine with me just so long as their need to get a quick onchain tx doesn't cost *me* so much 20:46 < zmnscpxj__> az0re: unfortunately with the *current* spec, yes, it does cost *you* much :) 20:46 < az0re> rusty: Cool beans. Although I worry 100 ECONOMICAL might be too low. 20:46 < az0re> So, the spec needs to be changed lol 20:46 < zmnscpxj__> which is why there are discussions on anchor commitments, also t-bast recent post on lightning-dev as well 20:46 < az0re> I'm sure this is super hard 20:46 < zmnscpxj__> yes, onchain fees are always a problem 20:46 < zmnscpxj__> squared by the fact that there are now two nodes interested in the feerates 20:47 < az0re> Some sort of fee sharing I think is the way to go, to align incentives 20:47 < rusty> zmnscpxj__: yes.. 20:47 < rusty> az0re: yes, dual opening does this, in fact. 20:47 < zmnscpxj__> anchor commitments "should" help with this 20:47 < zmnscpxj__> (emphasis on "should") 20:47 < zmnscpxj__> rusty: but only on the funding tx IIUC? 20:48 < az0re> I didn't realize dual opening was a thing; I tried to open a channel to a node who opened one to me, got an error, and assumed it wasn't possible 20:48 < zmnscpxj__> dual opening is a new thing, where both of you arrange to open a single channel at the same time 20:48 < zmnscpxj__> note that other LN implementations support multiple channels per peer, we in C-Lightning deliberately do not support this as policy 20:48 < az0re> And what, commitment tx fees are split 50/50? 20:49 < rusty> zmnscpxj__: we'll use it for shutdown and splice, too. 20:49 < az0re> Aha I see 20:49 < zmnscpxj__> ah...? 20:49 < az0re> Or there are just two channels each with its own funding and commitment tx 20:49 < rusty> az0re: you're always better off making a triangle, TBH 20:49 < zmnscpxj__> yes 20:50 < az0re> rusty: Justice Kavanaugh agrees 20:50 < zmnscpxj__> so I can induce a victim to donate fees in a outgoing-capacity-draining attack I mount? 20:50 < az0re> No idea how to do that with LN channels, though ;) 20:50 < rusty> zmnscpxj__: always true, right? 20:51 < zmnscpxj__> yes, but if dual-funding shares fees even on closing, then the passive waiter on dual funding is induced to donate fees *in addition* 20:51 < zmnscpxj__> unless we specifically limit dual-funding to requiring a command "I allow allocating n satoshi to node X when it dual-funds to me"? 20:52 < zmnscpxj__> and default to "no I do not have funds" when somebody wants to dual-fund, even if we have onchain funds. 20:52 < rusty> zmnscpxj__: actually, I think that the commit tx funding is unchanged, sorry. But closing will be fair split by weight. 20:53 < zmnscpxj__> mutual? 20:53 < az0re> rusty: fair split by weight on commitment tx fees for a dual-open channel--correct? just to make sure I'm on the same page 20:54 < rusty> zmnscpxj__: yes, sorry, closing. Perhaps we should make person who proposes close (or initial opener?) pay for input and core, then split the rest? Or maybe simply split according to output ratio? 20:54 < rusty> niftynei is the one implementing it. 20:55 < zmnscpxj__> for mutual, output ratio seems appropriate at least. Or change the negotiation to "I am willing to pay n satoshis in fees", which is nearer to the control that users want 20:55 < rusty> az0re: no, I misspoke. The current proposal splits the funding tx fees depending on who proposes what inputs and outputs. But I think we left the commit tx alone. 20:55 < zmnscpxj__> ah, okay 20:56 < az0re> OK 20:56 < az0re> I like the person who proposes close pays for a chunk of it 20:57 < zmnscpxj__> but anyway, az0re: onchain fees have been a headache for a long time, because it can be used in some attacks. low fee to delay them, high fee to drain them 20:57 < az0re> Maybe after some weight threshold 20:57 < az0re> That makes sense 20:58 < az0re> To automate reasonable behavior in all situations is surely not easy 20:58 < az0re> Especially with the underlying nondeterminism in block mining 20:58 < zmnscpxj__> definitely 20:59 < zmnscpxj__> and since we use pre-signed txes, fees that are reasonable *now* when both of you are online, could be too low or too high later when one of you is offline 21:00 < zmnscpxj__> which is what squares the problem 21:00 < zmnscpxj__> anchor commitments allow for lowballing the presigned fees, but now commitments are larger and thus more expensive in blocksize too, sigh 21:01 < az0re> Now I get it 21:01 < az0re> And basically whoever wants the funds urgently can CPFP it and *they* pay for it 21:02 < zmnscpxj__> with anchor commitments, yes 21:02 < az0re> makes good sense 21:02 < az0re> I wonder what effect it has on transaction distinguishability 21:02 < zmnscpxj__> without it, because of the CSV restrictions on the scripts that ensure correct behavior, it is not possible to CPFP 21:02 < az0re> Does it make LN commitment transactions stand out? 21:03 < zmnscpxj__> which is why we need anchor commitments 21:03 < zmnscpxj__> Even today, LN commitment transactions already stand out 21:03 < az0re> On a mutual close? 21:03 < az0re> Don't the look just like a CoinJoin tx? 21:03 < zmnscpxj__> mutual closes do not use commitment txes 21:03 < az0re> Oh, right 21:03 < zmnscpxj__> but on a mutual close, that is a 2-of-2 being openly spent 21:03 < zmnscpxj__> on both a unilateral and a mutual close, you are spending a single 2-of-2 21:04 < zmnscpxj__> and nearly every use of the 2-of-2 now is Lightning 21:04 < az0re> Especially with different utxo sizes 21:04 < az0re> I see 21:04 < zmnscpxj__> because if you are going to do mutisig on your *own* funds you would do "never go to sea with two chronometers, bring either one or three" 21:04 < zmnscpxj__> meaning you will either do 1-of-1 P2WPKH, or start with 2-of-3 at minimum 21:05 < zmnscpxj__> so 2-of-2 has a very high probability of being an LN channel close 21:05 < az0re> Not necessarily, but probably you're right 21:05 < az0re> Only in some very niche situations 21:05 < zmnscpxj__> yes 21:05 < zmnscpxj__> so if you see a 2-of-2, with high probability it is an LN channel close 21:05 < az0re> and for those situations plain old shamir's secret splitting makes more sense than a multisig scheme 21:06 < zmnscpxj__> yes, if you are a single entity who wants to split your key 21:06 < zmnscpxj__> so it looks like 1-of-1 onchain 21:06 < az0re> Right, and costs less 21:07 < zmnscpxj__> anyway, the hope is that unilateral closes are rare, so making commitment txs stand out is considered not a problem, since 99% of the time (we hope) it will not be used 21:08 < zmnscpxj__> and in current blockchain, even mutual closes stand out as well 21:12 < az0re> Yep 21:13 < az0re> And if they stand out anyway, might as well use anchor commitments 21:13 < zmnscpxj__> yes 21:13 < az0re> BTW, here's the latest version of my "low-fee routing diversity" node recommender: blob:http://aco6injncogk3siaubyh5sterx7w5pocqdrm7mna7u4wuukscgnqpeid.onion/691dd8a8-d3a9-4ee0-aee7-01198893ad5f 21:15 < az0re> It's pretty slow, as it runs pairwise maxflow between root_node and all other nodes, for each potential peer node 21:15 < zmnscpxj__> ok 21:16 < az0re> But compile with cython and you'll get good results within the first 100 peers tried, and it should finish in a couple hours max 21:16 < zmnscpxj__> "hours" oh my 21:16 < zmnscpxj__> getting a 404 21:17 < zmnscpxj__> tried on both tor browser and torify wget 21:17 < az0re> err what? 21:18 < az0re> try http://aco6injncogk3siaubyh5sterx7w5pocqdrm7mna7u4wuukscgnqpeid.onion/#MJbf7-YDryg-auXmSFYBTg 21:18 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has joined #c-lightning 21:18 < az0re> or maybe blob:http://aco6injncogk3siaubyh5sterx7w5pocqdrm7mna7u4wuukscgnqpeid.onion/8cc9ac60-ae58-431d-b0c6-86ce22a544f5 21:18 < zmnscpxj__> got 21:18 < az0re> I don't know why riseup makes it so difficult to use a pastebin service :P 21:19 < zmnscpxj__> got it 21:19 < zmnscpxj__> thanks 21:19 < az0re> cool 21:19 < zmnscpxj__> will go poke at it in a few weeks, sorry 21:20 < az0re> no worries 21:21 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 258 seconds] 21:22 < az0re> maybe I'll go through and speed it up by then; it currently duplicates a lot of effort in the interest of better clarity 21:22 < az0re> Most of the maxflows do not need to be recomputed every time 21:41 -!- jasan [~jasan@2001:470:6f:200:958c:b041:4947:c5e7] has joined #c-lightning 21:41 -!- jasan [~jasan@2001:470:6f:200:958c:b041:4947:c5e7] has quit [Client Quit] 21:47 -!- jasan [~jasan@2001:470:6f:200:958c:b041:4947:c5e7] has joined #c-lightning 21:50 -!- jasan [~jasan@2001:470:6f:200:958c:b041:4947:c5e7] has quit [Client Quit] 21:51 -!- jasan [~jasan@2001:470:6f:200:958c:b041:4947:c5e7] has joined #c-lightning 22:04 -!- jasan [~jasan@2001:470:6f:200:958c:b041:4947:c5e7] has quit [Ping timeout: 240 seconds] 22:04 < rusty> az0re: https://github.com/ElementsProject/lightning/pull/4113, I'll be happy to update the value of "normal" too over, depending on what our best guess is from your observations. 22:05 -!- jasan [~jasan@2001:470:6f:200:c2f6:bf7c:c6c:bf6b] has joined #c-lightning 22:10 -!- jasan [~jasan@2001:470:6f:200:c2f6:bf7c:c6c:bf6b] has quit [Quit: jasan] 22:16 < az0re> Cool, thanks 22:16 < az0re> The removal of commit-fee-min/max just removes any constraints that we have on channel opening requests from peers, right? 22:17 < az0re> rusty^ 22:17 < zmnscpxj__> `update_fee` as well I think? 22:17 < rusty> az0re: no, they were unused since a while ago. We actually use hardcoded values. 22:18 < zmnscpxj__> !! 22:18 < rusty> zmnscpxj__: well, hardcoded factors :) 22:18 < zmnscpxj__> ah, yes 22:18 < zmnscpxj__> but we have an option to ignore them 22:18 < zmnscpxj__> so I thought it was that 22:18 < az0re> But what's this removed in lightningd/options.c:711? 22:19 < az0re> Oh just sanity checking for the config values, I see 22:19 < rusty> az0re: you could set them, but yeah, they were only used for that sanity check. 22:43 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning [] 22:43 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning 22:47 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 23:08 -!- jasan [~jasan@2001:470:6f:200:c2f6:bf7c:c6c:bf6b] has joined #c-lightning 23:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Write error: Connection reset by peer] 23:14 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 23:14 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Read error: Connection reset by peer] 23:14 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 23:14 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Read error: Connection reset by peer] 23:14 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Read error: Connection reset by peer] 23:14 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Write error: Connection reset by peer] 23:14 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning 23:14 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 23:14 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #c-lightning 23:14 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning 23:18 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning 23:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 23:48 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning [] 23:48 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning --- Log closed Wed Oct 07 00:00:39 2020