--- Day changed Sat Jul 07 2018 00:17 < waxwing> so is the consensus just to go with "let it continuously attempt to reconnect"? i'm not averse (although it might take a while to figure out the right way to do it; irc stuff is annoying from the testing point of view) 00:18 < waxwing> well not "let it" but "code it to ..." 00:34 -!- wordacc [~Instantbi@115.164.76.172] has joined #joinmarket 01:30 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 01:43 -!- Tommy_ [4c599ccf@gateway/web/freenode/ip.76.89.156.207] has joined #joinmarket 01:43 -!- Tommy_ is now known as Guest37928 02:15 -!- Guest37928 [4c599ccf@gateway/web/freenode/ip.76.89.156.207] has quit [Ping timeout: 252 seconds] 02:32 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket 03:24 -!- MaxSan [~user@185.156.175.35] has joined #joinmarket 03:27 -!- MaxSan [~user@185.156.175.35] has quit [Remote host closed the connection] 03:28 < AgoraRelay> [agora-irc/CatoAlex] dont think reconnect is necessary. Just try to rename itsself imho... or is that more complicated to do? 04:18 < arubi> lol turns out piqure will ban you for posting joinmarket.me/blog links :) 04:19 < arubi> it has to be a new rule. I'm sure I posted a link before 05:24 < belcher_> waxwing: ah ok, i didnt watch the talk yet 05:24 < belcher_> ty for the correction 05:49 < undeath> working on PR #104, does someone have an idea why bitcoind does this? https://travis-ci.org/undeath/joinmarket-clientserver/jobs/401206634#L2159 05:49 < undeath> error pushing = -26 16: bad-txns-in-belowout 05:50 < undeath> the weird thing is, this is a parametrized test and one iteration works while the other doesn't 05:51 < undeath> in contrast, when running the test locally with 0.15.1 bitcoind complains about "error pushing = -26 66: min relay fee not met" sometimes 05:52 < undeath> or even "error pushing = -26 256: absurdly-high-fee" 05:53 < undeath> fee in the test is set to 9000 sat right now, but I've tried with values between 1000 and 10000 and seemingly randomly get one of those three errors (or don't) 06:14 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket 06:44 < arubi> undeath, re. bad-txns-in-belowout error, I see the test hard codes an index 0 for the input. maybe 1.0 gets sent to index 1 instead and the amount in index 0 is less than 0.99991000, which causes validation to fail even before the script is executed (too few funds in utxo) 06:44 < arubi> might explain why it happens intermediately. sometimes it does end up at index 0 and passes 06:46 < undeath> oh, I though it's a 1-in 1-out tx 06:46 < undeath> that could explain things 06:46 < undeath> will look into that, thanks 06:46 < arubi> cheers 07:02 < undeath> looks like you were spot-on, arubi! thanks :) 07:03 < arubi> nice :) 07:28 < waxwing> catoalex sorry was on road, yes, that makes sense i think. will have a go today/tomorrow. 08:40 -!- wordacc [~Instantbi@115.164.76.172] has quit [Quit: Instantbird 1.5 -- http://www.instantbird.com] 08:41 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket 08:55 < waxwing> interesting, tested it against my own uname on cgan; if i change altercollidedNick to just keep trying the same nick, it tries every ~ 1 second or so, and when i quit the original user, it immediately grabs it (no delay, certainly not 120s) 08:55 < waxwing> that was cgan, will try anarplex/agora now 08:56 < belcher> the 120s thing is ping timeout, which would happen if your tcp peer disappeared 08:57 < belcher> when you do quit it does close() and sends tcp RST, so the server immediately knows the nick is available 08:57 < waxwing> ah right yes i see what you're saying there. hmm. 08:58 < waxwing> so simulate by crashing the script i guess? 08:59 < belcher> that wont work, the OS will send the tcp RST packet instead 08:59 < belcher> the only way i know is to pull the plug on your ethernet cable :p 09:00 < waxwing> lol 09:00 < waxwing> who ever came up with the idea of layered protocols, what a dumb idea that was 09:01 < belcher> you know that idea of leaky abstractions? every abstraction (layered protocols are one kind) is leaky 09:01 < belcher> leaky means it leaks information about the underlying implementation 09:02 < belcher> like if you have a 100x100 grid of integers, traversing them in the x direction could be slower than in the y direction, because memory in a computer isnt actually laid out that way 09:02 < waxwing> ok so the retry rate for the collided nick is just coming from lineRate (which is set at 1.3 s due to the throttling limitations) 09:03 < belcher> but for this joinmarket irc, i dont think it matters, we could just have it try every 5 seconds or so until it succeeds 09:03 < waxwing> yeah 1.3s is a bit antisocially fast 09:15 < belcher> could i check i understand the whole problem again? is it that takers send messages to makers but those makers may have previously ping timedout and rejoined with a new nick, but the taker sends to the old nick so gets no reply 09:19 < AgoraRelay> [agora-irc/CatoAlex] takers send messages to the sanitized name, instead of its actual one. So if there's makers with "_" in the name, they will never get a message, because makers try to send it to their nick without the _ 09:20 < AgoraRelay> [agora-irc/CatoAlex] so a maker with the "backup" name with the _ appended will never be included in any joins 09:20 < AgoraRelay> [agora-irc/CatoAlex] belcher/waxwing: wouldnt 60s be a better than 1.3/5, as this is not a timecritical thing to do anyways? Might be nicer to the irc server guys 09:20 < waxwing> right. with the important caveat that you must consider multiple message channels; if the "_" is appended on one channel but not another it may be that the message channel has been switched (if there was a disconnect) 09:21 < waxwing> catoalex yeah possibly. latest data i noticed; agora boots you if you don't succeed in setting your nick after about 60 seconds. if i'm reading this right. 09:21 < AgoraRelay> [agora-irc/CatoAlex] but the nick is set, even if it's one with _ in the end, right? 09:22 < AgoraRelay> [agora-irc/CatoAlex] or how might those 60s affect JM? 09:22 < waxwing> i'm doing a test where i own "waxwing" and i'm seeing what happens if i run a bot trying to claim it. (context) 09:22 < waxwing> we were discussing above 09:22 < belcher> oh 09:23 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 09:23 < waxwing> but that "boot" doesn't really matter as it's an automatically reconnecting irc protocol factory 09:23 < waxwing> iirc it has an exponential backoff 09:23 < belcher> what if we had the taker always send messages to the actual nick 09:23 < AgoraRelay> [agora-irc/CatoAlex] gotta run now, back later. But will read everything 09:23 < waxwing> ok agora works the same as cgan. once i quit, it connects OK. 09:23 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket 09:24 < waxwing> belcher, it's not really maker/taker specific, at least not in any sense i can think of 09:24 < belcher> "peer" instead 09:24 < waxwing> that's the way it works now; when you receive a message you strip trailing chars to do the signature checking (authenticating, which is needed for multiple message channels otherwise people could "squat" your nick on the other one and screw things up, theoretically) 09:24 < belcher> always send irc messages to the actual peer nick instead of the sanitized one 09:25 < waxwing> yeah that's something that was discussed yesterday, but it does imply keeping track of a mapping between sanitized or normalized, and non-normalized 09:25 < waxwing> because there are multiple MCs, the MC collection is controlling and deciding which MC to send the message on (the idea was to handle connection drops) 09:26 < waxwing> and at that higher level there is just the normalized (pubkey hash) nick, which is used to authenticate against. 09:26 < waxwing> we were discussing the various scenarios around that a day or two back and then people gravitated towards saying "meh, just keep retrying until you get the real nick". 09:27 < waxwing> generally because we dont' register, we can always get squatted, whatever we do, at least the signing prevents shenanigans 09:28 < belcher> what of the idea that if peers have been disconnected then they make a new keypair for authentication and change all their nicks to that on every MC 09:29 < waxwing> yeah maybe. that's a 100% abandoning of trying to complete a tx with a connection dropout though 09:29 < waxwing> i think generally that doesn't work today but it might in certain situations 09:30 < belcher> oh right, so if the connection drops during a coinjoin 09:30 < waxwing> because the switch from a disconnected MC to a connected one is dynamic 09:31 < waxwing> also that'll be harder to code (not that i've thought about it much) 09:32 < waxwing> i'll just make this change for now i think because it should work, and it at least will stop this scenario: a maker maybe has only one MC working, then collides nick, and just goes "silent" without realising it. pretty crappy that it was like that, which is why i'm focused on getting a bugfix out. 09:32 < waxwing> i grepped my logs and saw i'd had collisions like about once a month last year or so; no idea if this ever affected me but i know i basically always have 2 MCs so i'd guess not, but i don't actually know. 09:34 < waxwing> also i'll make sure it's a WARNING level message so everyone will see it if it's happening. it'll only really affect makers i guess in practice. 09:45 -!- viasil [~viasil@185.217.171.21] has quit [Ping timeout: 248 seconds] 09:48 -!- viasil [~viasil@185.217.171.21] has joined #joinmarket 09:52 < waxwing> k, going with 10s to split the difference 09:59 < AgoraRelay> [agora-irc/CatoAlex] there's a few countries in which the ISPs force a reconnect once every 24hrs, so you will notice a few of the makers have that dropped connection problem at least once a day; this is how i noticed 10:00 < AgoraRelay> [agora-irc/CatoAlex] 2 MCs only help if the taker has 2 MCs configured as well; most do, but there's a non-negligible amount of takers that only are seen on one of the IRCs 10:00 < AgoraRelay> [agora-irc/CatoAlex] also, that 24hr-isp-disconnect makes both MCs fail at the same time, therefor also killing the backup solution 10:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 10:03 < grubles> what's the rationale for forcing a reconnect? 10:04 < arubi> "don't run servers on our infrastructure unless you purchase a more expensive program"? 10:05 < grubles> well that would piss off gamers too i would think 10:05 < grubles> or netflix watchers, etc 10:06 < arubi> yea it doesn't sound very friendly. maybe these are extra cheap isps that try to market for email\news readers 10:06 < arubi> like, low speed, bad QoS, something gamers wouldn't use anyway 10:07 < waxwing> sorry 'killing the backup solution'? you mean having 2 mcs right? not killing the idea of having the attempt to reclaim the nick? 10:07 < waxwing> updated the PR (it won't show here, but changed the code as per the above) 10:07 < AgoraRelay> [agora-irc/CatoAlex] in germany for example, thats the default ISP behavior for *all* ISPs 10:07 < AgoraRelay> [agora-irc/CatoAlex] for consumer connections 10:08 < AgoraRelay> [agora-irc/CatoAlex] but theres an upside to that: changes the IP address every time as well 10:08 < AgoraRelay> [agora-irc/CatoAlex] --> better privacy 10:08 < grubles> ok but what is the reasoning behind it though 10:08 < grubles> i guess most consumers dont need 99.99999% uptime 10:08 < AgoraRelay> [agora-irc/CatoAlex] no idea tbh. My best guess would be to make server hosting unattractive 10:10 < AgoraRelay> [agora-irc/CatoAlex] > waxwing] sorry 'killing the backup solution'? you mean having 2 mcs right? not killing the idea of having the attempt to reclaim the nick? 10:10 < AgoraRelay> [agora-irc/CatoAlex] by that i meant: that isp-disconnect forces the maker to have that _ nick on *all* of his MCs 10:10 < AgoraRelay> [agora-irc/CatoAlex] so that backup, a 2nd MC, is directly affected by the bug as well 10:10 < AgoraRelay> [agora-irc/CatoAlex] "fallback solution" would have been a better word 10:10 < waxwing> i see 10:12 < AgoraRelay> [agora-irc/CatoAlex] so yes, reclaiming the name solves 99% of this problem 10:15 -!- qubenix [~qubenix@185.104.184.187] has quit [Remote host closed the connection] 10:59 -!- qubenix [~qubenix@185.65.134.178] has joined #joinmarket 11:30 < waxwing> btw it'd be great if anyone was running that PR (assuming no other comments), i'm running it atm but i dont' seem to get connection drops often at all 12:01 -!- so [~so@unaffiliated/so] has joined #joinmarket 12:52 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 2.1] 12:55 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://www.Quanto.ga/] 12:59 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 13:01 < AgoraRelay> [agora-irc/CatoAlex] i will 13:01 < AgoraRelay> [agora-irc/CatoAlex] will provide feedback tomorrow 15:42 -!- MaxSan [~user@86.105.9.67] has joined #joinmarket 16:00 -!- MaxSan [~user@86.105.9.67] has quit [Ping timeout: 264 seconds] 16:01 -!- MaxSan [~user@185.156.175.51] has joined #joinmarket 17:35 -!- AgoraRelay [~jmrelayfn@p5DE4A97E.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 17:48 -!- AgoraRelay [~jmrelayfn@p54866893.dip0.t-ipconnect.de] has joined #joinmarket 22:35 -!- AgoraRelay [~jmrelayfn@p54866893.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 22:48 -!- AgoraRelay [~jmrelayfn@p5DE4A866.dip0.t-ipconnect.de] has joined #joinmarket 23:41 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ylodevztenejfmrl] has quit [Quit: Connection closed for inactivity]