--- Log opened Wed Mar 03 00:00:45 2021
01:25 < waxwing> Evanito[m], just to be clear it's `snicker-finder.py` that finds coinjoins, but only if you use the `-j` flag. sorry that this is obscure, but it was only actually *needed* for snicker; it seems i accidentally added something that people really do want, although as a JM user myself i never felt it was useful for more than curiosity :)
01:25 < waxwing> (location: `scripts/snicker/snicker-finder.py`)
01:27 < waxwing> as for 'watching for !hp2 chatlines' - that is indeed an indication that some bots participated in an *attempted* coinjoin - but not the bots who announced it, other ones.
02:01 < DSRelBot> [DS/sr56jtdy] ty waxwing, works for me :) [INFO]  Found Joinmarket coinjoin transaction: dee9e2765542915f246cd5def8283d1105749b96ce06fbdeb7bee60c491ccf2a in block: 672963
02:10 -!- belcher_ is now known as belcher
03:19 < waxwing> yes, it's a very inefficient parser because in python, but it's fairly reliable in terms of the algo. if someone writes something better in C/C++ for speed, great, i'll happily redirect people to that.
03:20 -!- Coy2Mohr [~Coy2Mohr@static.57.1.216.95.clients.your-server.de] has joined #joinmarket
03:28 < openoms_> just signed a signet PSBT with the wallet-tool.py prepared with SpecterDesktop! Very smooth experience.
03:30 < openoms_> @belcher re how useful more hops are (they aren`t) https://twitter.com/OxoUtx/status/1268631334479704073
03:33 -!- Coy2Mohr [~Coy2Mohr@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 276 seconds]
03:39 < waxwing> openoms_, oh wow that's cool re: PSBT
03:39 < waxwing> so wait what exactly is going on? does specter sign with core and then you co-sign JM? or?
03:42 < openoms_> @waxwing I imported the 5 mixdepths to the watch only Specter wallet, built the txn with the gui, pasted the unsigned PSBT for wallet tool and could choose to broadcast with JM or back in Specter.
03:42 < waxwing> oh i see, so the value here is that in specter, you can build the transaction with the gui?
03:43 < waxwing> can it also work with inputs not signable by JM? Hmm i think we can only finalize, not sign without finalize, but i can't remember, let me check.
03:43 < openoms_> yes, my main usecase is funding lightning channels with PSBT-s including paytomany for batched opens.
03:43 < waxwing> right, those use cases sound great. can you show an example on signet? (or maybe you already did)
03:44 < waxwing> ah no, we can output from `signpsbt` either finalized or unfinalized.
03:45 < openoms_> just researching if there is an LN on signet yet. Not supported with LND yet: https://github.com/lightningnetwork/lnd/issues/5018
03:45 < waxwing> yeah right.
03:46 < openoms_> here is the transaction, but it si not particularly interesting I think: https://mempool.space/signet/tx/8dc02201e96ab7498d6a8cb7ab1151e6432e8353267426aecdfed5d1d6b5dc44
03:46 < openoms_> might have found  a Specer bug as well https://t.me/spectersupport/18764
03:46 < openoms_> *Specter
03:46 < waxwing> but even before that, you could maybe show an example of a batched payment where you had another wallet contribute inputs? and then JM finalizes with its own signatures?
03:47 < waxwing> so i don't know why i say 'batched payment' there, that itself is interesting, but i was actually talking about coinjoining two wallets under your control.
03:47 < openoms_> manual coinjoins? I'd just like batched lightning channel opens first.
03:48 < openoms_> and setting up the best way to use my JM wallet as a source 
03:48 < waxwing> right. but batched lightning channel opens are just batched payments, no?
03:48 < waxwing> oh because you have to link it to the lightning software.
03:48 < waxwing> yeah kristapsk looked into that at some point and so did I, though I never went far into it.
03:49 < openoms_> the biggest saving is on the input side. Ideally one input and couple of channel outputs (a change comes handy for CPFP ability)
03:50 < waxwing> manual coinjoin would be the biggest and clearest demonstration of the PSBT functionality itself, though.
03:51 < waxwing> doing a batched payment is not a huge deal, i guess it's just about it offering a better workflow .. many wallets can already do that, just as well or better, without PSBT.
03:51 < openoms_> does not even to be equal output right?
03:51 < waxwing> right we have a crappy script that just sends equal amounts; but that's because i couldn't be bothered to add more complex functionality
03:51 < waxwing> like electrum has, say
03:52 < waxwing> it didn't feel like something that was worth spending time on, albeit, it wouldn't be very hard.
03:52 < waxwing> but having things like PSBT is nice because you've opened up a big range of what you can create, using other software, and then sign.
03:52 < waxwing> tbh i didn't quite appreciate that before
03:53 < openoms_> exactly! Mixing the layers with ligthning is the most interesting for me.
03:53 < waxwing> users do need to be careful to review though, when other software is creating arbitrarily structured transactions.
03:53 < waxwing> if you stick inside one wallet, then that wallet software already knows how to be careful to only allow certain conditions.
03:55 < openoms_> yes, like Specter not having the labels JM has. Was asking if it could be possibel to import the Core wallet straight into Specter to preserve the labels: https://github.com/cryptoadvance/specter-desktop/issues/990
03:56 < waxwing> Yes I had a read of that issue, very interesting
03:57 < openoms_> do I think it right that the Core has the labels what JM shows like cj-out, change-out, new etc?
03:57 < waxwing> oh; no
03:57 < waxwing> the addresses are labelled `joinmarket-wallet-XXXXX`
03:57 < openoms_> sory, it's me not using the bitcoin-qt
03:57 < waxwing> where XXXXX is basically some intended-to-be-unique truncated hash of the wallet (it goes from the first address)
03:58 < waxwing> well i never use bitcoin-qt either :)
03:58 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/wallet.py#L859-L863
03:59 < waxwing> openoms_, so actually you were wanting that specter displays things like 'cj-out', huh.
03:59 < waxwing> that is done in software in JM, it's not stored even in the wallet file; maybe it should
04:00 < openoms_> yes, just what I was about to ask
04:00 < waxwing> really those labels are just indicative. labels like that are sometimes (often) a requested feature, i know e.g. wasabi people consider it really a requirement but we didn't, at least to start with.
04:01 < waxwing> i would be very open to a PR that just made it a user-specified thing, i.e. the user enters on Qt/command line the label that they want.
04:01 < waxwing> meanwhile having it persisted in file is nice but problematic, due to recovery.
04:01 < waxwing> yes of course in that scenario it would obviously have to be persisted to *.jmdat
04:02 < openoms_> so the labels must be based on basic transaction analysis? Like how JM tells the difference between a change-out and a  CJ out?
04:02 < waxwing> yes
04:03 < openoms_> if equal output -> cj-out; else ->  change-out :)
04:03 < waxwing> honestly i was kinda surprised when someone PR-ed that code but it was like, well OK that works well enough that it's not misleading so why not? clearly some people like having it, understandable
04:03 < waxwing> let me find the code ref for you
04:04 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/365ca38cc2a821039c501b31be264b0ecffaefef/jmclient/jmclient/wallet_utils.py#L313
04:04 < waxwing> that is used here:
04:06 < openoms_> so an output of a  manual CJ  (maybe using a PSBT) should still show up as a CJ-out. Same as when using sendpayment.py to CJ to a new address.
04:07 < waxwing> wait, i got disconnected, to continue:
04:07 < waxwing> that is used here:
04:07 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/wallet_utils.py#L412
04:07 < waxwing> (etc.. i'll lose the rest)
04:07 < waxwing> openoms_, yes it still should, but there is no pretense to perfect accuracy in labelling here.
04:08 < waxwing> if you do something weird, there is no guarantee it won't get a wrong label (and indeed it couldn't be otherwise, i think)
04:08 < openoms_> sure, now it is clear it is not something which can be imported to Specter. (but Specter could do a similar thing)
04:09 < waxwing> yeah +1
04:10 < openoms_> the other thing I like in Specter (and will stop shilling it) that it has the option to see the combined balance of multiple wallets. No grouping yet, but still very useful.
04:10 < openoms_> I get tired of managing JM wallets with Electrum for example.
04:11 < waxwing> yeah sounds good, but also sounds difficult :)
04:11 < waxwing> i mean for specter, not for the user
04:16 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]
04:16 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #joinmarket
04:30 < openoms_> @waxwing re > XXXXX is basically some intended-to-be-unique truncated hash of the wallet (it goes from the first address)
04:30 < openoms_> could we generate the label just from the first address in the JM wallet? In that case Specter could filter and  import the addresses  from the already used watch-only Core wallet.
04:30 < openoms_> Would only need acces to the wallet file and the first address.
04:40 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has quit [Remote host closed the connection]
04:41 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has joined #joinmarket
04:44 < openoms_> I couldn't find the code so far, but hope this is correct: https://github.com/cryptoadvance/specter-desktop/issues/990#issuecomment-789688295
04:48 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
04:48 < openoms_> getting there: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/365ca38cc2a821039c501b31be264b0ecffaefef/jmclient/jmclient/wallet.py#L859
04:53 < openoms_> hmm, is this where the usniques hash generated? https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/365ca38cc2a821039c501b31be264b0ecffaefef/jmclient/jmclient/wallet.py#L1889 
04:57 < openoms_> ok found it : https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/365ca38cc2a821039c501b31be264b0ecffaefef/jmclient/jmclient/wallet.py#L2250
05:13 < waxwing> openoms_, no that last link is specific to the fidelity bond wallet mixin
05:14 < waxwing> oh wait is that an overwrite? so it's changed?
05:14 < waxwing> belcher, ping ^
05:15 < waxwing> ah, no, the default wallets do not use that Mixin.
05:15 < belcher> _get_key_ident() is not specific to fidelity bond wallet mixins, but that mixin overrides it
05:16 < waxwing> so your earlier deduction was correct: line 1889; i.e. it uses the hash from bi32_priv_export
05:16 < belcher> it is the bip32 path
05:16 < belcher> m/key_ident/something/change/index
05:17 < waxwing> it's possible that my original 'from address' error (it's clearly not that) was because this changed after the wallet was refactored?
05:17 < waxwing> belcher, am i remembering that right? i have a feeling the first version of the wallets used a hash of the first address instead of this?
05:18 < belcher> i dont remember, but i think no
05:18 < waxwing> but yes i see in cryptoengine that it is indeed hashing the bip32 path
05:18 < belcher> i dont remember anything about hashing the address
05:18 < belcher> yes hashing the bip32 xpub maybe
05:18 < belcher> because then its effectively also stored in the seed phrase
05:19 < waxwing> no hang on isn't it hashing the private key?
05:19 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket
05:19 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/365ca38cc2a821039c501b31be264b0ecffaefef/jmclient/jmclient/cryptoengine.py#L167
05:22 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
05:22 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
05:24 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
05:27 < openoms_> then we can't just derive the wallet from the xpub. The wallet-tool could have a method to to show the label of the Core wallet maybe?
05:29 < belcher> fwiw i recently merged code into EPS which uses `getaddressinfo` instead of `getaddressesbylabel` to check if a wallet is already imported, its much faster and removes the need to actually use address labels
05:29 < belcher> thats an option for getting rid of labels if needed
05:29 < belcher> the label/account thing dates from a time before bitcoin core's multiwallet
05:31 < openoms_> right, it does not make much sense now to use watch-only core wallet for more then one connected wallet
05:35 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
05:35 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket
05:38 < openoms_> https://kycnot.me/
05:41 < belcher> also another similar site https://github.com/cointastical/P2P-Trading-Exchanges/
05:42 < waxwing> good point re: labels
05:43 < waxwing> openoms_, yeah the wallet label is output from some tool at some point but we for sure should/could add it as output to wallet-tool. let me check.
05:48 < waxwing> ok the only place i see it being output is when you do `--recoversync` for wallet-tool and it outputs it in debug log messages
05:48 < waxwing> natural thing would be to just output it at the start of any wallet-tool method, after sync is finished
05:48 < waxwing> and/or of course add a getwalletname method
05:53 < openoms_> could be useful if someone (or an app) would want to filter the addresses in their bitcoin core wallet. Now could even use a unique wallet in core for every JM wallet which is related to: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/812
05:55 < waxwing> yeah i'm honestly not sure about 1 Core wallet vs several. it seems like users would want one Core wallet for all JM activity, only because it would be tricky to manage it otherwise?
05:56 < waxwing> that's certainly what I do. One Core wallet for JM and a bunch of JM wallets. Even then it's annoying to have to remember not to mix up or use the wrong Core wallet in rpc_wallet_file (at least, as a tester, it is).
05:57 < openoms_> true, using more wallets would add a lot of complication. Then it makes even more sense to be able to extract the label used.
05:58 < waxwing> yeah i suppose it's a counterargument against no labels. to be clear, i haven't thought this through.
06:11 < waxwing> openoms_, just to be sure i checked: the code takes the first 3 bytes of the sha2 hash of the ascii-encoded xpriv for: (mixdepth 0, external(0)), i.e. m/84'/0'/0'/0 (for mainnet bech32)
06:17 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket
06:27 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 246 seconds]
06:28 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
06:42 -!- jonatack_ [~jon@37.172.59.183] has joined #joinmarket
06:42 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
06:43 -!- jm_noob [68251f5e@104.37.31.94] has joined #joinmarket
06:44 -!- jonatack_ [~jon@37.172.59.183] has quit [Client Quit]
06:45 < openoms_> thanks, so it is the private key
06:46 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
06:52 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 260 seconds]
06:54 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
07:10 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket
07:14 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Remote host closed the connection]
07:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
07:54 < jm_noob> Is the "correct" way to put a stash through JM to deposit one KYCed UTXO at a time in M0 and let it tumble all the way through M4 to 3 new external (cold storage) addresses? And then of course make sure the change output at the end of the tumble is handled correctly. Am I missing something?
07:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
08:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
08:11 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 245 seconds]
08:13 < waxwing> it depends on your timing but if you are happy for it to take a long time i would do a combination of (a) running tumbler and (b) running yg .. with (b) obviously being a long term process
08:14 < waxwing> doing (a) alone is clearly something, note that there is no change at the end, since JM allows you to use 'sweeps' that empty mixdepths
08:14 < waxwing> i would also strongly advise people to use long, even very long wait times with tumbler .. reason i say that is that you'll be in a significantly larger crowd of other coinjoins
08:15 < waxwing> for more general advice, you may find this helpful: https://joinmarket.me/blog/blog/the-445-btc-gridchain-case/index.html#recommendations
08:15 < waxwing> jm_noob, ^
08:22 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 260 seconds]
08:28 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
08:30 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
08:30 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
08:31 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
08:31 -!- jonatack_ [~jon@37.172.59.183] has joined #joinmarket
08:38 -!- jonatack_ [~jon@37.172.59.183] has quit [Quit: jonatack_]
08:44 -!- jonatack [~jon@37.172.59.183] has joined #joinmarket
09:01 -!- Netsplit *.net <-> *.split quits: fluffypony
09:07 -!- Netsplit over, joins: fluffypony
09:37 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
09:37 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
09:37 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
09:37 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
09:41 -!- berndj-blackout [~berndj@ns1.linksynergy.co.za] has joined #joinmarket
09:41 -!- berndj [~berndj@ns2.linksynergy.co.za] has quit [Read error: Connection reset by peer]
09:43 -!- berndj-blackout is now known as berndj
10:25 -!- jungly [~jungly@host-95-235-238-177.retail.telecomitalia.it] has quit [Ping timeout: 260 seconds]
11:06 < openoms_> @waxwing just thinking would it make more sense to base the wallet label on the hash of the xpub (instead of xpriv) in case in the future there would be watch only wallets possible in JM with the signing done externally (CKbunker for example)
11:06 < openoms_> Also then it would be possible to easily generate the core label in the knowledge of the xpub. I don't think that would be a privacy concern, would it?
11:09 -!- Saloframes [~Saloframe@2607:9000:2000:16::a44d] has quit [K-Lined]
11:11 < belcher> openoms_ i think actually fidelity bond wallets already use the xpub instead of the xprv, so that watch only wallets can be implemented
11:11 < belcher> however when coding fidelity bond wallets i didnt change it for regular wallets because otherwise people's existing wallet files would stop working
11:11 < belcher> might be remembering wrong, check the code, but im pretty sure thats right
11:16 < waxwing> belcher, i think the original version used private keys, do you remember why you did it like that?
11:17 < belcher> because im stupid xD i didnt think to allow for watch-only wallets
11:17 < belcher> in my defence this was in 2014 or something
11:18 < waxwing> i had a vague idea it might be because of some vague concern that it should not be derivable from xpubs or something like that
11:18 < waxwing> which, if even a coherent thought at all, is curious because it's almost the opposite :)
11:20 < belcher> well pretty soon afterwards the wallet-tool.py script would print out xpub keys, so it cant have been that we wanted to keep xpubs hidden
11:20 < openoms_> hmm if changed the existing wallets would stop working concern is a big one
11:20 < belcher> i think it was just a mistake on my part
11:21 < belcher> openoms_ however, the only time the wallet label is used is on startup when calling `getaddressesbylabel` i think, so if that were changed to use `getaddressinfo` instead then the label wouldnt matter
11:22 < waxwing> right it was not a particularly coherent thought :) it was a valid thought (correlation between Core wallets and xpubs that *were* shared), but not one of any practical significance
11:23 < waxwing> belcher, i'd have to think a bit about whether a refactor to remove labels entirely would never cause difficulties in how syncing and monitoring works
11:23 < waxwing> or a better way to say it is, it'd be a significant refactor. i'm reasonably sure of that without looking at code.
11:23 < waxwing> (assuming more than one JM wallet related to the Core wallet)
11:24 < belcher> do think about it, but i recently did it on EPS (which works basically the same way as joinmarket's wallet) and it was just a few lines
11:24 < belcher> possibly when joinmarket calls `listtransactions` then labels are involved, but if so you can change the labels to "*"
11:25 < waxwing> yes it may be that since the other checks exist (e.g. in transaction_monitor), like "is_our_address" (i forget the name), it's not an issue at all.
11:25 < belcher> right now joinmarket calls `getaddressesbylabel` to get a list of all the addresses that have been imported, for the change to check if an address is imported you call `getaddressinfo` and check if the field "iswatchonly" is true
11:25 < belcher> actually..
11:25 < waxwing> yeah but you're only looking at one part of the code
11:25 < belcher> i think the "forced address reuse" attack checker uses that list
11:25 < belcher> you know the one which freezes incoming UTXOs if they land on an already-used address
11:26 < belcher> i think
11:26 < waxwing> i mean sure. don't forget arch changed so we're always checking for new transactions, too.
11:31 < waxwing> hmm, on a first look through *that* code (the monitor/update) really just checks utxos so it's not relevant to that. but anyway thanks for the tip, it's a feasible change at some point, maybe very easy, maybe not.
11:45 -!- jm_noob [68251f5e@104.37.31.94] has quit [Quit: Connection closed]
11:53 -!- jungly [~jungly@host-95-235-238-177.retail.telecomitalia.it] has joined #joinmarket
11:54 -!- roshii [~roshii@248-39-178-143.ftth.glasoperator.nl] has joined #joinmarket
11:54 -!- roshii [~roshii@248-39-178-143.ftth.glasoperator.nl] has quit [Read error: Connection reset by peer]
11:55 -!- roshii [~roshii@248-39-178-143.ftth.glasoperator.nl] has joined #joinmarket
11:59 -!- jonatack_ [~jon@37.170.222.46] has joined #joinmarket
12:00 < roshii> since last update to 0.8.1 I see many blacklisted commitments and not a single signed transaction in my maker logs. I have in the meanwhile update the container running joinmarket so it could be something related to that as well. regardless, any tips, info about it is welcome :)
12:03 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 260 seconds]
12:10 < waxwing> roshii, i'm scanning the blockchain for the last day and so far activity looks pretty normal
12:11 < waxwing> getting 'commitment blacklisted' in your maker logs happens here and there if some taker out there has their setup misconfigured and keeps trying over and over
12:16 < roshii> it is more like a dozen 'commitment blacklisted' line once per hour in my case, which is why I suspect something wrong
12:19 < waxwing> well something is certainly wrong for them; to have that happen, they not only have to have too many tries or the wrong size utxo, they *also* have to have deliberatly misconfigured the software, since by default, the error will prevent them from even starting/sending you a message.
12:19 < waxwing> there weren't any changes to handling of commitments in 0.8.1 either.
12:24 < roshii> thanks for the details
12:25 < roshii> could it be something with accessing local files on my end or is it purely a taker misconfiguration?
12:26 < roshii> there is like 2 months I see only blacklisted commitments and not a single signature
12:27 < roshii> might have started before 0.8.1 now that I think about it 
12:27 < DSRelBot> [DS/J5F4cZCVKjo7moX8] i can only see two commitment blacklisted from last week
12:31 < waxwing> well if *you* changed the commitments_* config settings, that would also do it
12:31 < waxwing> sorry afk
12:31 < DSRelBot> [DS/J5F4cZCVKjo7moX8] how you got so many
12:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]
12:37 < roshii> can't recall having change any commitments settings, I even generated a fresh new config file
12:37 < roshii> but clearly, there is something wrong at my end, digging that up
12:38 < roshii> thanks for confirming occurrence at your end DSRelBot
13:23 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket
13:33 -!- Netsplit *.net <-> *.split quits: qubenix, GAit
13:34 -!- Netsplit over, joins: qubenix, GAit
13:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
13:58 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket
14:36 < waxwing> it doesn't really confirm that there's anything wrong your end
14:36 < waxwing> because the log message you're getting are from takers that requested a join with you; which won't be the same as for all other makers
15:13 -!- openoms [~quassel@91.132.136.76] has joined #joinmarket
15:14 -!- openoms_ [~quassel@91.132.136.76] has quit [Ping timeout: 265 seconds]
15:45 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]
15:45 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket
16:24 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has quit [Ping timeout: 256 seconds]
16:24 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has quit [Ping timeout: 256 seconds]
16:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
16:44 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 3.0.1]
16:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
17:01 -!- d [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket
17:01 -!- d is now known as Guest84735
17:02 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
17:04 -!- jungly_ [~jungly@host-212-171-255-115.retail.telecomitalia.it] has joined #joinmarket
17:05 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Quit: ZNC 1.8.2 - https://znc.in]
17:09 -!- jungly [~jungly@host-95-235-238-177.retail.telecomitalia.it] has quit [Ping timeout: 276 seconds]
17:09 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #joinmarket
17:15 -!- Guest84735 is now known as davterra
17:42 -!- DSRelBot [~DSRelBot@p5de4ab3c.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
17:42 -!- HackRelay [~jmrelayha@p5de4ab3c.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
17:55 -!- HackRelay [~jmrelayha@p5de4ab42.dip0.t-ipconnect.de] has joined #joinmarket
17:56 -!- DSRelBot [~DSRelBot@p5de4ab42.dip0.t-ipconnect.de] has joined #joinmarket
18:03 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket
18:03 -!- asy [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Ping timeout: 268 seconds]
18:04 -!- elector [~elector@gateway/tor-sasl/elector] has quit [Ping timeout: 268 seconds]
18:04 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has quit [Ping timeout: 268 seconds]
18:04 -!- elector [~elector@gateway/tor-sasl/elector] has joined #joinmarket
18:16 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has joined #joinmarket
18:29 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket
18:32 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
18:39 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]
19:07 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
19:07 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
19:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
19:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
19:34 -!- emzy [~quassel@unaffiliated/emzy] has quit [Ping timeout: 272 seconds]
19:43 -!- emzy [~quassel@2a01:4f8:192:628a::83] has joined #joinmarket
22:31 -!- deafboy_ [quasselcor@cicolina.org] has quit [Ping timeout: 265 seconds]
22:33 -!- deafboy [quasselcor@cicolina.org] has joined #joinmarket
22:37 < roshii> thanks again waxwing
22:41 -!- jungly_ [~jungly@host-212-171-255-115.retail.telecomitalia.it] has quit [Ping timeout: 276 seconds]
23:09 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 240 seconds]
23:12 -!- roshii [~roshii@248-39-178-143.ftth.glasoperator.nl] has quit [Ping timeout: 260 seconds]
23:12 -!- roshii [~roshii@84.241.194.232] has joined #joinmarket
23:24 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket
23:33 -!- roshii [~roshii@84.241.194.232] has quit [Ping timeout: 264 seconds]
23:34 -!- roshii [~roshii@248-39-178-143.ftth.glasoperator.nl] has joined #joinmarket
23:39 -!- jungly [~jungly@host-212-171-255-115.pool212171.interbusiness.it] has joined #joinmarket
23:40 -!- jonatack_ [~jon@37.170.222.46] has quit [Ping timeout: 260 seconds]
--- Log closed Thu Mar 04 00:00:46 2021