--- Day changed Fri Jul 06 2018
00:00 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket     
00:44 -!- GitHub75 [GitHub75@gateway/service/github.com/x-gpubocrzvwnxmkps] has joined #joinmarket     
00:44 < GitHub75> [joinmarket-clientserver] fivepiece opened pull request #158: add retry to curl in install process (master...installsh_curl_retry) https://git.io/fbjim
00:44 -!- GitHub75 [GitHub75@gateway/service/github.com/x-gpubocrzvwnxmkps] has left #joinmarket []     
00:59 -!- lnostdal [~lnostdal@85-118-78-83.mtel.net] has joined #joinmarket     
01:16 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
01:31 < undeath> waxwing: regarding nick collision handling, I think simply monitoring joins/parts won't work well. it could be easily abused by joining with nicks that pretent reconnects
01:32 -!- lnostdal [~lnostdal@85-118-78-83.mtel.net] has quit [Ping timeout: 276 seconds]     
01:35 < undeath> maybe a better way to implement this might be to always repond to the real nick but internally derive a "normalized" nick and use that for all purposes other than message routing
01:57 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
02:17 -!- rdymac [uid31665@gateway/web/irccloud.com/x-yvybzcrfquhfjtun] has quit [Quit: Connection closed for inactivity]     
02:25 -!- lnostdal [~lnostdal@85-118-78-83.mtel.net] has joined #joinmarket     
03:07 -!- lnostdal [~lnostdal@85-118-78-83.mtel.net] has quit [Quit: https://www.Quanto.ga/]     
03:25 < waxwing> that's essentially how it was set up before, but you have to keep track of the correspondence between the internalised form and the external/IRC form, so that when you send, you send to the right nick (on that particular IRCMessageChannel; it'll usually be different on the other/s message channel(s))
03:26 < waxwing> see, the signing feature was to prevent people squatting a nick that you hold on one channel, on another and thus trying to "steal" your messages (although that's ultra limited as an attack due to encryption)
03:27 < waxwing> but if you get a collision and drop into a "_" appended version, then theoretically an attacker can jump in and take the non-"_"-appended version right.
03:27 < waxwing> it seems there could be multiple scenarios where you can get "squatted" because we have no registration or anything, just id being verified internally/JM side.
03:40 < undeath> does it happen frequently that jm has to switch the messagechannel during the cj? seems to introduce pretty high complexity
03:42 < undeath> if not it might just be good enough to try to respond to the last known nick
03:42 < waxwing> good q; i specifically considered that kinda "out of scope". as i recall, it won't successfully complete a join with a dropout *during* negotiation, although it might depend exactly at what point the dropout occurs.
03:43 < undeath> as far as I understood the main problem right now is that jm can't contact the fallback nicks at all
03:43 < waxwing> i mean, "does it happen frequently", i'm sure, no. was answering whether it would work.
03:43 < undeath> so just responding to the last known nick on any available channel would be a huge improvement already
03:44 < undeath> the nicks should usually be the same on both networks, disregarding fallbacks, right?
03:44 < waxwing> not usually, definitely
03:44 < waxwing> it's a hash of a pubkey (so it can be signed against/authenticated)
03:46 < waxwing> respond to last known nick still requires keeping a mapping from the internalised to the external last-known-nick, right
03:47 < undeath> if you can compute the normalized nick from any nick there is no need to keep a map
03:47 < waxwing> but you have to send to the non-normalize
03:47 < waxwing> d     
03:48 < undeath> yes, the code would, in the scope of processing a single message, use both
03:48 < undeath> the normalized version for internal bookkepping and the real nick for responding
03:48 < undeath> that's what I imagine
03:49 < undeath> or do responses happen asynchronously?
03:49 < waxwing> yes     
03:50 < undeath> ah, I see
03:50 < waxwing> there's a one-many negotiation going on
03:51 < undeath> but still, couldn't you just pass around the real nick and compute the normalized one whenever you need it for anything but sending a response?
03:51 < undeath> not sure if that would require too many changes
03:52 < waxwing> trouble is there's more than one message channel and the non-normalized will be different on each one
03:52 < waxwing> the messagechannelcollection defines the nick, and has the job of re-routing to different messagechannels based on dropped connections.
03:53 < waxwing> so the network-layer nick is defined in the individual message channels, so in *some* sense i think there has to be a mapping between the two somewhere.
03:54 < undeath> well, given the complexity it would introduce I argue it'd be good enough if you just try the last known nick
03:54 < waxwing> got to hit the road in a minute, but fwiw i agree that it's better not to go for perfection here, just fix the out-and-out bug of not sending to the right nick in this case.
03:54 < undeath> that'd still be better than not being able to communicate with the fallback nicks at all
03:55 < waxwing> (i.e. i accept that there will be corner cases where it's theoretically possible for somebody to block communication, but rare due to more than 1 mc and rare-ness of collision also)
03:57 < undeath> another option would be cycling through the full nick list each time and send the response to all matching nicks
03:57 < undeath> but that seems wasteful
04:02 < belcher> could nicks that have _ do NICK until they get to a nick without _ ?
04:02 < belcher> i.e. change their nick
04:03 < belcher> also you can do the irc command NAMES #channel to get a full list of nicks
04:04 < belcher> i suppose it is a bit wasteful as undeath said
04:57 < AgoraRelay> [agora-irc/CatoAlex] > belcher] could nicks that have _ do NICK until they get to a nick without _ ? <-- easiest solution imho
04:57 < AgoraRelay> [agora-irc/CatoAlex] but adam is already considering that:
04:57 < AgoraRelay> [agora-irc/CatoAlex] <CatoAlex> or even easier idea: let the makers check periodically if their nick is too long and rename themselves back. Tolerate the few minutes in which they might not be able to get joins. Rationale: its usually just a few seconds of overlap, when the server does not know about the disconnection yet, but the maker already rejoined
04:57 < AgoraRelay> [agora-irc/CatoAlex] <AgoraRelay> [Freenode/waxwing] hmm yeah possibly. i'm off now (and will be all over the place next day or two) but keep thinking about limitations of various solutions. worth remembering that the dynamic switch between message channels already probably solves a good chunk of these problems (if you change nick on one channel but not the other
04:57 < AgoraRelay> the switch should
04:57 < AgoraRelay> [agora-irc/CatoAlex] <AgoraRelay> happen when you disconnect, the MCC notices and changes the channel on which you're active, iirc)
06:33 < waxwing> belcher, i think maybe (maybe?) that's the cleanest solution. it's the strictest but everything else seems a bit too messy to me.
06:35 < waxwing> anyone have any idea what the delay is likely to be, before you can reclaim a nick? just would like a sense of what timing we're looking at.
06:35 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]     
06:42 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
06:42 < arubi> I think dropped connections' nicks are cleared after 120 seconds on freenode?  should be easy to enable part\join messages on #bitcoin and see when that happens
06:42 < waxwing> fwiw i am just sitting here in the airport burbling. i don't really know. maybe i'll have a better idea after i get off the flight lol.
06:43 < arubi> heh, have a good one
06:45 < undeath> it's trivial for a malicious actor to claim that nick quicker and dos the maker
06:47 < arubi> how long can nicks usually be?  also I was wrong about 120 seconds, this is from #bitcoin now: "* kevthanewversi has quit (Ping timeout: 268 seconds)"
06:48 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 248 seconds]     
06:55 < arubi> also how is the nick authenticated to the other party?  I'm guessing it's something like you sign the nick and the pubkey is hashed and checked to match the nick?
06:56 < undeath> waxwing | it's a hash of a pubkey (so it can be signed against/authenticated)
06:56 < arubi> if that's how it works, then maybe when you get an "extended" nick, you should also sign the extension itself as part of the message
06:56 < undeath> so no, not quite
06:57 < undeath> but you can simply drop excessive characters
06:57 < arubi> you could sign a message <nick>|<extension> (if the nick has an extension), and authenticate with that
06:57 < arubi> the non extended nick is either dropped or simply not you, so they can't sign for you
06:58 < undeath> what is your goal right now?
06:58 < undeath> an attacker wouldn't know the matching private key anyway
06:58 < arubi> yea, but they can get the nick and annoy everybody
06:58 < undeath> they can still get the nick whatever you do to verify it
06:59 < arubi> I know they can, I'm failing to get my point across
07:00 < undeath> I think I see what you mean
07:01 < undeath> but implementing that would be far more complex than just cycling through the nick list
07:03 < arubi> yea that's true.  I guess you'll be cycling but stopping at the first one that works right?
07:03 < arubi> (on each network)
07:03 < undeath> you don't immediately receive a response, if you don't message all matches you have a high chance of messaging the one timing out
07:05 < arubi> I'm thinking about some kiddie just entering the channel with a bunch of nicks that look like extensions for already existing nicks
07:05 < undeath> I see, that would greatly increase your traffic then
07:08 < undeath> but would that cause more harm than a kiddie entering the channel with valid-looking makers that don't work?
07:11 < undeath> you could limit the nicks you message to <expected nick>, <expected nick>_, and up to X more that start with <expected nick>
07:11 < undeath> where X is some small number like 3
07:11 < arubi> yea but then if you drop and someone catches all these 4 different nicks before you return, you won't be able to communicate
07:12 < undeath> true
07:12 < arubi> maybe it should be the other way around.  when your jm client drops and returns with an extended nick, it messages all clients it was in mid conversation with to authenticate the new nick
07:13 < arubi> if it's starting a new conversation, it authenticates the same extended nick
07:15 < arubi> yea it's difficult..  not sure what's best here
07:17 < undeath> I mean, this is only remotely related to the issue at hand that we can't message a nick that has garbage characters at the end
07:18 < undeath> for the message routing caused by connection abort a best-effort strategy seems ok
07:20 < undeath> I assume jm does create a new offer in the channel when joining after a re-connect
07:20 < undeath> so as long as other jm clients know how to handle the extended nick the maker will still work
07:22 < undeath> if in the meantime a rouge maker took over the original nick it would just get blacklisted like any other non-responding fake maker
07:49 -!- MaxSan [~user@86.105.9.67] has joined #joinmarket     
08:01 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
08:03 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has joined #joinmarket     
09:03 < AgoraRelay> [agora-irc/CatoAlex] > /waxwing] anyone have any idea what the delay is likely to be, before you can reclaim a nick? just would like a sense of what timing we're looking at
09:03 < AgoraRelay> [agora-irc/CatoAlex] its usually less than 1 minute
09:04 < AgoraRelay> [agora-irc/CatoAlex] i stand corrected, example from today:
09:04 < AgoraRelay> [agora-irc/CatoAlex] 03:43:32 * J52VsiCLK7kiwoXu_ (J52VsiCLK7k@mynet7k7.e14.28u4qj.IP) has joined
09:05 < AgoraRelay> [agora-irc/CatoAlex] 03:36:03 * J52VsiCLK7kiwoXu has quit (Ping timeout: 121 seconds)
09:06 < AgoraRelay> [agora-irc/CatoAlex] 03:46:03 * J52VsiCLK7kiwoXu has quit (Ping timeout: 121 seconds)
09:06 < AgoraRelay> [agora-irc/CatoAlex] (correct timestamp now)
09:06 < AgoraRelay> [agora-irc/CatoAlex] so around 2.5 minutes, even though the ping timeout is reported as 121 seconds.
09:08 < AgoraRelay> [agora-irc/CatoAlex] about that: > arubi] yea, but they can get the nick and annoy everybody
09:09 < AgoraRelay> [agora-irc/CatoAlex] you can only "steal" the nicks of the ones which disconnect and get back before the server drops them. Thats like... 5% of nicks maximum? That annoyance would be low if someone tried to intentionally "exploit" that
09:10 < AgoraRelay> [agora-irc/CatoAlex] and in the unintentional cases, a simple rename-to-original-nick will fix the problem which currently exists (= nicks with _ appended will be not doing anything)
09:10 < AgoraRelay> [agora-irc/CatoAlex] so worst case: same situation as now
09:10 < AgoraRelay> [agora-irc/CatoAlex] best case: reduces non-communication to the small time frame that the maker needs to rename
09:10 < AgoraRelay> [agora-irc/CatoAlex] so likely a few minutes
09:30 < arubi> yea I see both your points.  maybe a "passive" approach is better here.  just retry the original nick every so often
10:02 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 268 seconds]     
10:36 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 2.1]     
12:36 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
12:49 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 268 seconds]     
12:53 < belcher> nopara73 is going around saying joinmarket's anonymity set is only 2-6, iv told him off on twitter
12:55 < belcher> regarding the nick change thing, maybe could we have maker bots generate an entirely new keypair and change nick to have the hashvalue corresponding to that? it should avoid the problem of nick squatters not allowing makers to change their nicks back to the original
13:10 -!- MaxSan [~user@86.105.9.67] has quit [Remote host closed the connection]     
13:29 < AgoraRelay> [agora-irc/CatoAlex] for a single sendpayment, it's true though. In his medium post, he only had one paragraph for each other solution, maybe not enough space to go into much more depth while keeping it short?
13:29 < AgoraRelay> [agora-irc/CatoAlex] kinda doubt that he doesnt know better
13:32 < belcher> using a single sendpayment to improve your privacy is simply doing it wrong
13:33 < belcher> it looks like he makes money per tx on his wallet, hopefully he wont end up like privacy-focused altcoins who think they help their own project by being misleading about others
13:38 < belcher> waxwing at one point on CoinJoinTX you mentioned that one side could broadcast all the coinjoins immediately without delay which would be bad for privacy... that problem can be fixed using the nlocktime field, and it wont even harm privacy because electrum and bitcoin core set nlocktime
13:52 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]     
14:02 < waxwing> belcher_, yeah that was explicitly mentioned in the Q/A .. i think it was also in the blogpost? or maybe i forgot in the blogpost? if so i'll correct cos it's important
14:03 < waxwing> belcher_, re nopara saying the anonymity set is 2-6, i already told him on twitter, but it doesn't seem to stop him repeating it sadly. still it's not something worth fighting over really, after all there are matters of perspective in this.
14:04 < waxwing> belcher_, also i corrected that article that's just come out that mentioned i'm the creator of joinmarket :) but you were pinged on twitter you probably saw already.
14:04 < waxwing> still personal perspective aside, compared to the litany of comically wrong statements that most "crypto" journalists make, that wasn't too bad ...
14:21 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ylodevztenejfmrl] has joined #joinmarket     
15:54 < AgoraRelay> [agora-irc/Paradox] Hey, what is this chat?
19:21 -!- AgoraRelay [~jmrelayfn@p5DE4A329.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]     
19:34 -!- AgoraRelay [~jmrelayfn@p5DE4A97E.dip0.t-ipconnect.de] has joined #joinmarket