--- Log opened Wed Feb 26 00:00:05 2020
00:14 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
00:16 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
01:09 < darosior> k3tan: I haven't tested but I heard of https://github.com/justinmoon/clhwi
01:15 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
01:17 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
01:49 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]
02:00 < vasild> I stumbled on a strange behavior that looks like a bug during channel close. Lets have two nodes: l1 and l2. When closing the channel l1 proposes a fee of 2000 and l2 proposes a fee of 1000. They start negotiatiating and eventually agree on a fee of 1500 (it is not exactly in the middle, but lets ignore this).
02:00 < zmnscpxj__> okay....
02:01 < vasild> both nodes contain in the l1.rpc.listpeers(l2_id)['peers'][0]['channels'])['status'] -- "agreed on a fee of 1500"
02:01 < zmnscpxj__> what is the strange behavior?
02:01 < vasild> and both nodes broadcast a tx
02:01 < vasild> so far so good
02:01 < vasild> however, what I find strange is that l1 broadcasts a transaction with a fee of 1000, not the agreed 1500
02:02 < vasild> l1 broadcasts the first tx it got from l2 -- l2's initial offer
02:02 < zmnscpxj__> definite bug
02:03 < vasild> yes, if that would be intentional, why bother to negotiate then and not boradcast 1000 right away :)
02:03 < zmnscpxj__> who initiated the close, and who was the original funder?
02:04 < vasild> original funder is l1, and l2 initiated the close
02:04 < zmnscpxj__> Is the transaction broadcasted by l1 valid or not?
02:04 < vasild> it is valid
02:04 < zmnscpxj__> thx
02:04 < vasild> I have a reproducable py test case 
02:05 < zmnscpxj__> okay, please post on the github
02:05 < vasild> https://github.com/ElementsProject/lightning/blob/master/lightningd/closing_control.c#L115
02:06 < vasild> this code would only update channel->last_tx if the new tx is "better", but "better" translates to a lower fee
02:07 < vasild> and this never happens on l1 because during negotiation last_tx is the initial l2's offer with fee=1000 and all negotiation is happening between 1000 and 2000, so all transactions have higher fee than 1000
02:08 < zmnscpxj__> last updated 2 years ago.... hmmm.
02:09 < vasild> ok, I will dump all the info on a github issue, should be easy to fix once all the details have been grasped
02:10 < zmnscpxj__> Even before 2 years ago: https://github.com/ElementsProject/lightning/blob/a83ff83328695f4666cad1b390a1757872c0428a/lightningd/peer_control.c#L1427
02:16 < zmnscpxj__> Even older: https://github.com/ElementsProject/lightning/blob/b7680412e3b73ba95f372f637aac44017bfb4bcb/lightningd/peer_control.c#L1683
02:20 < zmnscpxj__> The code has been there since 2017... still digging
02:22 < zmnscpxj__> Seems to have been introduced here: https://github.com/ElementsProject/lightning/commit/2b7c091e70226ea714167347bdb3140283cd3fe0
02:33 < vasild> It has gone unnoticed because when the two nodes broadcast the different transactions simultaneiously sometimes the correct tx from l2 makes it first to the mempools and the lower one from l1 gets rejected. Even if the "wrong" one from l1 gets first it would eventually confirm.
02:33 < zmnscpxj__> yes, I think so too
02:34 < vasild> I wonder why bitcoind rejects the tx with the higher fee if it arrives second
02:34 < zmnscpxj__> The code doing this is pretty old, circa 2017 as well
02:34 < zmnscpxj__> that is the policy if the RBF flag is not set
02:34 < zmnscpxj__> which it is not, on current mutual closes
02:35 < vasild> I see, yes RBF is not set
02:35 < zmnscpxj__> FWIW it is a good way to test that Lightning implementations properly handle all forms of closes, including previously-rejected mutual closes due to fee negotiation
03:01 -!- lxer [~lx@ip5f5bf497.dynamic.kabel-deutschland.de] has joined #c-lightning
03:03 < vasild> zmnscpxj__: https://github.com/ElementsProject/lightning/issues/3549 During close sometimes a node would broadcast the wrong transaction
03:08 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Quit: Leaving]
03:15 < vasild> https://github.com/ElementsProject/lightning/blob/master/lightningd/closing_control.c#L88-L89 -- this comment is correct, but is not what the code does.
03:23 -!- Kostenko [~Kostenko@2001:8a0:728b:2300:9a3b:b84c:ca83:82dd] has quit [Read error: Connection reset by peer]
03:51 -!- Kostenko [~Kostenko@2001:8a0:728b:2300:9a3b:b84c:ca83:82dd] has joined #c-lightning
04:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
04:36 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
05:07 < m-schmoock> Do we want this feature?   https://github.com/ElementsProject/lightning/issues/3550
05:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
05:34 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning
05:35 < darosior> m-schmoock: At first I felt like it could be done with a shell loop, but decomission seems to do more than just closing the channels. Do you propose them as a plugin ?
05:36 < darosior> Also, all: I've made some progress with the FAQ draft. If someone has suggestions / corrections before I PR it.. https://github.com/ElementsProject/lightning/issues/3382
05:37 < m-schmoock> darosior: I propose this specifically not as a plugin
05:38 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
05:42 < m-schmoock> but alternatively we could go for a integrated plugin (like the pay.c) or even a plugin if theres reservations against having this as an integrated operation.
05:43 < m-schmoock> I just think this is a lifecycle and security relevant operation, so we want this in general and not optional
05:46 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
05:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:56 < vasild> darosior: wrt FAQ: "Are there any issues if my node changes it's IP address? What happens to the channels if it does?" and "Can I have two hosts with the same public key and different IP addresses, both online and operating at the same time?" may be good additions to the FAQ (asked here a few days ago by Tim Ho)
06:47 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
06:50 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
07:07 < darosior> vasild: Thanks !
07:22 -!- Amperture [~amp@65.79.129.113] has joined #c-lightning
07:46 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning
08:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
08:26 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning
09:01 -!- MasterdonX [~masterdon@165.231.253.164] has quit [Ping timeout: 272 seconds]
09:01 -!- masterdonx2 [~masterdon@178-175-148-4.static.as43289.net] has joined #c-lightning
10:22 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
10:38 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning
10:43 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 272 seconds]
10:48 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning
10:55 < vasild> yw :)
11:32 -!- celerycelery [4620008b@gateway/web/cgi-irc/kiwiirc.com/ip.70.32.0.139] has joined #c-lightning
11:33 -!- celerycelery [4620008b@gateway/web/cgi-irc/kiwiirc.com/ip.70.32.0.139] has quit [Remote host closed the connection]
11:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
11:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
12:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
12:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning
13:49 < fiatjaf> channel_flags : Bitfields indicating the direction of the channel and signaling various options concerning the channel. (BOLT #7).
13:50 < fiatjaf> this says it's a bitfield, so it should be 0 or 1, right?
13:50 < fiatjaf> however I get 0, 3, 4, 5
13:51 < fiatjaf> oh wait, it's like 8 bits, each one representing a feature?
13:54 < fiatjaf> hm
13:54 < fiatjaf> now I get it
13:56 < fiatjaf> but apparently that's not what I'm looking for
13:56 < fiatjaf> I want to know if a channel supports tlv or legacy payments
14:11 < ysangkok> fiatjaf: there is no "tlv payment". tlv is about message encoding
14:41 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning
14:58 -!- masterdonx2 [~masterdon@178-175-148-4.static.as43289.net] has quit [Read error: Connection reset by peer]
15:01 -!- MasterdonX [~masterdon@104.244.208.36] has joined #c-lightning
15:05 < fiatjaf> ysangkok: isn't basically the description of payment the thing that is encoded?
15:05 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
15:05 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
15:06 < ysangkok> the description was always a possible field in BOLT-11. i am not sure i understand the question
15:09 < fiatjaf> my question is how do I know what kind of message a channel accepts, tlv or legacy
15:21 -!- lxer [~lx@ip5f5bf497.dynamic.kabel-deutschland.de] has quit [Ping timeout: 258 seconds]
15:41 < ysangkok> it is a property of a node, not a channel, though. maybe c-lightning already shows it in the node list?
15:46 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:50 < willcl_ark> fiatjaf: I think it's a node announcement featurebit, see BOLT9 featurebits 8/9. Not sure if CL displays it externally somewhere though...
15:50 < willcl_ark> well, that's for the onion at least, I'm not sure what you mean by "tlv payment", AFAIK update_add_htlc message does not use TLV 
15:52 < fiatjaf> right, I want the onion
15:53 < willcl_ark> looks like that featurebit should also get set in the init (and optionally invoice) messages too
15:55 < willcl_ark> what are you trying to do with the info, if you don't mind sharing? CL should handle sending correct onion type automatically I think so just trying to understand the problem
16:05 < fiatjaf> I'm trying to hijack CL's getroute command to build my own custom routes
16:05 < fiatjaf> and it seems I must return "style": "tlv" or "style": "legacy" for each hop
16:05 < fiatjaf> when using the "rpc_command" plugin hook
16:06 < fiatjaf> I see "listnodes" returns a "features" string for each node
16:06 < fiatjaf> from the big list of nodes some of the common features values are "0a8a", "2200" and "28a2"
16:07 < fiatjaf> these translate to "101010001010", "10001000000000" and "10100010100010"
16:07 < fiatjaf> which make no sense to me
16:14 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
16:19 < willcl_ark> i see. I can't help you with that I don't think
16:20 < willcl_ark> I think you just read the binary  repr (big or little endian?) and each position indicates if the feature is on (1) or not (0), but not sure enough to say I'm afriad
16:37 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
16:39 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning
16:49 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
17:14 < fiatjaf> willcl_ark: thank you. I was trying to do exactly that in my gigantic naïvete, that's when I stopped because I was very confused
17:17 < fiatjaf> actually I think it makes sense now
17:19 < fiatjaf> I was reading it from right to left, but from left to right it looks better
17:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
17:25 < fiatjaf> but if that is correct then my poor knowledge of binary operators is failing me. 
17:39 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has joined #c-lightning
18:01 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has quit [Quit: Leaving]
18:02 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has joined #c-lightning
18:13 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
18:29 -!- Amperture [~amp@65.79.129.113] has quit [Remote host closed the connection]
18:52 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
19:46 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Read error: Connection reset by peer]
19:46 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
20:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
20:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning
20:28 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has quit [Quit: Leaving]
23:10 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
23:11 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
23:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
23:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
--- Log closed Thu Feb 27 00:00:06 2020