--- Log opened Wed Jan 27 00:00:27 2021
01:28 -!- Evanito [~Evanito@cpe-76-87-174-228.socal.res.rr.com] has quit [Read error: Connection reset by peer]
02:00 -!- belcher_ is now known as belcher
02:37 -!- openoms [~quassel@91.132.136.76] has quit [Read error: Connection reset by peer]
02:38 -!- openoms [~quassel@91.132.136.76] has joined #joinmarket
05:13 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket
05:38 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 264 seconds]
05:49 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has quit [Remote host closed the connection]
05:50 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has joined #joinmarket
05:57 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket
08:00 < dc81> i have 2 utxos missing from the wallet-tool script, change-out and cj-out, from the yg. it shows up when i run the history option with an error saying the balance doesn't match. and when i increase the gap limit, it only increases for the external not internal addresses.
08:01 < dc81> i did a partial rescanblockchain around the blocks the utxo was confirmed and the debug log shows the AddToWallet txid
08:37 -!- schmidty [sid297174@gateway/web/irccloud.com/x-bcmslhjuomznedcf] has quit [Ping timeout: 240 seconds]
08:37 -!- MemeFarmer____ [sid414248@gateway/web/irccloud.com/x-nsqpxzzyxheatuyz] has quit [Read error: Connection reset by peer]
08:37 -!- Galvas [sid459296@gateway/web/irccloud.com/x-bwbwszkdaytmfgex] has quit [Read error: Connection reset by peer]
08:37 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-titxuhgfyqxjhksy] has quit [Ping timeout: 264 seconds]
08:38 -!- davterra [uid458765@gateway/web/irccloud.com/x-lhpbswxfklwpxape] has quit [Read error: Connection reset by peer]
08:39 -!- MemeFarmer____ [sid414248@gateway/web/irccloud.com/x-tehgdzcocttjcapv] has joined #joinmarket
08:39 -!- schmidty [sid297174@gateway/web/irccloud.com/x-xvvlfkntomjeacbw] has joined #joinmarket
08:42 -!- Galvas [sid459296@gateway/web/irccloud.com/x-oxwszmwkhmipkqtn] has joined #joinmarket
08:45 -!- davterra [uid458765@gateway/web/irccloud.com/x-buyeoafdljnffbjr] has joined #joinmarket
08:45 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-pmhrwtnemkaumrrh] has joined #joinmarket
09:17 < belcher> dc81 it means theres unconfirmed transactions
09:37 < waxwing> wallet-tool's default method display doesn't list unused internal addresses, by intent (because deposits should be to unused external, not unused internal)
09:37 < waxwing> you can use displayall to see all addresses up to current index
09:39 < dc81> the transaction is confirmed
09:40 < waxwing> (also, unconfirmed coins do show up in wallet-tool anyway)
09:42 < waxwing> dc81, perhaps you could try --recoversync option to wallet-tool?
09:43 < waxwing> (this is generic advice for cases where default sync method doesn't work, but of course not addressing what reason there might be for it not working; it certainly shouldn't suddenly start failing if nothing has changed ...)
09:44 < dc81> i've done the recoversync several times
09:44 < waxwing> ok.
09:44 < dc81> using display all
09:45 < waxwing> so do we know that those two addresses are imported into the Core wallet that you're using (i.e. what you set for rpc_wallet_file)
09:45 < dc81> m/84'/0'/2'/1/19        XXXX      0.00000000      used
09:45 < dc81> XXXX balance is not 0.000
09:45 < waxwing> so, the addresses are marked used, but the balance is zero and you expect it should still hold coins.
09:45 < waxwing> and your total is less than expected by that amount.
09:45 < dc81> there is a balance on that address with 1 utxo
09:46 < dc81> it's 2 addresses (one is a cj-out and other is change-out)
09:46 < waxwing> yes i see. i'm trying t grok the significance of 'used' here.
09:47 < dc81> both addresses show a balance with 1 transaction in any explorer
09:47 < waxwing> yes i got it
09:50 < waxwing> just a sanity check, if you do `showutxos` it doesn't show the utxos you're referring to?
09:50 < waxwing> dc81, 
09:51 < dc81> running now
09:52 < dc81> not showing up in showutxos
09:53 < waxwing> had the wallet previously done coinjoins? i'm guessing yes, and in which case are you aware of any delta for this latest transaction?
09:53 < waxwing> delta in execution environment let's say
09:53 < dc81> this wallet has been running since 0.8 was released with no updates
09:53 < waxwing> all i know is right now the syncing method is simply failing to find those utxos.
09:54 < waxwing> i see that's useful thanks
09:54 < dc81> the cj was low fee so it sat in the mempool for a while
09:56 < dc81> i noticed the discrepancy a few days ago, so not sure if the utxos were ever recognized when the cj happened
09:56 < dc81> running history:
09:56 < dc81> BUG ERROR: wallet balance (XX) does not match balance from history (YY)
09:56 < dc81> BUG ERROR: wallet utxo count (XX) does not match utxo count from history (YY)
09:59 < waxwing> when you do bitcoin-cli gettransaction <txid> do you see a label?
09:59 < waxwing> and if so is it 'joinmarket-wallet-XXXXX'?
09:59 < waxwing> (it's in the 'details' section)
10:02 < waxwing> also do you have any setting for `listunspent_args` in joinmarket.cfg and if so what is it?
10:04 < waxwing> and also, related, if you do `bitcoin-cli listunspent` without arguments, (probably pipe it to a file, it may be relatively large), can you find the given transactionid:index entries for the addresses you expect?
10:06 < dc81> don't see a label
10:07 < waxwing> ok. but you have a section like this?:
10:07 < waxwing> "details": [
10:07 < waxwing>     {
10:07 < waxwing>       "involvesWatchonly": true,
10:07 < waxwing>       "address": "bcrt1qmulphug0f3hkwekwxlg3ujjwpfutxdfjfnh2kn",
10:07 < waxwing>       "category": "send",
10:07 < waxwing>       "amount": -2.00000000,
10:07 < waxwing>       "label": "joinmarket-wallet-b5156d",
10:07 < waxwing>       "vout": 0,
10:07 < waxwing>       "fee": -0.00003280,
10:07 < waxwing>       "abandoned": false
10:07 < waxwing>     }
10:08 < dc81> is that from the listunspent?
10:09 < waxwing> no, gettransaction <txid>
10:09 < waxwing> see my first question after your history quote
10:10 < dc81> the details block is empty
10:10 < waxwing> oh. interesting.
10:11 < dc81> bitcoin-cli gettransaction XX
10:11 < dc81> {
10:11 < dc81>   "amount": 0.00000000,
10:11 < dc81>   "confirmations": YY,
10:11 < dc81>   "blockhash": "YY",
10:11 < dc81>   "blockheight": YY,
10:11 < dc81>   "blockindex": YY,
10:11 < dc81>   "blocktime": YY,
10:11 < dc81>   "txid": "XX",
10:11 < dc81>   "walletconflicts": [
10:11 < waxwing> if you can find an older coinjoin tx and do the same thing, can you check that? it raelly shouldn't be empty!
10:11 < dc81>   ],
10:11 < dc81>   "time": tt,
10:11 < dc81>   "timereceived": tt,
10:11 < dc81>   "bip125-replaceable": "no",
10:11 < dc81>   "details": [
10:11 < dc81>   ],
10:11 < dc81>   "hex": "
10:11 < dc81> i did it for several txids.. all empty
10:12 < waxwing> is the amount really recorded as 0.0 or is that just equivalent of XXXX?
10:13 < dc81> it's recorded as 0
10:13 < waxwing> please also report on the other questions i asked (not that this isn't requiring further investigation - i personally don't understand right now)
10:14 < dc81> txid does not show up in listunspent
10:14 < dc81> grep listunspent_arg  ~/.joinmarket/joinmarket.cfg
10:14 < dc81> #listunspent_args = []
10:14 < dc81> #  spend from unconfirmed transactions:  listunspent_args = [0]
10:14 < dc81> # display only unconfirmed transactions: listunspent_args = [0, 1]
10:14 < dc81> # defend against small reorganizations:  listunspent_args = [3]
10:14 < dc81> #   who is at risk of reorganization?:   listunspent_args = [0, 2]
10:14 < waxwing> what version of Core are you using?
10:14 < dc81> 0.20
10:15 < waxwing> oh, just a thing, could you use gettransaction <txid> true
10:15 < waxwing> the true flag is  supposed to be for watchonly (for some weird reason it worked without it for me, possibly because regtest(?))
10:16 < dc81> ok, now details show up
10:17 < waxwing> is the address you're looking for (or 2) there?
10:17 < waxwing> if so, we can move on to listunspent. you are using listunspent_args default, so that's not a thing to worry about.
10:17 < dc81> yes, but this is odd.. 
10:18 < dc81> nvm... it used multiple inputs
10:22 < waxwing> what i can tell you without it being too ambiguous is: a utxo will be picked up by our `WalletService.list_unspent` method (part of sync process) only if the utxo is labelled with "joinmarket-wallet-XXXX" or "joinmarket-notify".
10:22 < waxwing> (the latter exists for rather obscure reasons related to sweeps)
10:22 < dc81> i'm sanitizing the details of the txid right now
10:22 < waxwing> no rush i'll be popping in and out
10:24 < dc81>   "details": [
10:24 < dc81>     {
10:24 < dc81>       "involvesWatchonly": true,
10:24 < dc81>       "address": "A1",
10:24 < dc81>       "category": "send",
10:24 < dc81>       "amount": -B1,
10:24 < dc81>       "label": "joinmarket-wallet-abcdefg",
10:24 < dc81>       "vout": n,
10:24 < dc81>       "fee": x,
10:24 < dc81>       "abandoned": false
10:24 < dc81>     },
10:24 < dc81>     {
10:24 < dc81>       "involvesWatchonly": true,
10:24 < dc81>       "address": "A2",
10:24 < dc81>       "category": "send",
10:24 < dc81>       "amount": -B2,
10:24 < dc81>       "label": "joinmarket-wallet-abcdefg",
10:24 < dc81>       "vout": n,
10:24 < dc81>       "fee": x,
10:24 < dc81>       "abandoned": false
10:24 < dc81>     },
10:24 < dc81>     {
10:24 < dc81>       "involvesWatchonly": true,
10:24 < dc81>       "address": "A1",
10:24 < dc81>       "category": "receive",
10:24 < dc81>       "amount": B1,
10:24 < dc81>       "label": "joinmarket-wallet-abcdefg",
10:24 < dc81>       "vout": n
10:24 < dc81>     },
10:25 < dc81>     {
10:25 < dc81>       "involvesWatchonly": true,
10:25 < dc81>       "address": "A2",
10:25 < dc81>       "category": "receive",
10:25 < dc81>       "amount": B2,
10:25 < dc81>       "label": "joinmarket-wallet-abcdefg",
10:25 < dc81>       "vout": n
10:25 < dc81>     }
10:25 < dc81>   ],
10:25 < dc81> this is from the gettransaction txid true with only my addresses in the detail block
10:31 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection]
10:32 < waxwing> (it's better to 0bin.net or similar if it's long.) labels in the listunspent output as per above?
10:32 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #joinmarket
10:33 < dc81> yes, same label in listunspent
10:36 < dc81> # of utxos from listunspent is the same as the wallet-tool
10:36 -!- Evanito [~Evanito@cpe-76-87-174-228.socal.res.rr.com] has joined #joinmarket
10:36 -!- jungly [~jungly@host-79-19-186-104.retail.telecomitalia.it] has quit [Ping timeout: 260 seconds]
10:39 < waxwing> oh so you see the correct label in listunspent? mysteriouser.
10:40 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/wallet_service.py#L737-L742
10:41 < dc81> so it's as issue on the bitcoind side
10:46 < waxwing> i honestly couldn't say yet.
10:46 < waxwing> (sorry for delays, eating)
10:56 < dc81> i can just spend the utxo and keep the change in the same mix depth?
11:00 < waxwing> dc81, could you hold off on that? would like to know what's happening
11:01 < waxwing> on line 741, after it, in the if block could you put:
11:01 < waxwing> `if utxo['address']="youraddress":
11:02 < waxwing>     jlog.info("Did not find address: {}".format("youraddress"))
11:02 < waxwing> ` .. and then see if it shows up when you re-run wallet-tool.py?
11:03 < waxwing> sorry == not =
11:07 < dc81> where does the jlog output to?
11:07 < waxwing> stdout
11:08 < waxwing> i mean print() works fine too here
11:08 < dc81> it didn't produce an output
11:08 < waxwing> i don't get it. were A1 and A2 the two addresses you're looking for?
11:09 < dc81> yes
11:10 < dc81> if utxo['address']=="A1":
11:10 < dc81>    jlog.info("Did not find address: {}".format("A1"))
11:11 < waxwing> ok sanity check; can you put the same check before the `is_known_addr` check? i.e. to see if it's at least examining that utxo from the listunspent output
11:12 < waxwing> if that utxo is not even in the listunspent output i'm completely flummoxed, because you said that doing bitcoin-cli listunspent shows it, and shows it with the right label
11:12 < dc81> sorry, it's not in listunspent
11:12 < dc81> the label is present
11:13 < waxwing> oh that makes more sense.
11:13 < dc81> that's why i mentioned it's probably on the bitcoind side
11:13 < waxwing> so bitcoind does not think that utxo exists.. it could be consistent with the `importaddress` rpc call not working.
11:13 < waxwing> yeah.
11:13 < waxwing> one somewhat feasible explanation is the above. importaddress call failed.
11:14 < waxwing> but that doesn't make sense with the 'receive' entries in gettransaction
11:14 < waxwing> because if those addresses weren't imported, it wouldn't recognize those as receive events.
11:16 < dc81> looking at the yg log, it shows `[MainThread  ] [INFO ]  Added utxos= ` and the two addresses
11:23 < waxwing> if import fails when getting the new address, the yg would shut down. so it doesn't seem that importmulti (importaddress) could have failed.
11:23 < waxwing> so as of right now i don't have a rational explanation why those utxos are not returned by listunspent
11:23 < waxwing> dc81, 
11:28 < dc81> that's fine.. i'm okay with just spending that utxo so i can get the liquidity back
11:31 < waxwing> up to you but i have no understanding of what caused it so i don't know if it will happen again.
11:33 < belcher> if `importaddress failed` is really what happened, what you could do is run `importaddress <youraddress> "" false`
11:33 < belcher> and then use `importprunedfunds` to add your transaction
11:33 < belcher> or possibly `rescanblockchain`
11:33 < waxwing> right; but it can't be, for at least the reason that the script would shut down.
11:33 < waxwing> i think he rescanned already but either way.
11:34 < dc81> i didn't do a full rescan
11:34 < belcher> well just a rescan around the block heights where the transaction is
11:34 < belcher> rescanblockchain has a start and end height option
11:34 < belcher> assuming you node isnt pruned
11:35 < belcher> however you'd need to importaddress first, if you rescanned before but the address wasnt imported then the tx wouldnt show up
11:35 < dc81> yeah, i scanned around the blocks it was confirmed as well as the blocks the inputs were originally confirmed
11:36 < dc81> and gettransaction recognized the address
11:36 < waxwing> yes everything makes sense except for (a) the transaction is confirmed and (b) it doesn't show up in listunspent. given the gettransaction output that makes no sense to me.
11:37 < waxwing> (by "listunspent" i mean literally the rpc call with bitcoin-cli)
11:38 < waxwing> dc81, oh i suddenly had a thought
11:39 < waxwing> when you do the bitcoin-cli calls do you specify the rpcwallet name?
11:39 < waxwing> rpc calls that are for wallet methods need to specify the wallet iirc
11:39 < dc81> no
11:40 < waxwing> and do you have a value specified in `rpc_wallet_file` in joinmarket.cfg?
11:40 < dc81> wallet.dat
11:40 < waxwing> do you see all the other joinmarket coinjoin utxos/entries in the output of listunspent?
11:41 < dc81> yes
11:41 < belcher> you can use `listwallets`
11:41 < dc81> bitcoin-cli listwallets
11:41 < dc81> [
11:41 < dc81>   "wallet.dat"
11:41 < dc81> ]
11:46 < dc81> bitcoin-cli listunspent | grep joinmarket-wallet- | wc -l
11:46 < dc81> NN
11:46 < dc81> python wallet-tool.py wallet.jmdat history
11:46 < dc81> BUG ERROR: wallet utxo count (NN) does not match utxo count from history (NN+2)
11:47 < waxwing> belcher knows the history code (i don't unfortunately), but i agree that's an interesting data point.
11:48 < belcher> history deals with confirmed transactions only, display has unconfirmed, thats usually why that message appears
11:48 < belcher> but yes the message would also appear if a UTXO is really missing
11:48 < dc81> i currently have no unconfirmed transactions
11:50 < belcher> did you already try `importaddress` and then `rescanblockchain` ? its worth a try if you havent
11:55 < waxwing> he said he did. also the gettransaction output seems to prove that the addresses were imported.
11:55 < waxwing> but in this case i state nothing with certainty.
11:56 < dc81> i did not importaddress
11:56 < dc81> but getaddressinfo show "iswatchonly": true
11:56 < waxwing> right, you said you did recanblockchain though (more than once, heh) and as i've been trying to explain in detail, the gettransaction output at least, plus the fact the script didn't crash, indicates very strongly that the import happened, and did not fail.
11:56 < belcher> ah ok
11:57 < dc81> not from block 0
11:57 < waxwing> oh getaddressinfo, i was wondering what the call was for that. cool.
11:57 < dc81> iirc, importaddress does a rescan from block 0
11:57 < belcher> the gettransaction output could also mean that one of the addresses of the _inputs_ is imported
11:57 < belcher> but getaddressinfo "iswatchonly": true, seems to clinch it and it means that it was indeed imported
11:57 < waxwing> belcher, yes i'm well aware :) but we got the listings for receive events for the two addresses.
11:58 < waxwing> the extremely tricky behaviour of the Core wallet with regard to this stuff has already taken like 200 hours of my time by now probably, lol.
11:58 < waxwing> and i still don't understand all of it.
11:59 < waxwing> here's one thing that was a real headscratcher at one point: "I have found that the RPC listtransactions will not show send-category transactions if you specify a particular wallet label (joinmarket-XXXXX); but if you specify no label with "*", it does show send-category transactions."
12:00 < waxwing> that might just be me misunderstanding some detail, it was something i was investigating recently.
12:25 -!- jungly [~jungly@host-79-19-186-104.retail.telecomitalia.it] has joined #joinmarket
13:39 -!- jungly [~jungly@host-79-19-186-104.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds]
13:51 -!- keithhub[m] [keithhubma@gateway/shell/matrix.org/x-unimgndnzlllqksj] has quit [Ping timeout: 240 seconds]
13:51 -!- tiker[m] [tikerfunky@gateway/shell/matrix.org/x-rgmmkctcuycbnkek] has quit [Ping timeout: 265 seconds]
14:21 < undeath> waxwing: yes, that behaviour is documented in the bitcoind documentation
14:21 < undeath> "If set, should be a valid label name to return only incoming transactions"
14:23 < undeath> that probably means jm should always do listtransactions with "*" and do client-side filtering
14:25 < undeath> or possibly use listunspent instead?
14:29 -!- Netsplit *.net <-> *.split quits: undeath
14:30 -!- Netsplit over, joins: undeath
14:34 -!- asy [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket
14:34 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Remote host closed the connection]
14:35 -!- asy is now known as asymptotically
15:01 < waxwing> undeath, oh, thanks. and yes, we do use "*"; see BitcoinCoreInterface.list_transactions and also _yield_transactions (which istr you wrote :) )
15:01 < waxwing> i didn't spot that in the docs, but i'm still pretty confused about why it's like that.
15:07 < waxwing> (it case it confuses anyone, that sidebar about listtransactions is not related to our earlier debugging attempts; they were about listunspent not returning utxos for addresses that were clearly imported into the wallet)
15:27 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Ping timeout: 268 seconds]
15:29 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket
15:30 < qubenix> if a tx confirms after the confirm_timeout_hours, it seems as though it doesn't make it into yigen-statement.csv. is there any negative consequences to setting confirm_timeout_hours to something a lot longer, like a month or more?
15:32 < waxwing> i don't think so qubenix 
15:37 -!- tiker[m] [tikerfunky@gateway/shell/matrix.org/x-epgpbssiasdmjozl] has joined #joinmarket
15:41 < qubenix> ty waxwing 
15:45 -!- M1 [~Michail@michail.com] has quit [Ping timeout: 240 seconds]
15:47 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 3.0]
15:50 -!- M1 [~Michail@michail.com] has joined #joinmarket
16:16 -!- keithhub[m] [keithhubma@gateway/shell/matrix.org/x-lltznfhgnkocfywu] has joined #joinmarket
16:25 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 260 seconds]
16:51 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
16:54 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket
17:40 -!- DSRelBot [~DSRelBot@p5de4a822.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
17:40 -!- HackRelay [~jmrelayha@p5de4a822.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
17:50 -!- DSRelBot [~DSRelBot@p5de4a9b8.dip0.t-ipconnect.de] has joined #joinmarket
17:54 -!- HackRelay [~jmrelayha@p5de4a9b8.dip0.t-ipconnect.de] has joined #joinmarket
18:21 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-pmhrwtnemkaumrrh] has quit [Ping timeout: 256 seconds]
18:22 -!- HackRelay [~jmrelayha@p5de4a9b8.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
18:22 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-siqumvfebeajhqkl] has joined #joinmarket
18:38 -!- HackRelay [~jmrelayha@p5de4a9b8.dip0.t-ipconnect.de] has joined #joinmarket
21:14 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has quit [Remote host closed the connection]
21:15 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has joined #joinmarket
21:37 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket
21:40 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
22:48 -!- Michail1 [~Michail@michail.com] has joined #joinmarket
22:48 -!- johnhmay_ [sid110431@gateway/web/irccloud.com/x-wwciwutvvyvxnhkc] has joined #joinmarket
22:49 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-siqumvfebeajhqkl] has quit [Ping timeout: 256 seconds]
22:49 -!- M1 [~Michail@michail.com] has quit [Ping timeout: 256 seconds]
22:49 -!- DSRelBot [~DSRelBot@p5de4a9b8.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
22:49 -!- Michail1 is now known as M1
22:49 -!- johnhmay_ is now known as johnhmay
23:04 -!- DSRelBot [~DSRelBot@p5de4a9b8.dip0.t-ipconnect.de] has joined #joinmarket
23:22 -!- jungly [~jungly@host-212-171-252-80.retail.telecomitalia.it] has joined #joinmarket
23:57 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #joinmarket
23:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]
--- Log closed Thu Jan 28 00:00:28 2021