--- Day changed Fri Jan 25 2019 00:03 -!- apengdada [~apeng@unaffiliated/apengdada] has quit [Quit: leaving] 02:39 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 02:40 -!- apeng [~apeng@unaffiliated/apengdada] has joined #joinmarket 03:39 -!- apeng [~apeng@unaffiliated/apengdada] has quit [Remote host closed the connection] 03:53 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 03:54 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 05:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds] 06:37 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 06:38 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 06:48 -!- apeng [~apeng@unaffiliated/apengdada] has joined #joinmarket 07:07 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 272 seconds] 07:23 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 08:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket 08:28 -!- GitHub146 [GitHub146@gateway/service/github.com/x-ysxucjqwoigwciiw] has joined #joinmarket 08:28 < GitHub146> [joinmarket-clientserver] AdamISZ opened pull request #315: Check unaltered sequence, locktime (payjoin) (master...payjoin-check-sequence) https://git.io/fhoSo 08:28 -!- GitHub146 [GitHub146@gateway/service/github.com/x-ysxucjqwoigwciiw] has left #joinmarket [] 08:30 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket 08:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 08:35 -!- lukedashjr is now known as luke-jr 08:52 < waxwing> arubi, just general impression but it looks like it's getting harder and harder for the tests to pass. is there a simple option to just do say 1 test suite (maybe 1 environment) except for a full run that's manually startable? something like that? 08:53 < waxwing> today we have: apt-get install failed 08:53 < waxwing> $ cat ${TRAVIS_HOME}/apt-get-update.log 08:53 < waxwing> Get:1 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial InRelease [247 kB] 08:53 < waxwing> Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [109 kB] 08:53 < waxwing> Get:3 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial InRelease [17.5 kB] 08:53 < waxwing> Get:4 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB] 08:53 < waxwing> Get:5 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB] 08:53 < waxwing> Get:6 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main Sources [1,103 kB] 08:53 < waxwing> Get:7 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/restricted Sources [5,179 B] 08:53 < waxwing> Get:8 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/universe Sources [9,802 kB] 08:53 < waxwing> Get:9 http://security.ubuntu.com/ubuntu xenial-security/main Sources [175 kB] 08:53 < waxwing> Get:10 http://security.ubuntu.com/ubuntu xenial-security/restricted Sources [2,243 B] 08:53 < waxwing> Get:11 http://security.ubuntu.com/ubuntu xenial-security/universe Sources [116 kB] 08:53 < waxwing> Get:12 http://security.ubuntu.com/ubuntu xenial-security/multiverse Sources [3,513 B] 08:53 < waxwing> Get:13 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [767 kB] 08:53 < waxwing> Get:14 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [649 kB] 08:53 < waxwing> Get:15 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [351 kB] 08:53 < waxwing> Get:16 http://security.ubuntu.com/ubuntu xenial-security/restricted amd64 Packages [12.7 kB] 08:53 < waxwing> Get:17 http://security.ubuntu.com/ubuntu xenial-security/restricted i386 Packages [12.7 kB] 08:53 < waxwing> Get:18 http://security.ubuntu.com/ubuntu xenial-security/restricted Translation-en [2,204 B] 08:53 < waxwing> Get:19 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/multiverse Sources [215 kB] 08:53 < waxwing> Get:20 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 Packages [527 kB] 08:53 < waxwing> Get:21 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 Packages [1,558 kB] 08:53 < waxwing> Get:22 http://security.ubuntu.com/ubuntu xenial-security/universe i386 Packages [457 kB] 08:53 < waxwing> Get:23 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main i386 Packages [1,552 kB] 08:53 < waxwing> Get:24 http://security.ubuntu.com/ubuntu xenial-security/universe Translation-en [219 kB] 08:53 < waxwing> Get:25 http://security.ubuntu.com/ubuntu xenial-security/multiverse amd64 Packages [6,119 B] 08:53 < waxwing> Get:26 http://security.ubuntu.com/ubuntu xenial-security/multiverse i386 Packages [6,295 B] 08:53 < waxwing> Get:27 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main Translation-en [799 kB] 08:53 < waxwing> Get:28 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/restricted amd64 Packages [14.1 kB] 08:53 < waxwing> Get:29 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/restricted i386 Packages [14.5 kB] 08:53 < waxwing> Get:30 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/restricted Translation-en [3,019 B] 08:53 < waxwing> Get:31 http://security.ubuntu.com/ubuntu xenial-security/multiverse Translation-en [2,699 B] 08:54 < waxwing> Get:32 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages [9,827 kB] 08:54 < waxwing> Get:33 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/universe i386 Packages [9,804 kB] 08:54 < waxwing> Get:34 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/universe Translation-en [6,256 kB] 08:54 < waxwing> Get:35 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/multiverse amd64 Packages [176 kB] 08:54 < waxwing> Get:36 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/multiverse i386 Packages [172 kB] 08:54 < waxwing> Get:37 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/multiverse Translation-en [131 kB] 08:54 < waxwing> Get:38 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main Sources [415 kB] 08:54 < waxwing> Get:39 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/restricted Sources [2,684 B] 08:54 < waxwing> Get:40 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/universe Sources [303 kB] 08:54 < waxwing> Get:41 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/multiverse Sources [9,420 B] 08:54 < waxwing> Get:42 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [1,166 kB] 08:54 < waxwing> Get:43 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [1,027 kB] 08:54 < waxwing> Get:44 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main Translation-en [516 kB] 08:54 < waxwing> Get:45 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/restricted amd64 Packages [13.1 kB] 08:54 < waxwing> Get:46 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/restricted i386 Packages [13.1 kB] 08:54 < waxwing> Get:47 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/restricted Translation-en [2,334 B] 08:54 < waxwing> Get:48 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [929 kB] 08:54 < waxwing> Get:49 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [850 kB] 08:54 < waxwing> Get:50 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/universe Translation-en [402 kB] 08:54 < waxwing> Get:51 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 Packages [19.1 kB] 08:54 < waxwing> Get:52 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/multiverse i386 Packages [17.9 kB] 08:54 < waxwing> Get:53 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/multiverse Translation-en [8,978 B] 08:54 < waxwing> Get:54 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/main Sources [5,073 B] 08:54 < waxwing> Get:55 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/universe Sources [7,237 B] 08:54 < waxwing> Get:56 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages [7,942 B] 08:54 < waxwing> Get:57 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/main i386 Packages [7,942 B] 08:55 < waxwing> Get:58 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/main Translation-en [4,571 B] 08:55 < waxwing> Get:59 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 Packages [8,532 B] 08:55 < waxwing> Get:60 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/universe i386 Packages [8,172 B] 08:55 < waxwing> Get:61 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports/universe Translation-en [4,275 B] 08:55 < waxwing> Ign:62 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main amd64 Packages 08:55 < waxwing> Ign:63 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main i386 Packages 08:55 < waxwing> Ign:64 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main Translation-en 08:55 < waxwing> Ign:62 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main amd64 Packages 08:55 < waxwing> Ign:63 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main i386 Packages 08:55 < waxwing> Ign:64 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main Translation-en 08:55 < waxwing> Ign:62 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main amd64 Packages 08:55 < waxwing> Ign:63 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main i386 Packages 08:55 < waxwing> Ign:64 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main Translation-en 08:55 < waxwing> Err:62 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main amd64 Packages 08:55 < waxwing> Could not connect to ppa.launchpad.net:80 (91.189.95.83), connection timed out 08:55 < waxwing> Err:63 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main i386 Packages 08:55 < waxwing> Unable to connect to ppa.launchpad.net:http: 08:55 < waxwing> Err:64 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu xenial/main Translation-en 08:55 < waxwing> Unable to connect to ppa.launchpad.net:http: 08:55 < waxwing> Get:65 http://apt.postgresql.org/pub/repos/apt xenial-pgdg InRelease [51.3 kB] 08:55 < waxwing> Get:66 http://apt.postgresql.org/pub/repos/apt xenial-pgdg/main amd64 Packages [198 kB] 08:55 < waxwing> Get:67 http://apt.postgresql.org/pub/repos/apt xenial-pgdg/main i386 Packages [198 kB] 08:55 < waxwing> Fetched 51.5 MB in 1min 1s (836 kB/s) 08:55 < waxwing> Reading package lists... 08:55 < waxwing> W: Failed to fetch http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu/dists/xenial/main/binary-amd64/Packages Could not connect to ppa.launchpad.net:80 (91.189.95.83), connection timed out 08:55 < waxwing> W: Failed to fetch http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu/dists/xenial/main/binary-i386/Packages Unable to connect to ppa.launchpad.net:http: 08:56 < waxwing> W: Failed to fetch http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu/dists/xenial/main/i18n/Translation-en Unable to connect to ppa.launchpad.net:http: 08:56 < waxwing> W: Some index files failed to download. They have been ignored, or old ones used instead. 08:56 < waxwing> The command "sudo -E apt-get -yq --no-install-suggests --no-install-recommends $(travis_apt_get_options) install bitcoind" failed and exited with 100 during . 08:56 < waxwing> wow sorry for that, heh 09:44 < arubi> yea waxwing I already started working on the patch to allow that but have been mostly afk on the last few days. I will be around tomorrow morning most likely and hopefully be able to PR it at some point too 09:46 < d3spwn> didnt matt corallo say he didnt support the ppa anymore? 09:48 < arubi> oh he did? I know there was a thread about warning about ubuntu and not treating it as a recommended os, but wasn't sure if the ppa is going away 09:48 < waxwing> arubi, right. thanks for that. take your time. 09:48 < arubi> nw 09:48 < waxwing> i don't think the issue was about the ppa; but for sure there was an issue with ubuntu. so maybe. 09:49 < d3spwn> i'm not saying thats the reason, just noticed the coincidence 09:53 < arubi> in any case I think somebody will have to keep supporting the ppa with either security updates only and just so squatters don't get a hold of it 09:53 < d3spwn> debian sid had a bitcoind package 09:55 < arubi> nice. but yea for normal\new users sid is probably too volatile as an os 09:55 -!- apeng [~apeng@unaffiliated/apengdada] has quit [Quit: leaving] 10:18 -!- GitHub100 [GitHub100@gateway/service/github.com/x-kbrdnkckvemcnmeq] has joined #joinmarket 10:18 < GitHub100> [joinmarket-clientserver] AdamISZ opened pull request #316: graceful sender-side timeout of PayJoin if fails (master...payjoin-timeout-sender) https://git.io/fhoNH 10:18 -!- GitHub100 [GitHub100@gateway/service/github.com/x-kbrdnkckvemcnmeq] has left #joinmarket [] 11:37 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 250 seconds] 11:52 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 12:01 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket 13:26 -!- kybl [~ales@ip-89-239-24-188.mameradirychlost.cz] has quit [Quit: Leaving.] 13:26 -!- kybl [~ales@ip-89-239-24-188.mameradirychlost.cz] has joined #joinmarket 13:27 -!- kybl [~ales@ip-89-239-24-188.mameradirychlost.cz] has quit [Client Quit] 13:57 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] Thinking about issue #105, in which a JM bot crashes because it cant send a PM to a specific counterparty, because the IRC server it wanted to send it to just disconnected (even if other IRC servers are connected). 13:57 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] Just to see whether I am on the right track. This is the piece which might be modified to fix this: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmdaemon/jmdaemon/message_channel.py#L255-L263 13:57 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] could I just check other MCs for the same nick in case the expected MC fails? 14:03 < belcher_> good job on noticing the agora 13 nick characters thing 14:03 < waxwing> alexcato gonna have to think about this :) 14:03 < waxwing> yeah that was galli zoltan 14:03 < belcher_> im just reading up in the log from the last few days 14:03 < waxwing> alexcato, just double checking, you did read my comment from when i thought i knew what caused it ? 14:04 < waxwing> it was some time ago, so ... (and even more absurdly long ago when i wrote that chunk of code ... logic error? umm..) 14:04 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] not sure, where was that comment? IRC? 14:05 < waxwing> on the issue, sorry. 14:05 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] it seems to happen more often than sporadic lately, if you see issues #311 and #313 . I know that for myself, agora was kind of unstable and it directly crashed after user-confirming the sendpayment amounts. 14:06 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] i'll check the issue again, think i read it but unsure now 14:07 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] yeah, i read that. But if another message channel with the same message recipient exists, it shouldnt matter what kind of JM bot was causing the exception - fixing it should always be falling back to the other available message channel, right? 14:08 < waxwing> yes that's the plan 14:09 < waxwing> but note that that particular function behaves differently if it's called with a specific mc passed as argument. 14:09 < waxwing> (and that's the branch where we hvae the bug) 14:09 < waxwing> i'm trying to remember the logic, there was some logic (actually i think you were involved in debugging this code back in the day when we were first testing it) 14:10 < waxwing> i.e some logic to why in some cases it was preferred to stick to/fix a particular mc for one conversation. 14:11 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] phew, i wish i could remember. I remember the testing, but no specifics any more 14:13 < waxwing> yes. it looks to me like what happened is this: in the JMCS code, to support this, there is a process of passing a request for a message signature back to the client, then waiting for the response before sending the privmsg 14:13 < waxwing> (see MessageChannelCollection.prepare_privmsg) 14:14 < waxwing> and it appears that this always fixes the mc value (hostid). so privmsg always gets called with a specific hostid value. 14:14 < waxwing> but what i recall, anyway, is that once the privmsg conversation starts, the mc chosen for one side of the conversation is fixed for the duration of the conversation. 14:15 < waxwing> and i remember that this was the case from the start, even when it was on JM not JMCS. i can't remember why i felt the need for it to be like that, but i remember discussing it here at the time. 14:15 < waxwing> basically saying 'yeah i know this is suboptimal but we have almost all the advantages, just not quite the complete multiplexing even during a tx negotiation' 14:15 < waxwing> of course this doesn't mean there isn't a bug to be fixed, it doesn't need to crash. but just trying to remember the parameters. 14:18 < waxwing> alexcato a possible cause for it triggering more now: we have 3 channels. if one is down (e.g. agora) then that code line might get triggered because the actual value is 2. 14:18 < waxwing> in any case why did i think it was a "logic error" for it not to be 1? atm it beats me. 14:19 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] ah, i thought about that but for reasons unclear to me now, i thought it was 0 channels on agora failure 14:19 < waxwing> oh hang on i take all that back. it's filtering on hostid. 14:19 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] so basically, the fix might be: replace '!= 1" with '<1' 14:20 < waxwing> so the list shouldn't have more than 1 element with the exact same hostid (the network name). 14:21 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] alright, makes sense. Couldnt the stall detector logic be used for this? Basically, instead of crashing, restart like the stall detector does? I'd have to check out how it does that, but in principle that should work then? 14:22 < waxwing> maybe but let's try to get this clear first. 14:22 < waxwing> so the "two tries" thing is really just allowing the mc parameter to be either an actual MessageChannel object, or a hostid string instead. 14:23 < waxwing> so as i understand it, we're actually exclusively using the latter in normal operations because we're coming in via the msg signature client->daemon response. 14:23 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] i believe i can reproduce this crash half-way reliably, so i can test different approaches and add/get some useful debugging output 14:24 < waxwing> so ... if there are no available channels, we can't send the privmsg. so what do we do. hmm. this is back to the comment i made "it might be tricky because it might depend on the bot". 14:24 < waxwing> i think just keep it simple, reproduce line 174 14:24 < waxwing> 274 14:25 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] well, there are available channels - at least when I encountered this issue, only agora failed while cgan/darkscience were working without problem 14:25 < waxwing> ah. well in that case yes there is a bug. ok i'll keep thinking. 14:25 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] so this feels like the code already decided to send a PM on agora, but then this one failed 14:25 < waxwing> oh; yes that's back to my earlier point. the code was not designed to switch *during the transaction build conversation*. 14:25 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] see issue #313... theres a 5 sec window between confirming the sendpayment parameters and the crash 14:25 < waxwing> one direction of convo is fixed on server A, if it starts successfully on server A. 14:26 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] i guess it decided to use agora before confirming 14:26 < waxwing> ok i'll look at that again. 14:27 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] the disconnect did happen while the code was waiting for user feedback 14:27 < waxwing> so for now i think min is reproduce line 274. it's a separate question as to whether switching during processing can be made to work easily. 14:27 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] then crashed when the user did finally give feedback... 14:27 < waxwing> it's important to fix that because it can break makers too (previously it was *extremely* rare, but it can happen. 14:28 < waxwing> re-architecting other stuff would be a harder/longer task. 14:28 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 274? At least mine crashed at 263 14:29 < waxwing> i meant do the same as on line 274. 14:29 < waxwing> replace the exception raise with that. 14:29 < waxwing> it's the same scenario, for now. 14:30 < waxwing> again, we can in future probably improve by allowing the multiplexing *durign tx negotiation* (currently it's per-conversation-side fixed to one mc during that, but not before or after) 14:30 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] ah, ic. Will edit debugging output and reproduce. Will take a few min 14:30 < waxwing> and i don't remember why i did that, but i do remember discussing it here and saying it was a fairly minor limitation. perhaps right now today agora is not in a state to allow it. 14:31 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] i think multiplexing during tx negotiation should not be necessary. At least my issue crashed *before the first message was sent from taker to maker* 14:31 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] it crashed on trying to send exactly that: the first message 14:31 < waxwing> hmm. it was the !fill, right? 14:32 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] flow was like this: sendpayment, select manual offers. (basically, all communication at this point from the taker was !orderbook). Then wait for user confirmation. Then it crashes when it tried to initiate the CJ with the selected makers 14:32 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] so crashed on first mesage 14:32 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] yes, !fill was the one it tried to send 14:32 < waxwing> yes you're right. so ... thinking again. 14:33 < waxwing> so this is reproducible right now, with 3 mchans configured? 14:33 < waxwing> if so i can have a look at it too 14:36 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] unsure about reliability, on 3 tries it failed twice yesterday. But i believe there might be a developer-driven cause: i already had a connection to agora open on a maker and this IRC client. So starting an additional taker made it 3 connections. I guess agora just kicks me reliably after around 1-3 min 14:37 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] so this might not actually be a big deal for normal JM users. But just a theory at this point. Will test right now 14:37 < waxwing> huh, interesting thought. i've seen that kind of thing on IRC servers before. can be quite bewildering. 14:38 < waxwing> yep i just reproduced it using all 3. i don't have any other bots running. 14:42 < waxwing> yeah agora seems to be the culprit, i hope reproducibly. works without. 14:42 < waxwing> since it's currently default it may well block users right now. 14:42 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] alright, so that theory is out of the window then. But something that needs a fix 14:43 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] i've added some log output, hope to gain some insights. Hope i can reproduce 14:46 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] yup, crashed. New log output just before the exception: 14:46 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-25 23:45:43,948 [DEBUG] Failed to send message to: J5Q31zHZReJeaghO 14:46 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-25 23:45:43,948 [DEBUG] len(matching_channels) = 0 14:46 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-25 23:45:43,948 [DEBUG] matching_channels = [] 14:47 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] problem is also observable now: agora just kicks me at some point, still waiting for user input. But the code does not check for available message channels when the user input is done 14:49 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] though that would not really fix it. The disconnect seems to happen about 1 minute after joining. So evne if it did start and could get the first messages through, it couldnt finish in that time 14:50 < waxwing> i think we can try to finesse it better later, for now i think the more important thing would be to patch it up so it doesn't crash, specifically for makers; and for takers it would be nice if a log message indicated what connection had failed. Unfortunately there is a problem with that! 14:50 < waxwing> (the latter, giving information to user) 14:51 < waxwing> well, to be clearer: not a big problem, unless you run the daemon separately. at the very least we can simply print out the message that hostid X is not available, and it should tell them. 14:52 < waxwing> so perhaps you could just push out a PR with that, i think it's good enough for now. 14:53 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] will do that, but have a different idea as well. Couldnt we just use exactly what line 275 does, and only raise that exception if that fails as well? 14:53 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] sorry, 271 i mean 14:54 < waxwing> huh, i've just realised something quite amusing. 14:54 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] and if you did reply, sorry, my IRC client had a disconnect as well right now 14:54 < waxwing> look at the @check_privmsg decorator :) 14:59 < waxwing> but anyway, in response to your question, not only do i agree that we could do 271, but we could perhaps simply move that to the start of the function. 15:00 < waxwing> that *would* violate my earlier statement that "it's fixed for the tx negotiation" but again, for now, i don't remember what the reason for that was. 15:00 < waxwing> so we would at least need to think it through and test carefully, which is what's bothering me. 15:01 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] have to read up on function wrappers, never dealt with that before 15:02 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] wondering why it defaults to Agora as preferred message channel though - might that be because "A"gora is > "C"gan > "D"arkscience ? 15:02 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] i can reliably reproduce right now. So testing, at least the bad case, shouldnt be a problem. 15:04 < waxwing> oh, note the comment here: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmdaemon/jmdaemon/message_channel.py#L532-L541 15:05 < waxwing> it reminds me a bit. there was some reasoning behind it. again, to say what i said before, i think we should PR a simple "this doesn't crash" plus a print message for now. making it better i think should be deferred because it's not going to be trivial. 15:07 < waxwing> fwiw i don't think it's 100% repeatable; my second try with all 3 did not trigger it. 15:09 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] yeah 15:09 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] and i'm confused. This error message is from the decorator: 15:09 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-25 23:54:00,519 [WARNING] Couldn't find a route to send privmsg 15:09 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-25 23:54:00,519 [WARNING] For counterparty: J5A6dTBB6xEJmSVa 15:09 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] but this from my added logging just before the crash: 15:09 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-25 23:54:00,522 [DEBUG] Failed to send message to: J5F3oXCLMQUkZotb 15:10 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] shouldnt that be the same counterparty? 15:10 < waxwing> Maybe you're talking to more than one counterparty over Agora? 15:11 < waxwing> my 3rd try triggered the crash again, i can see Agora 'on disconnect fired' just before. for whatever reason, a bit strange but there we are. 15:11 < waxwing> yeah the 'couldn't find a route' at least doesn't crash. i think the PR should also remove agora from the defaults. 15:11 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] ah, i see. The one in the wrapper was the 1st selected maker, then the one from my debug message was the 2nd selected one 15:12 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] for the 1st maker, the code seems not to reach the exception 15:13 < waxwing> it presumably depends on the exact timing of the disconnect, i guess 15:13 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] alright, so i will prepare a PR to remove agora first 15:14 < waxwing> k 15:14 < undeath> is agora so unrealiable? 15:15 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] then i believe so. Only seems to be an issue right after joining. After reconnecting, i do not see that issue any more (my maker has no agora disconnects) 15:15 < waxwing> don't know but it seems to be disconnecting as the conversation starts. admittedly we're both testing with -P so a meaningful delay between !orderbook and fill. maybe it doesn't happen without that, shrug. 15:15 < waxwing> and can't reproduce any similar issue without agora, right now, it seems. 15:16 < undeath> can you reproduce the problem when removing one of the other servers? 15:17 < waxwing> haven't tried on my end. 15:17 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] i will try 15:20 -!- GitHub17 [GitHub17@gateway/service/github.com/x-lhkgrblilesuiweo] has joined #joinmarket 15:20 < GitHub17> [joinmarket-clientserver] AlexCato opened pull request #317: Remove agora from default IRC configuration (master...patch-6) https://git.io/fhKnN 15:20 -!- GitHub17 [GitHub17@gateway/service/github.com/x-lhkgrblilesuiweo] has left #joinmarket [] 15:20 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] PR submitted, but let me test the idea by undeath before merging 15:22 < waxwing> right but we do need to replace that exception with a print and return ... shouldnt be a crash condition for long running bots. 15:22 < waxwing> anyway thanks, noted 15:24 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] try 1: seems to have recovered and tried the other server, even though connection to agora lost 15:24 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] about the connection loss: is there a keepalive-message to the IRC server that is *not* being sent while waiting for user feedback or something? 15:25 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] The code seems to recover. 2nd try: it again automatically switched to CgAN when only agora & cgan were activated 15:26 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] one last try. 15:28 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] alright, the code recovers. This part does it: 15:29 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmdaemon/jmdaemon/message_channel.py#L146 15:29 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] thats the message i see. Now i'm wondering why that works with two, but not three IRC servers 15:30 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] because the "On disconnect fired" is directly *after* the "dynamically switching" log entry 15:33 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] Output of this auto-recovering, when using only 2 IRC servers (and one fails): 15:33 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-26 00:28:06,725 [INFO] INFO:Commitment sourced OK 15:33 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-26 00:28:06,726 [DEBUG] Dynamically switching: J5E1KRK4L5hUsvWe to: ('aldfqlbwtsagq2gy.onion', 6698) 15:33 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] 2019-01-26 00:28:06,727 [DEBUG] On disconnect fired, nicks_seen is now: {: set(), : {'J55KShE4KJTQpJk8', 'J58fg9xAae5MQVaB', 'J5AcJEkqUSJJMKco', 'J543qEGKrz6HEJ6W', 'J5zgFwWxsqHxji1O', 'J57d3oK3NwBmojzs', 15:33 < AgoraRelay> 'J542jLBDCh5sVoTf' (......) 15:33 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] and then many successful privmsg on CgAn with the !fill messages 15:35 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] ignore that, of course it is that way --> because the "On disconnect fired" is directly *after* the "dynamically switching" log entry 15:56 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] debugging progress: something in flush_nicks is not working. This line https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmdaemon/jmdaemon/message_channel.py#L145 seems not to trigger, even though it should. 15:57 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] This function is executed *before* the exception. And if it worked, the exception would be avoided 15:57 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] but even though some makers are on both agora & cgan, it never triggers this line 145 (the dynamic change). But i see it reaches line 144 for that exact nick. 15:59 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] strangely enough, this works fine with 2 IRCs (when one fails). But it does not work fine with 3 IRCs (when one fails) 15:59 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] this should be simple to see whats wrong here, but I fail at doing just that ;( 16:40 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3] 16:52 -!- GitHub99 [GitHub99@gateway/service/github.com/x-jjwsraeevwbmhrmc] has joined #joinmarket 16:52 < GitHub99> [joinmarket-clientserver] AlexCato opened pull request #318: Do not raise exception when privmsg fails (master...patch-7) https://git.io/fhK8U 16:52 -!- GitHub99 [GitHub99@gateway/service/github.com/x-jjwsraeevwbmhrmc] has left #joinmarket [] 17:07 -!- AgoraRelay [~jmrelayfn@p5DE4AEC4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 17:14 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 17:17 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 17:22 -!- AgoraRelay [~jmrelayfn@p5DE4AD84.dip0.t-ipconnect.de] has joined #joinmarket 17:26 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexCato] for a summary of what we've found and the two quick mitigation PRs, please see https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/105 . 18:03 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:06 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:06 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:11 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:14 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:16 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:18 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:21 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:25 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:28 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:31 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:33 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:35 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:37 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:39 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:41 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:43 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 18:45 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 18:47 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 19:03 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 19:14 -!- grubles [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection] 19:35 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket 20:07 -!- grubles [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection] 20:48 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket 22:31 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 268 seconds] 23:49 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket