--- Log opened Sat Jul 31 00:00:25 2021
02:05 -!- undeath [~undeath@user/undeath] has joined #joinmarket
02:43 < belcher_> i pushed a commit rewording the release notes 0.9.0
02:43 -!- belcher_ is now known as belcher
04:03 < waxwing_> belcher, ok cool i'll push it out later today, i just need to correct that one typo about "be yet be" and it's done.
05:10 -!- undeath [~undeath@user/undeath] has quit [Quit: WeeChat 3.1]
07:49 <+JoinMarketRelay> [hackint/person] since FB there are tons of "Message to ... throttled due to flooding"
07:55 < belcher> are you running or someone else runnign the fidelity bond code?
07:55 < belcher> it is not released yet so i first thought "since FB" doesnt make sense, unless people are running from the master branch
07:58 < waxwing_> see https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.0 i will post to mastodon shortly, feel free to do so on other channels and update IRC etc
08:03 <+JoinMarketRelay> [hackint/person] of course i am running FB, that's why i said it
08:09 < belcher> hmm
08:09 < belcher> ok well i can try it out myself a bit later today
08:09 < belcher> are you able to see your own bot when you run ob-watcher.py ?
08:10 <+JoinMarketRelay> [hackint/person] sure
08:11 <+JoinMarketRelay> [hackint/person] every privmsg generates 2-4 throttling messages, all from hackint. it definitely wasn't like that before FB. maybe because the msgs are bigger?
08:12 < belcher> yes messages which announce FBs are bigger
08:12 < belcher> hold on
08:12 < belcher> i havent looked at the throttling code in a while, but isnt the throttling done by joinmarket itself and not by the irc server? if so then all the data should still be transferred but just slower
08:13 < belcher> if you can see fidelity bonds displayed on ob-watcher.py then its all working
08:13 < belcher> you are a yield-generator i assume? or are you a taker
08:15 <+JoinMarketRelay> [hackint/person] yg. if it's jm itself then why is it saying guybrush.hackint.org? "[DEBUG]  (unhandled) noticed:  guybrush.hackint.org .... *** Message to .... throttled due to flooding"
08:15 < belcher> ok, hmm
08:15 <+JoinMarketRelay> [hackint/person] i am not doubting whether it's working, i am merely saying it's giving these warnings much more frequently than before FB
08:15 <+JoinMarketRelay> [hackint/person] thought you might wanted to know
08:16 < belcher> thanks
08:16 < belcher> ill run ob-watcher.py myself in a little bit to check
08:18 <+JoinMarketRelay> [hackint/person] what is maybe also strange is that a privmsg to given nick is sent more than once via each irc channel, miliseconds apart. so there are always 3-4 identical privmsgs
08:18 <+JoinMarketRelay> [hackint/person] not sure if it was doing that before
08:19 <+JoinMarketRelay> [hackint/person] i am not seeing any warnings in ob-watcher, just in yg
08:28 <+JoinMarketRelay> [hackint/person] 3x identical privmsg to nick1: ":04:06,679 [DEBUG]  >>privmsg on hackint", ":04:06,729 [DEBUG]  >>privmsg on darkscience", ":04:06,730 [DEBUG]  >>privmsg on hackint", followed by 4 throttling warnings
08:28 < waxwing_> person fwiw i have strong evidence that using FB as yg is working fine and allowing joins
08:28 <+JoinMarketRelay> [hackint/person] 3x identical privmsg to nick2: ":15:15,188 [DEBUG]  >>privmsg on hackint", ":15:15,268 [DEBUG]  >>privmsg on darkscience", ":15:15,268 [DEBUG]  >>privmsg on hackint", followed by 4 throttling warnings
08:28 < waxwing_> and i see the same warnings
08:28 <+JoinMarketRelay> [hackint/person] 1 minute later again the same identical privmsg to nick2, this time 4x: ":16:15,520 [DEBUG]  >>privmsg on darkscience", ":16:15,520 [DEBUG]  >>privmsg on hackint", ":16:15,565 [DEBUG]  >>privmsg on darkscience", ":16:15,565 [DEBUG]  >>privmsg on hackint", followed by 4 throttling warnings
08:29 <+JoinMarketRelay> [hackint/person] i never said it's not working
08:30 < waxwing_> i also can note i've seen it working with the coinjoin interaction happening over hackint as well as darkscience.
08:30 < waxwing_> yes i'm not criticizing, this is worth of careful note.
08:30 < waxwing_> i believe these messages already existed but they are now triggered reliably on the !fill response on hackint
08:31 < waxwing_> doubtless as per the comment i made on the PR, i.e. we now send two lines not one in our !fill response
08:34 -!- waxwing_ is now known as waxwing
08:34 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host]
08:34 -!- waxwing [~waxwing@user/waxwing] has joined #joinmarket
08:34 <+JoinMarketRelay> [hackint/person] right now there is only me and maybe a few others using FB. i am wondering how will the messaging work when hundreds of people will use FB
08:34 < waxwing> of course, i had the same question, i think i raised it in the PR
08:35 < waxwing> please share if you like: https://x0f.org/web/statuses/106675919959913019
08:35 -!- mode/#joinmarket [+o waxwing] by ChanServ
08:35 -!- waxwing changed the topic of #joinmarket to: JoinMarket: Improving bitcoin privacy since 2015 | https://github.com/Joinmarket-Org/joinmarket-clientserver | @joinmarket r/joinmarket | Logs: http://gnusha.org/joinmarket/ | Latest release 0.9.0 | Also on ncwkrwxpq2ikcngxq3dy2xctuheniggtqeibvgofixpzvrwpa77tozqd.onion:6667
08:35 -!- mode/#joinmarket [-o waxwing] by ChanServ
08:37 <+JoinMarketRelay> [hackint/person] hope the mass usage of FB will not crash irc. it would be unfortunate if something that is supposed to make JM better would make it worse
08:40 < waxwing> it strikes me as very unlikely that anything bad will happen due to our use of redundant servers; however, we always badly need more help in testing stuff out. if you can do tests seeing specific communication issues arising out of this, please let us know.
08:40 < waxwing> for myself my testing so far indicates it isn't going to cause that, but i am definitely not 100% sure yet.
08:42 <+JoinMarketRelay> [hackint/person] well i think there is no argument that a better way of exchanging messages would help a lot
08:45 < waxwing> i've been looking at it a lot. spent many hours looking for best ways but end up snowed under with (no joke) hundreds of hours of testing, coding, analyzing and helping others. and that's just JM, i have other stuff to do too.
08:45 < waxwing> libp2p -> gossipsub is kinda interesting. extremely nontrivial to figure out the best way to integrate, though.
08:46 <+JoinMarketRelay> [hackint/person] i know this is a years long issue
08:46 < waxwing> on the surface a lot of ideas look like slam dunks but they may not be. you prob know (since i keep repeating it) but in *theory* anyone could make a new implementation of MessageChannel by implementing ~ 4 methods.
08:47 < waxwing> but what goes behind those 4 methods is of course not so simple :)
08:48 <+JoinMarketRelay> [hackint/person] i think a huge dealbreaker is that it must be decentralized
08:49 <+JoinMarketRelay> [hackint/person] have you ever thought about using bitmessage infrastructure?
08:50 < waxwing> myself i haven't, but others mentioned it a couple of times.
08:51 <+JoinMarketRelay> [hackint/person] or hijacking OP_RETURN in fake bitcoins transactions that would never confirm
08:51 < waxwing> i can't see how on-chain stuff would help here? isn't it way too slow to be of any use?
08:52 <+JoinMarketRelay> [hackint/person] when you send transaction it takes mere seconds to propagate it across thousands of nodes. that's faster than how irc is used currently
08:53 < waxwing> yeah but then .. at some point they might actually confirm :)
08:53 < waxwing> also i wouldn't assume re: faster. it's actually surprising how slow the global propagation happens, at times. or maybe i'm remembering very old anecdotal data that's wrong. meh, either way.
08:53 <+JoinMarketRelay> [hackint/person] well not if they get invalidated
08:54 < waxwing> well i admire your hacker attitude, but .. not quite on board with this one yet :)
08:54 <+JoinMarketRelay> [hackint/person] i am running several nodes geographically around the world and i am watching the mempool count, they all update within 1 second apart
08:55 < waxwing> yes. i think it did get much better. actually, hmm, i think i am confused, and actually remembering *block* propagation, which is a different thing entirely.
08:55 <+JoinMarketRelay> [hackint/person] it was just an idea. using a tx with minimum fee and inserting the msg inside them
08:56 <+JoinMarketRelay> [hackint/person] i am talking about tx propagating in mempools of all nodes
08:56 < waxwing> yes i know you are.
08:56 <+JoinMarketRelay> [hackint/person] actual blocks that takes a bit longer because nodes need to verify thousands of txs at once
08:56 < waxwing> yes i know.
08:57 <+JoinMarketRelay> [hackint/person] omnicore is abusing bitcoin blockchain for years using OP_RETURN
08:58 < waxwing> afaik the existing abuses of OP_RETURN actually involved confirming txs? The idea of using it as messaging and then invalidating .. how do you invalidate?
08:58 < waxwing> without more txs?
08:59 < waxwing> of course "abuses" .. let's leave to one side whether that is a valid pejorative :)
09:01 <+JoinMarketRelay> [hackint/person] yes omnicore is using confirmed txs, i wanted unconfirmed so that nothing would be actually spent, just the mempool would be exploited for messaging. well if the fee is very low it wouldn't confirm. or if the input was used that later would be used in a JM then the original tx wouldn't confirm either
09:01 < waxwing> if the fee is too low to not confirm then it's *usually* too low to relay.
09:01 < waxwing> the problem here is you're trying to do something that the bitcoin p2p layer actively tries to prevent.
09:02 <+JoinMarketRelay> [hackint/person] there is this spam going on quite regularly, surely you noticed. you receive a 547 satoshis tx
09:02 <+JoinMarketRelay> [hackint/person] ads for bitcoin sv i think it is
09:03 <+JoinMarketRelay> [hackint/person] so when i get this 547 utxos i just burn it by sending it to OP_RETURN (the only output). it gets relayed and confirmed, 547 is the fee, tx amount is 0
09:05 < waxwing> just as a side note, our software has a specific feature for that (see https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse )
09:05 <+JoinMarketRelay> [hackint/person] and i even put inside a text in the OP_RETURN, 80 bytes
09:05 < waxwing> feel free to investigate but i think what i said above still 100% stands.
09:05 < waxwing> it's not viable imo, but happy to be proven wrong :)
09:06 <+JoinMarketRelay> [hackint/person] but adress reuse is for incoming, we are talking about outgoing
09:08 < waxwing> when people got these 1Enjoy 1Sochi back in the day, or whatever the new one is, they get sent to an address that was already used.
09:09 < waxwing> so it's related to both incoming (you get dust incoming to an address you have used in the past), and outgoing if you do as you did, spend in an OP_RETURN or elsewise.
09:10 <+JoinMarketRelay> [hackint/person] yes you mean the spam, that's incoming and if people aren't careful they may sweep it and they could be tracked that way. so everytime i receive it i burn it
09:10 <+JoinMarketRelay> [hackint/person] when i only send the spam back then i am not risking anything
09:11 < waxwing> yes
09:11 <+JoinMarketRelay> [hackint/person] and i get to write text in the blockchain forever and ever
09:11 <+JoinMarketRelay> [hackint/person] for free
09:12 <+JoinMarketRelay> [hackint/person] it looks like this: https://bitcoinsays.com/9d6959c3de441f26ec25baa824476a1bca0d9407381f414732e58a70c0a03559
09:12 <+JoinMarketRelay> [hackint/person] i sent dozens of these
09:15 < waxwing> so i'm going to shamelessly repeat this earlier message:
09:15 < waxwing> see https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.0 i will post to mastodon shortly, feel free to do so on other channels and update IRC etc
09:22 <+JoinMarketRelay> [hackint/person] i really think the throttling warnings are from the irc server, not JM. this is definitely from irc server: "[DEBUG]  (unhandled) noticed:  guybrush.hackint.org ... *** You are exempt from DNS blacklists" and a throttling message looks the same: "[DEBUG]  (unhandled) noticed:  guybrush.hackint.org ... *** Message to ... throttled due to flooding"
09:23 < waxwing> yes, they are. that was never in question.
09:27 <+JoinMarketRelay> [hackint/person] not by you
09:33 <+JoinMarketRelay> [hackint/person] can FB be switched off in yg?
10:41 -!- SomeFellow [~SomeFello@194.54.28.203] has joined #joinmarket
10:50 < SomeFellow> It really is like pulling teeth, finding any information whatsoever about how to run stuff through Tor (except that damn browser). Almost feels purposeful. Can anyone point me to a guide on how to run things in general (or, better yet, JM and Bitcoin Core in particular) through Tor?
10:52 < JMBridge> [agora/coinjoin] Bitcoind somefellow: onlynet=onion proxy=127.0.0.1:9050
10:52 < JMBridge> [agora/coinjoin] Bitcoind somefellow: onlynet=onion proxy=127.0.0.1:9050
10:53 < SomeFellow> I assume I have to install something first, but what? The browser?
10:54 < JMBridge> [agora/coinjoin] For JM you just uncomment (remove the line prefix #) for the tor socks port lines in messaging servers joinmarket.cfg search [MESSAGING:server1] #for tor socks5 = true
10:54 < JMBridge> [agora/coinjoin] For JM you just uncomment (remove the line prefix #) for the tor socks port lines in messaging servers joinmarket.cfg search [MESSAGING:server1] #for tor socks5 = true
10:54 < JMBridge> [agora/coinjoin] You like to run tor as deamon or service on windows. tor browser bundles it, but it will only run while the browser is running.
10:55 < JMBridge> [agora/coinjoin] You like to run tor as deamon or service on windows. tor browser bundles it, but it will only run while the browser is running.
10:55 < JMBridge> [agora/coinjoin] Whats your platform/os?
10:55 < JMBridge> [agora/coinjoin] Whats your platform/os?
10:56 < SomeFellow> Currently running JM on Linux Mint, so I guess I'll start with that one.
10:56 < JMBridge> [agora/coinjoin] Install tor as deamon with "sudo apt install tor"
10:57 < JMBridge> [agora/coinjoin] It will run on port 9050 tor browser uses 9150 by default
11:10 < SomeFellow> Can I stick the onlynet=onion proxy=127.0.0.1:9050 part in bitcoin.conf, and will it apply to everything in a normal Core install (qt and whatnot)?
11:13 < JMBridge> [agora/coinjoin] Yes, if you use bitcoinqt you can also goto => settings => config => network: switch only tor on. disable ipv4&ipv6. set proxy to your tor port
11:15 <+JoinMarketRelay> [hackint/s45rutz7e] Bitcoin Core install same config for qt
13:04 < SomeFellow> Couldn't get Core working right through Tor (no peers after 30m), so I reverted the changes and changed system Network settings to route all traffic through Tor instead. Any reason why that might be a bad idea?
13:05 < SomeFellow> (I only use that machine for JM anyway)
13:07 < SomeFellow> Is there any way I can confirm that everything is going through Tor?
13:59 -!- jungly [~jungly@gateway/tor-sasl/jungly] has joined #joinmarket
14:08 < SomeFellow> Okay, new problem, this time trying to install JM. "ERROR: Could not install packages due to an EnvironmentError: Missing dependencies for SOCKS support." Guessing it has something to do with the Tor stuff, since I've never gotten that one before. What dependencies does it want?
14:22 -!- jungly [~jungly@gateway/tor-sasl/jungly] has quit [Remote host closed the connection]
15:55 <+JoinMarketRelay> [hackint/person] SomeFellow if you disable tor in bitcoind and route all machine traffic through tor it's not the same. you will achieve bitcoind connecting to clearnet nodes via tor, instead of your bitcoind connecting to other tor nodes via tor
15:57 <+JoinMarketRelay> [hackint/person] same for JM. they both will not connect to tor hidden services if they don't know they can (if they aren't configured for tor socks)
16:00 <+JoinMarketRelay> [hackint/person] plus with all machine traffic routing through tor you most probably didn't configure tor's dns as a machine's dns, and neither you setup iptables rediction, so you cannot connect to .onion addresses at all
16:09 < SomeFellow> Makes sense. Guess I'll keep trying then.
16:09 <+JoinMarketRelay> [hackint/person] if you tell me specific problem you are having i could help
16:15 < SomeFellow> Right now, I'm trying to set up Bitcoin Core and JM to go through Tor on Linux Mint. So far, I've installed Tor, added onlynet=onion proxy=127.0.0.1:9050 to bitcoin.conf, and tried to install JM 0.9.0 ("ERROR: Could not install packages due to an EnvironmentError: Missing dependencies for SOCKS support.")
16:17 <+JoinMarketRelay> [hackint/person] tor with default torrc, after tor (re)start verify from the logs that it bootstraps to 100% and in the logs it should also mention the socks port
16:17 < SomeFellow> Last time I tried to get COre working, I didn't have any peers after waiting ~30m, so I reverted the conf and tried the system traffic thing instead. Just reverted Network settings, re-added the onlynet stuff, and waiting to see if it works this time.
16:20 <+JoinMarketRelay> [hackint/person] if tor is definitely working then you can try to add forcednsseed=1 to bitcoin.conf and possibly some addnodes, but you can try those in the console
16:20 <+JoinMarketRelay> [hackint/person] but first make sure tor is definitely working and listening on the socks port
16:25 <+JoinMarketRelay> [hackint/person] if tor is working and bitcoin.conf is setup you can watch ~/.bitcoin/debug.log for connect errors while you manually add a tor node via bitcoin console, or via bitcoin-cli, like so: "addnode=something.onion:8333 add", replace "something" with any hostname from https://bitnodes.io/nodes/?q=onion
16:42 <+JoinMarketRelay> [hackint/person] belcher waxwing_ it seems JM yg is crashing with "Invalid private key" when it's supposed to use unlocked unfrozen FB utxo, full log: https://pastebin.com/9aRztD7p
16:47 <+JoinMarketRelay> [hackint/person] it shouldn't even be possible to unlock&unfrozen my FB because it's too early, there could be a timezone problem
16:51 < SomeFellow> Okay, I decided to try addnode first, and it successfully added one. After about 10 minutes, the peer list was populated with several more nodes, and the blockchain was up to date. I'm currently trying to install JM again, and no big red error messages so far.
16:56 <+JoinMarketRelay> [hackint/person] great, it will save tor nodes in peers.dat so the next tiem it starts it will be faster. also if you want to be considerate you could add listenonion=1 in bitcoin.conf so that other tor bitcoind nodes can connect to your node
17:11 < SomeFellow> JM installed successfully this time. So how do I run it through Tor? Just uncomment the four lines under #for tor? Should I change the port to 9050?
17:13 < SomeFellow> Ah, looks like there are two #for tor sections, once with 4 lines and one with 2.
17:13 < SomeFellow> (Not counting Agora)
17:13 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
17:15 <+JoinMarketRelay> [hackint/person] yes uncomment 4 and 2 lines
17:17 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 256 seconds]
17:18 <+JoinMarketRelay> [hackint/person] it's only using tor for irc communication, everything else it's doing via localhost rpc communication to your local bitcoind
17:19 <+JoinMarketRelay> [hackint/person] also uses tor for payjoins
17:27 < SomeFellow> So leave the port as is?
17:27 < SomeFellow> (except uncommented, of course)
17:27 <+JoinMarketRelay> [hackint/person] which port? in the irc sections?
17:28 <+JoinMarketRelay> [hackint/person] "socks5_port = 9050" is already there, no?
17:28 <+JoinMarketRelay> [hackint/person] i don't think you need to change any port anywhere
17:34 < SomeFellow> So it is. The one with four lines has a "port=6667", and since it was under the #for tor header, I figured I might as well ask.
17:35 <+JoinMarketRelay> [hackint/person] nono, you aren't changing anything, just uncommenting. (if unsure you can start from the default joinmarket.cfg again) then just try to start ob-watcher (cd joinmarket-clientserver; source jmvenv/bin/activate; cd scripts/obwatch; python ob-watcher.py) and see whether it connects. you can change log level from INFO to DEBUG in the .cfg to see irc
17:35 <+JoinMarketRelay> connecting messages
17:51 < SomeFellow> Everything seems to be working. Thanks to everyone who helped me.
18:06 < xyy> yo, quick question before I get started here .. what is the logging policy? are logs ever deleted? 
18:07 <+JoinMarketRelay> [hackint/person] https://gnusha.org/joinmarket/
18:08 < xyy> seems they are deleted every 5 years (:P)
18:08 <+JoinMarketRelay> [hackint/person] or the logging started 5 years ago
18:10 -!- SomeFellow [~SomeFello@194.54.28.203] has quit [Quit: Connection closed]
18:10 < xyy> okay let's keep this non-controversial then... so if a hypothetical maker (`./yg-privacyenhanced.py`) decides that the wallet has too man mixdepths, would it be a clean solution to just sweep the extra mixdepths (via mini-coinjoin into the desired mixdepths) and then call the maker script with `--mixdepth=X` (where X is the reduced depth)?
18:11 < xyy> or is there some reason why a new wallet should be created instead?
18:13 <+JoinMarketRelay> [hackint/person] i personally would never ever do any kind of sweep, if i needed to move coins to lower depths i would just use yg with maybe a tiny modification
18:15 < xyy> okay fair. btw the people on hackint, assume you're over there because they have an .onion ?
18:15 <+JoinMarketRelay> [hackint/person] yes i am connected via tor to hackint's onion address
18:18 < xyy> ncwkrwxpq2ikcngxq3dy2xctuheniggtqeibvgofixpzvrwpa77tozqd.onion:6667 for the curious
18:18 <+JoinMarketRelay> [hackint/person] there is a short howto at https://www.hackint.org/transport/tor
18:20 <+JoinMarketRelay> [hackint/person] you can use acyclic yg script, just reverse the order of balances it returns if you want to move from higher depths to lower
18:27 < xyy> wouldn't that end up combining mixdepths quickly?
18:27 < xyy> I would still have to tell it to stop using certain depths going forward so it can cycle
18:28 < xyy> so, I don't want multiple depth to suddenly get combined in depth 0
18:28 < xyy>  * so, I don't want multiple depths to suddenly get combined in depth 0
18:29 < xyy> and I don't want funds to cycle back to depth N (which is greater than what I want to use)
18:32 < xyy> alternatively, if the hypothetical maker doesn't want to sweep, he could also send UTXOs one-by-one if there are not too many of them in the too-high mixdepths
18:32 <+JoinMarketRelay> [hackint/person] so first you wanted to sweep everything at once and deanonymize your hard-mixed coins and now you don't want to move them coin by coin?
18:32 < xyy> well I'm not sure what algorithm you have in mind exactly, I'm guessing
18:33 < xyy> reversing the direction sounds cool, but something needs to happen after coins hit depth 0 
18:33 <+JoinMarketRelay> [hackint/person] you can setup precisely from which mixdepth to which mixdepth you want your coins to move within yg, it's a matter or 1 line change
18:34 < xyy> okay now your algorithm becomes more defined 
18:35 <+JoinMarketRelay> [hackint/person] acyclic is moving all coins from lower levels to the highest level and then it just stops. you would simply reverse the order, so it would step by step moved everything lower and then you would just switch to an ordinary yg. but again, you can set anything anyway you want, if you know basic python
18:35 <+JoinMarketRelay> [hackint/person] it's in a custom scripts git
18:35 < xyy> so you admit that some tweaking is recommended. I'm OK with that. But initially it sounded like it was just changing one line. 
18:36 <+JoinMarketRelay> [hackint/person] yes it is changing just one line
18:36 < xyy> okay I"m too lazy to solve this communication problem :P
18:36 < xyy> thank you
18:36 <+JoinMarketRelay> [hackint/person] there is no communication problem
18:37 < xyy> thank you sir I got the inspiration that I needed
18:50 <+JoinMarketRelay> [hackint/person] if m > 0 should do the trick
18:50 <+JoinMarketRelay> [hackint/person] almost
18:59 <+JoinMarketRelay> [hackint/person] and input_mixdepth - 1 in select_output_address()
21:04 <+JoinMarketRelay> [hackint/x8all] h4ck 7h3 pl4n37
22:15 -!- technonerd [~techno@user/technonerd] has quit [Ping timeout: 244 seconds]
22:29 -!- technonerd [~techno@user/technonerd] has joined #joinmarket
22:42 -!- BUSY [~BUSY@user/busy] has quit [Ping timeout: 240 seconds]
22:44 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Ping timeout: 244 seconds]
22:46 -!- BUSY [~BUSY@user/busy] has joined #joinmarket
--- Log closed Sun Aug 01 00:00:25 2021