--- Day changed Mon Jan 14 2019
01:36 < waxwing> https://anarplex.net/log/08/
01:40 < waxwing> i suspect that what we've experienced is on the new server config; according to this page the old .onion is still valid (which is what we've seen): https://anarplex.net/agorairc/connect/
01:56 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
02:27 -!- user___ [187de310@gateway/web/freenode/ip.24.125.227.16] has joined #joinmarket     
02:35 -!- user___ [187de310@gateway/web/freenode/ip.24.125.227.16] has quit [Quit: Page closed]     
03:53 < waxwing> interesting, i didn't realise, but apparently we still have a non-deterministic failure mode in the tests: https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/479192299#L3405
03:53 < waxwing> guess it's super rare tho
03:54 < waxwing> btw gonna be doing several merges today (may or may not include the colored logs, later), updates and running with master tomorrow will be appreciated.
04:05 < waxwing> <J59maddpXV3MBp8T> !orderbook
04:05 < waxwing> <Courage> What kind of books 
04:05 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds]     
04:09 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
05:07 < arubi> waxwing, the asciinema video works fine here
05:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds]     
05:35 < waxwing> thx     
05:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket     
06:20 < waxwing> arubi, is there something we can do to make the tests take less time?
06:20 < waxwing> perhaps run one environment but somehow have a flag that lets us periodically run all of them?
06:20 < waxwing> talking about travis of course, not tests per se
06:22 < waxwing> hmm, it's interesting, it appears they run kinda in parallel, but also not entirely. like each run taking ~ 7-8 minutes, but overall about 24 minutes (so far, this one is not complete) although there are about 8 of them altogether.
06:22 < waxwing> hmm, 11 not 8
06:45 < Xeha> so i upgraded my old joinmarket (non segwit) to the new one. the wallet tool only lists segwit addresses now and my balance is 0 :(
06:52 < belcher> i think the easiest method would be to create a new joinmarket wallet seed phrase which will be segwit, and send the bitcoins from your old wallet to your new wallet using the old joinmarket software
07:00 < Xeha> thats something i'd like to avoid...
07:07 < waxwing> Xeha, try adding segwit=false to your joinmarket.cfg
07:08 < waxwing> in the [POLICY] section, sorry
07:08 < Xeha> already set, its loading (will take a few mins9
07:09 < waxwing> there's nearly nobody left in this position, so i tbh am not 100% sure if something might be borked. you having a huge/old wallet with a lot of gaps is of course a separate question.
07:09 < Xeha> its not that i dont want to use segwit, but i thought it would gradually convert the non-segwit UTXO to segwit everytime i'd tumble or so
07:09 < waxwing> and btw Xeha the new software only supports direct send (-N 0) txs with nonsegwit, not coinjoins.
07:10 < waxwing> Xeha, yes that would have been nice, but there are issues with anonymity sets. nobody wants to be the 'odd one out' in a transaction.
07:10 < waxwing> it's debatable, but for simplicity's sake, we have a segwit-only version of the software.
07:11 < waxwing> direct send sweeps, mixdepth by mixdepth, from one wallet to the other, are the best way if you want to keep JM running. or at least the most practical way that doesn't really harm your privacy (we consider all coins in one mixdepth already essentially linked)
07:12 < Xeha> so sweeping each mixdepth to a new joinmarket segwit address is the way to go
07:13 < waxwing> yeah do it like: `python sendpayment.py -N 0 -m 0 mywallet.jmdat 0 address-from-mixdepth-0-in-new-wallet`
07:13 < waxwing> and same for -m 1,2...
07:13 < Xeha> rgr, thanks
07:13 < waxwing> of course first you have to do a `generate` to make a new wallet
07:13 < Xeha> probably deleting bitcoind's wallet.dat aswell? thats seriously bloated
07:14 < waxwing> Xeha, i had a similar issue
07:14 < waxwing> the thing to do is to make a new wallet.dat
07:14 < waxwing> and then point joinmarket to it; we can now use bitcoind's multiwallet feature for this
07:14 < waxwing> i can find the mention in the release notes somewhere, it was something belcher added for us iirc
07:14 < belcher> dont delete it
07:15 < belcher> it could always be useful
07:15 < Xeha> so i should segwit=false with wallet W1, then i create a new wallet.dat W2 with is segwit=true and generate a new joinmarket one aswell for it
07:15 < belcher> you can generate a wallet.dat again but its a bit of a pain and requires -rescan usually
07:15 < Xeha> oh, i have snapshots and i cp'd it alreayd before upgrading
07:15 < belcher> yes Xeha regarding segwit=false/true
07:15 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/release-notes/release-notes-0.3.4.md#support-for-bitcoin-core-multiwallet-feature
07:16 < waxwing> yeah just make a new wallet.dat
07:16 < waxwing> and set its name in rpc_wallet_file in [BLOCKCHAIN] in joinmarket.cfg
07:23 < arubi> waxwing, yea it's basically running 5 jobs in parallel max.  it definitely should be possible to say run only a subset of the platforms at every PR (maybe just the native osx and ubuntu ones, the top two), and a nightly\weekly\monthly run that executes all the tests
07:24 < waxwing> arubi, yeah i think it might be better to go with that, but it's obviously far from a priority. when i'm doing tons of merges and edits, i might just manually cancel some of the runs (like PR, squash, merge .. all trigger runs).
07:25 < belcher> im reading a paper and saw this, might be old news to some (paper is from april 2018)
07:25 < belcher> "We adapt Moser et al's algorithm to identify JoinMarket transactions [47], and it is shown in
07:25 < belcher> Algorithm 3 in Appendix A.1. We found 95,239 such transactions, of which 78,697 are during the period of interest to us (mid-2015 - mid-2017). The number of coins mixed in one of these transactions has a mean of 3.98 and a stardard deviation of 1.72."
07:25 < arubi> travis also lets you control test flow by keywords in the commit message, so that might be useful too.  I'll look into it
07:25 < belcher> 78,697 joinmarket transactions in a 2 year period is just over 100 per day
07:25 < waxwing> belcher, i think it might be an update; that's narayanan's paper right, i think it came out before that
07:25 < belcher> the paper "when the cookie meets the blockchain"
07:25 < waxwing> i probably mentioned it here, i also found that data super-interesting (they presumably did it with an early version of blocksci)
07:25 < waxwing> yeah that's the one
07:25 < belcher> yes him
07:26 < waxwing> i met the main blocksci guy at stanford, kalodner i think was his name. they were just upgrading for segwit at the time.
07:26 < waxwing> he's probably a co-author. yes, that paper.
07:26 < belcher> harry kolodner yes is a coauthor
07:26 < waxwing> my suspicion is they have some false positives, but for sure it's not way off.
07:26 < belcher> its interesting that mid-2015 is when joinmarket was first released so presumably didnt have many users yet, also early-mid-2017 was when the demand for block space started getting higher
07:27 < belcher> Mosor's algorithm works by starting from a known JM tx and seeing whether the input or output addresses also look like JM txes, so the false positive rate shouldnt be very high IMO (but of course you can never tell)
07:27 < waxwing> yeah the algo's in the appendix, it's accurate, i agree.
07:28 < belcher> what did they say at stanford?
07:28 < waxwing> but you can just get false positives anyway, it especially depends on the low-end cutoff of N, right.
07:29 < waxwing> stanford, just scaling 2017. there was an interesting cut-away group discussion on privacy tech, with Bunz, Ficsor, Ruffing, a few other people you might know. But you know how those discussion groups work, they're largely pointless unless properly structured.
07:29 < belcher> txes that just happen to have 3 or more equal-amount-outputs just by chance still have to touch an existing JM tx to be a false positive
07:29 < waxwing> i guess i mention that because that's when i met kolodner, he was sitting next to me.
07:29 < belcher> ah ok
07:29 < waxwing> oh; is that in the algo? i missed that. yes that's a big deal.
07:30 < waxwing> i guess i just focused on the numerical checks.
07:30 < belcher> i could be misremembering
07:30 < belcher> i know adlai's cjhunt worked by just checking for the tx structure without seeing whether they touched known JM txes, and it had some false positives
07:35 < waxwing> arubi, thx yeah let me know, that could be a nice trick
07:43 < Xeha> the converting of old to new format wallets is deterministic? ie old backups can be converted to the same new one?
07:45 < waxwing> i don't see much of a source of non-determinism
07:46 < waxwing> do the labels you see in bitcoin listunspent match the label you see when you startup the joinmarket wallet?
07:46 < waxwing> hmm hold on not sure where that shows up, i know it shows up in starting up yieldgenerator, but not sure it shows up when running wallet-tool
07:49 < Xeha> no it dosnt list the label
07:49 < waxwing> yeah, we should get that for you, so you can actually check if it matches, otherwise you're wasting your time
07:49 < waxwing> sec     
07:50 < Xeha> can i switch segwit=false/true while having the same new wallet? or should i convert and then duplicate and send from first to second then ditch the first once done?
07:53 < waxwing> hang on, let's get the other thing done first
07:53 < waxwing> did you install.sh with --develop?
07:53 < Xeha> nope, cant switch between segwit=true/false (just tried)
07:53 < Xeha> nope, but i can
07:54 < waxwing> it's ok. just go into jmvenv/lib/python.../site-packages and find the jmclient directory
07:54 < waxwing> in jmclient/wallet_utils.py add this line:
07:54 < waxwing> print("wallet name: ", jm_single().bc_interface.get_wallet_name(wallet))
07:55 < Xeha> already did tell it to start build with develop :)
07:55 < waxwing> should be line 449, but it might be a bit off, but just before these two lines:
07:55 < waxwing>     walletview = WalletView(path, acctlist)
07:55 < waxwing>     if serialized:
07:55 < waxwing> can give exact line if you give me commit shown by `git log`
07:56 < Xeha> 0.5.1 tag
07:56 < waxwing> k     
07:56 < Xeha> jup, 449
07:56 < waxwing> yes agreed, just after that
07:57 < waxwing> then run wallet-tool again and the first line should be the name of your wallet
07:57 < waxwing> (we should add that, i'll open a PR i guess)
08:00 < Xeha> yes, matches :)
08:00 < waxwing> it matches, ok, good so you know they're accessible coins, assumign your listunspent call is correct
08:01 < Xeha> it lists my coins with segwit=false
08:01 < waxwing> yes segwit=true uses an entirely different algo (Bip39/bip44), so it won't match in any way
08:02 < Xeha> but i tried switching to segwit=true with same jmwallet, didnt work. so i'll duplicated a newly converted one and make them them nonsegwit/segwit and send from first to second
08:02 < Xeha> ah     
08:02 < waxwing> yes, at the time of conversion this was explained. i can find the doc for you
08:02 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/SEGWIT-UPGRADE.md
08:03 < waxwing> it included a brief section on migrating coins: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/SEGWIT-UPGRADE.md#if-you-do-have-an-existing-joinmarket-wallet
08:03 < Xeha> ah ty, i did onyl read the 0.4 release notes as it was mentioned its neccessary to read it
08:04 < Xeha> but should work fine if i duplicate the newly created ones, instead of creating a new one?
08:04 < waxwing> but as for your not being able to sync, well, i don't know. worst comes to worst you can dump literally all the private keys with -p and displayall, but that won't be easy. it should be able to find the coins. try both with and without --fast (generally i would avoid --fast now, it no longer makes sense in the way it did; the non --fast is usually ok).
08:04 < Xeha> yes it finds them now
08:04 < waxwing> what does 'duplicate the newly created ones' mean?
08:05 < Xeha> i convert the old wallet to a new one, then duplicated said one (different filenames)
08:05 < Xeha> after that one will be run with segwit=false, the other with segwit=true
08:05 < waxwing> ok it finds them, good. then just follow that migration suggestion (which i already said), do a mixdepth-by-mixdepth sweep.
08:05 < waxwing> no just make a new one using generate, it will be segwit automatically, then migrate coins.
08:05 < waxwing> afk for a bit
08:05 < Xeha> but is that necessary?
08:06 < Xeha> cause the convert is deterministic, so the new segwit one would also be backed up by the old one indirectly
08:53 < waxwing> there is no compatibility, at all, between the segwit and non-segwit wallet types. note that this is completely separate from the difference between the old *json and new *jmdat wallet *file* types.
08:53 < waxwing> the non-compatibility point is explained at length in the doc I linked.
09:21 < qubenix> waxwing: do you use a black background in your terminal? with black background the debug color (dim blue) is barely readable. normal blue is ok and still highlights the bright blue info msgs.
09:43 < qubenix> but on white background the difference is barely visible between normal and bright blue. :(
09:46 < waxwing> qubenix, right. i had a suspicion that might happen. so i wonder, what's best is probably have an option to switch it off; alternatively could make color configurable but that sounds too complicated.
09:47 < waxwing> thanks for the feedback, it was rather needed for this one.
09:48 < qubenix> np. i'll keep tinkering with it while i have free time today.
09:48 < waxwing> well, unless there really is a color set that would work anyway. not sure.
09:48 < waxwing> qubenix, you can just edit the colors in jmbase/support.py if you want to try something different.
09:48 < waxwing> it's called jm_color_map iirc
09:48 < qubenix> got it
09:50 < waxwing> i agree about 'barely readable' on black, but that's kinda what i was going for. well; i'd more say 'not easy to read'. it's not actually illegible, so to speak.
09:50 < waxwing> literal bikeshedding time :)
09:58 < technonerd> The default blue is horrendous on every system I've used 
09:59 < waxwing> horrendous? oh dear, sorry, wasn't quite expecting that. do you mean you just can't read it?
09:59 < waxwing> i'll put together a "switch it off" config now then,  but also if people have other color schemes they prefer let me know.
09:59 < waxwing> it looks fine here.
10:11 < qubenix> so far what worked best for me is to change debug to dim green and success to bright green
10:13 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 246 seconds]     
10:19 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket     
10:25 < waxwing> qubenix, does the yellow for warning look OK? (it looks more orange here but that's fine ofc)
10:25 < waxwing> i won't ask about error, since you probably haven't seen it, it's red, that should be fine on any terminal i guess.
10:27 < qubenix> i haven't seen a warning msg yet. i haven't seen a success either, i just guessed on switching that to bright green when i put dim green on debug.
10:29 < waxwing> gotcha. yeah what you said sounds fine. btw for an idea what it looks like on my terminal you can look at that asciinema thing i linked.
10:30 < waxwing> https://asciinema.org/a/221153?speed=2 (not that it matters ofc). oh i just remembered i specifically switched off debug. but; it's interesting that people find green better than blue i guess. maybe it's because it was LIGHTBLUE... but for me it looked fine. oh well.
10:31 < waxwing> and yeah i don't know how clever you'd have to get to make colored logging work well on an *arbitrary* color background.
10:31 < waxwing> i guess as long as it's legible on both white and black that's enough?
10:32 < waxwing> yeah i'm playing with my console background, i think it looks OK on black, and on white it's probably not ideal, but legible anyway.
10:32 < waxwing> seems to me the 'bright blue for emphasis' doesn't work on white, though.
10:33 < qubenix> in re. to LIGHTBLUE, i changed that to BLUE and the color didn't seem to change at all.
10:35 < waxwing> qubenix, oh interesting. it looks very different here changed to BLUE. much darker. (even with Style.DIM still)
10:36 < qubenix> huh, i'll have to check it again then.
10:37 < waxwing> anyway, looking at black, white and ubuntu system default, it all looks *ok*, although the white it's pretty non-ideal really (INFO not emphasised to one's eye).
10:38 < waxwing> anyway i'll go back and figure out a quick PR to have it switched off (possibly by default, depending on what people think).
10:38 < waxwing> personally I *much* prefer having this. even though i actually understand all the output it's quite turgid scrolling through it all the time looking for things.
10:47 < qubenix> on debian-9 i don't see any difference between dim lightblue_ex and dim blue with black or white background.
10:50 < waxwing> is the INFO legible? and also, how does it look when you switch to green? does it look bright green/bold?
10:50 < waxwing> i wasn't really expecting there to be some massive difference with let's say "normal" distros, there's probably more to this than i realized(?).
10:54 < qubenix> info is good default, it's the same blue as my path in the term prompt.
10:55 < qubenix> s/path/working dir/
11:01 < qubenix> here is what dim green looks like: https://ibb.co/f9GPqpt
11:02 < waxwing> yeah that looks fine, thanks
11:03 < waxwing> technonerd, qubenix pushed a commit to master, you can switch off colored logging with `color=false` in [LOGGING] section of config now.
11:04 < qubenix> ok, for the record i like the colored output a lot.
11:07 < waxwing> good, yeah, i'd like to keep it the default (as it still is after that commit). but am open to switching the color choices, it's just very hard to judge what the best is. i didn't expect it'd look strange enough to actually cause a problem unless you were using some funky background color like green maybe. or blue.
11:07 < waxwing> interestingly, chromalog's default choices were these: https://chromalog.readthedocs.io/en/latest/_images/fast-setup.png
11:08 < waxwing> i probably shouldn't have so casually changed them! for some reason i didn't like INFO being white (feels like it doesn't stand out)
11:08 < waxwing> and the debug looked sort of wrong too (think it's CYAN)
11:09 < belcher> "payjoin" is a better name for the concept than pay-to-end-point ? any objections before i start using "payjoin" everywhere
11:10 < grubles> payjoin ftw
11:11 < waxwing> here's the default qubenix : https://github.com/freelan-developers/chromalog/blob/master/chromalog/colorizer.py#L268-L276
11:11 < waxwing> belcher, yes i suggested it in london but people were focused on the merchant use case so most discussion was about that. (but i knew that normies' response to 'pay-to-endpoint' would be "eh?" :) )
11:12 < waxwing> one could reserve p2ep for a merchant solution.
11:12 < waxwing> and as for bustapay, big props to the work done by the guy, but that name isn't really going to work :)
11:12 < waxwing> even if it does actually have logic, outside of his business
11:12 < waxwing> which it does
11:12 < belcher> is "payjoin" less focused on the merchant usecase ?
11:13 < waxwing> well i think so yes. but i'm not saying we cant just blanket call all of it "payjoin"; sure, why not.
11:13 < belcher> i guess "payjoin" might be a bit less user-friendly, you could imagine a newb saying "this site wants me to pay by payjoin, but i only have bitcoin, is that ok?"
11:13 < waxwing> heh     
11:13 < waxwing> someone was saying it reminded them of paycoin :)
11:13 < belcher> maybe pay-to-end-point sounds a bit more like a method rather than a "thing", oh i dont know
11:14 < belcher> p2ep ideally wouldnt be a thing thats marketed, or would it?
11:14 < waxwing> well; payjoin is just in the tradition of "coinjoin" , "coinswap", "joinmarket"; short name that encapsulates the central idea in brief.
11:14 < waxwing> it doesn't necessarily sound too "branded" imv. but, shrug, who knows.
11:15 < belcher> ill stick with payjoin, theres many blog posts already using the name p2ep anyway so we'll see what happens
11:15 < waxwing> i guess there's matthew haywood's one, and pretty sure nopara too; any other p2ep blog posts?
11:16 < Xeha> btw, did anyone get that bounty for coinjoin from gmaxwell?
11:16 < waxwing> hmm maybe samourai, but they have yet another name for it :)
11:16 < waxwing> i think it's stowaway but it's hard to keep up with all their names :)
11:18 < qubenix> waxwing: in re. the default colors, dim cyan looks good on black but not on white and i agree that white INFO doesn't stand out enough.
11:18 < belcher> Xeha nope
11:21 < waxwing> finding it amusing to see the response Udi is getting to my puzzle: https://twitter.com/DogePreacher/status/1084885048803745793
11:22 < belcher> he presumably thought its a mixer because it touches other joinmarket transactions
11:22 < waxwing> yes, that's what i presumed too.
11:23 < belcher> he got the UIH though
11:23 < waxwing> it's notable that of the few responses, at least a couple referenced UIH1
11:23 < waxwing> yes, snap :)
11:23 < waxwing> i guess it makes sense; if you look at it as a puzzle, just with that jpeg image, that's about the only thing you *can* deduce.
11:30 < waxwing> belcher, i feel like this question is right up your alley: suppose people started doing payjoins with mixed wallet types. would that be (a) totally fine, (b) unfortunately always a bad thing or (c) something else, in your view?
11:30 < belcher> by different wallet types do you mean p2sh and p2wsh and so on?
11:30 < waxwing> yeah let's say
11:31 < waxwing> so i meant different address types really, sorry
11:31 < belcher> i think it would be bad unless there was a wallet out there that used multiple address types in the same wallet
11:31 < waxwing> but .. well that's where it's tricky i guess :)
11:31 < waxwing> yeah that seems to be the first cut answer, doesnt it.
11:31 < belcher> i think samurai wallet does that, they try to make the change address type match the payment address type
11:31 < waxwing> because that doesn't really exist, except *maybe* somebody using Core and coin selection or something.
11:32 < belcher> i made one a few day ago (mixed uncompressed and compressed p2pkh) but it was using Core raw transactions
11:32 < belcher> btw the old joinmarket donation address is now part of MtGoxAndOthers https://www.walletexplorer.com/wallet/MtGoxAndOthers?from_address=1AZgQZWYRteh6UyF87hwuvyWj73NvWKpL
11:33 < waxwing> i guess it's mostly change heuristics that bork things up.
11:34 < belcher> there are wallets that mix output types, but not input types
11:34 < belcher> i.e. if you use a single-sig wallet and pay a multisig address, then your transaction mixes output types
11:35 < belcher> mixed input types is basically a coinjoin giveaway isnt it, since i cant imagine a reason a regular wallet would do it (except to improve the privacy of payjoin)
11:40 < waxwing> doubtless happens occasionally e.g. big businesses but not normal payments for sure
11:40 < waxwing> so this does quite seriously affect the potential merchant use case
11:40 < belcher> i dont see why big businesses would do it, except a one-off when they transition to segwit
11:40 < waxwing> yeah really rare cases
11:41 < belcher> yes agreed
11:41 < waxwing> a merchant would have to make a choice to hold its coins in multiple address types to deal with this. that's not good.
11:41 < belcher> maybe a fix could be that the merchant holds some coins in a few address types so they can do payjoins with whatever wallet type the customer uses
11:42 < belcher> or we just fix that payjoins are single-sig p2wpkh-p2sh or something
11:42 < belcher> (but then an analyst can say for sure that a p2pkh is definitely not a payjoin)
11:47 < belcher> the fix of requiring the merchant to have UTXOs on several address types is the most practical i think
12:57 < waxwing> whichever way it's handled, i think it's a big negative for the idea; another way is to just use the fallback non-coinjoin if the input type doesn't match your type(s)
13:05 -!- johnhmay_ [sid110431@gateway/web/irccloud.com/x-jvwcsvnfuvsdkpoi] has joined #joinmarket     
13:10 < belcher> that way has a downside that privacy isnt improved
13:11 -!- nsh [~lol@wikipedia/nsh] has quit [Ping timeout: 268 seconds]     
13:11 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-jqiytollnodztveh] has quit [Ping timeout: 268 seconds]     
13:11 -!- johnhmay_ is now known as johnhmay     
13:11 < belcher> how many address types are there really? for single-sig its only 3 major ones p2pkh, p2wpkh-p2sh and p2wpkh
13:14 -!- nsh [~lol@wikipedia/nsh] has joined #joinmarket     
13:54 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
14:08 -!- nothingmuch [~user@62.102.148.189] has joined #joinmarket     
15:07 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]     
15:34 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
17:20 -!- AgoraRelay [~jmrelayfn@p5DE4AB16.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]     
17:34 -!- AgoraRelay [~jmrelayfn@p5DE4AE76.dip0.t-ipconnect.de] has joined #joinmarket     
18:13 -!- raedah [~x@184.75.223.219] has joined #joinmarket     
18:28 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has joined #joinmarket     
18:51 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has quit [Quit: Leaving]     
23:48 -!- nothingmuch [~user@62.102.148.189] has quit [Ping timeout: 246 seconds]     
23:57 -!- nothingmuch [~user@213.152.161.30] has joined #joinmarket