--- Log opened Tue Mar 09 00:00:51 2021
00:05 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has joined #joinmarket
00:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
01:09 -!- isenough [~isenough@2602:ffb6:4:e24d:f816:3eff:fe37:bdec] has joined #joinmarket
01:38 -!- jonatack_ [~jon@37.167.192.44] has joined #joinmarket
01:42 -!- jonatack [~jon@37.166.110.136] has quit [Ping timeout: 260 seconds]
02:22 -!- isenough [~isenough@2602:ffb6:4:e24d:f816:3eff:fe37:bdec] has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
02:31 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
02:31 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
02:32 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
02:32 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
02:32 -!- isenough [~isenough@irc.21isenough.me] has joined #joinmarket
03:13 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:14 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket
03:16 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has quit [Ping timeout: 264 seconds]
03:18 -!- Karlee76Mayert [~Karlee76M@static.57.1.216.95.clients.your-server.de] has joined #joinmarket
03:58 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
03:58 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
03:58 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
03:58 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
04:19 -!- netkrat [~netk@5.147.10.38] has joined #joinmarket
04:45 < waxwing> just finishing it off now, i really should modulate that 'mostly deducible by arithmetic on the blockchain' comment more, e.g. in the case of sweep it's unambiguously not the case
04:46 < waxwing> because there's no change output to correlate to
04:49 < waxwing> i think i'll change the wording of that to:
04:49 < waxwing> The most nuanced point, but important: the reveal, to makers, of taker inputs, was *often* revealing what is already deducible on the blockchain, by simple arithmetic - but the key word there is *often* - there are many cases where the taker's input is not revealed by arithmetic (sweeps are one example), and indeed that's a strengthening of the effect of the coinjoins. Revealing them to the makers was a significant failure in that regard.
04:49 < waxwing> i changed 'mostly' to 'often' and i added the parenthetical about sweeps. i think it's a fairer assessment of how bad it is.
04:53 < belcher_> waxwing there is, the change value is just zero
04:53 < belcher_> for sweeps
04:53 < belcher_> e.g. if theres a sweep coinjoin with an amount of 1btc, the adversary has to look for inputs which add up to just above 1btc
04:54 < belcher_> while the other maker's inputs will add up to (say) 3btc and their change value will be about 2btc
04:54 -!- belcher_ is now known as belcher
04:55 < belcher> the real defence is having many many peers in the coinjoin, so that theres more inputs overall and therefore the arithmetic deducing succeeds less often
04:55 < waxwing> oh dammit yeah
04:55 < waxwing> lol revert time then
05:02 < waxwing> confusing, was logged out of github and really confused why certain buttons weren't there
05:02 < waxwing> apparently they had a security issue and logged everyone out yesterday
05:08 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has joined #joinmarket
05:11 < waxwing> (not only many peers, also equal sizes which as you pointed out some time ago, isn't that uncommon, for obvious reasons)
05:12 < waxwing> the other effect which i only appreciated after doing some analysis on some of the gridchain case transactions, is exactly due to fees, it is not uncommon that the arithmetic gets fuzzy enough to have multiple valid partitioning solutions
05:13 < waxwing> of course it depends on what range of fees are considered reasonable; for larger coinjoins, larger fees are not particularly uncommon (relfee especially)
05:13 < waxwing> i had a couple cases,  i probably reported it here at the time, where i thought there were reasonably 2 or 3 possible partitioning solutions because of it
05:14 < waxwing> https://gist.github.com/AdamISZ/15223a5eab940559e5cf55e898354978
05:15 -!- coconutanna [~coconutan@gateway/tor-sasl/coconutanna] has quit [Remote host closed the connection]
05:15 < belcher> i wonder if an adversary would be helped by recording the orderbook through time
05:15 < belcher> that might help them untangle the fee situation
05:15 < waxwing> effectively what happened there is particular known actor could have been a maker or a taker if you allowed for fees in the range of 100ks of sats, which was *very* reasonable for that very large size
05:16 -!- coconutanna [~coconutan@gateway/tor-sasl/coconutanna] has joined #joinmarket
05:16 < waxwing> belcher, yes there seems no doubt that it could help, obviously fraught with difficulty. but yeah i haven't thought it through in any concrete detail
05:16 < belcher> i considered this thing for coinswap: fees actually be a random number, have the fees chosen by the maker and taker generating a fair random number between them and using that
05:17 < waxwing> ah. interesting thought, yeah.
05:17 < belcher> so the fee can actually be zero, and could go all the way up to 2*coinswap_fee.... on average the maker still earns `coinswap_fee` but the added randomness hurts analysis
05:17 < waxwing> there has to be some finesse around the concept of 'market' to account for the publication problem if you want privacy.
05:18 < waxwing> looking back at that data, if anything i was too conservative - i actually think the uncertainty of fee more or less destroys untangling there. kinda.
05:18 < waxwing> https://gist.github.com/AdamISZ/15223a5eab940559e5cf55e898354978#file-ba29eanal-py-L57
05:19 < waxwing> but as we know often it's more, investigator doesn't want *one* answer, just some plausible ones and see if they can get anywhere with a hypothesis
05:20 -!- jonatack_ [~jon@37.167.192.44] has quit [Ping timeout: 264 seconds]
05:20 < belcher> right but repeat that uncertainty over ~10 coinjoins and the number of possibilities should be pretty big
05:21 -!- mode/#joinmarket [+o waxwing] by ChanServ
05:22 -!- waxwing changed the topic of #joinmarket to: Welcome to JoinMarket: Increase Fungibility and Subsidise Your Fees | https://github.com/Joinmarket-Org/joinmarket-clientserver | @joinmarket r/joinmarket | Logs: http://gnusha.org/joinmarket/ | Latest release 0.8.2 UPDATE REQUIRED | Also on ssl cfyfz6afpgfeirst.onion:6667
05:22 <@waxwing> belcher, pls do hackint when you can
05:22 <@waxwing> also to everyone please widely publicize this new release https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.8.2
05:23 -!- mode/#joinmarket [-o waxwing] by ChanServ
05:25 < waxwing> also announced here https://x0f.org/web/statuses/105860058519429093
05:26 < belcher> done hackint
05:30 -!- jonatack [~jon@37.167.192.44] has joined #joinmarket
05:33 < waxwing> put big warnings on all 0.7.0-0.8.1 releases and deleted the binaries, but left the notes there
05:39 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket
06:38 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
06:38 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has quit [Quit: Bridge terminating on SIGTERM]
06:39 -!- threenp [~threenp@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
06:39 -!- johnnynitwits [~johnnynit@M111108211092.v4.enabler.ne.jp] has joined #joinmarket
06:41 < openoms> thank you for the heads up, updated quick
06:42 < openoms> on signet I get  a problem trying to run the wallet-tool.py:
06:42 < openoms> jmclient.jsonrpc.JsonRpcError: {'code': -18, 'message': 'Requested wallet does not exist or is not loaded'}
06:42 < openoms> mainnet has no issues
06:43 < openoms> my settings did not change apart from reinstalling JM from v0.8.1 to v0.8.2
06:43 < waxwing> openoms, well huh .. i mean, i'm not sure what i'd tell you there, that you don't already know
06:43 < waxwing> huh that's a weird one. let me think.
06:44 < openoms> the bitcoind has the wallet loaded of course, but handling must have changed for signet somehow
06:44 < waxwing> i've updated but it didn't change for me
06:44 < waxwing> oh but i was on master ofc, so that doesn't mean anything really
06:45 < waxwing> did you restart signet bitcoind between calls?
06:45 < waxwing> does it work backwards, like if you downgrade, does it work, now?
06:46 < waxwing> i don't recall any signet-relevant changes in the delta, but looking again
06:46 < openoms> thanks, will try to reinstall 
06:46 -!- Karlee76Mayert [~Karlee76M@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 276 seconds]
06:47 < waxwing> maybe when restarting bitcoind for signet you're missing like a create/loadwallet call or something?
06:47 < openoms> no, actually I did automate those and did not even restart bitcoind yet
06:47 < openoms> will reinstall v0.8.1 then back to v0.8.2 to see if reproducible
06:52 < DSRelBot> [DS/kermi] snicker finder finds many txids. but snicker is disabled if read release. so do some use it yet or is it just false positive look alike snickertx found...?
06:53 < waxwing> kermi - good Q!
06:53 < waxwing> i have the same question, i believe it's very likely false positives, but ofc i can't be 100% sure
06:54 < waxwing> bear in mind, a snicker is identified mainly by 2 equal outs and 1 non-equal out, with a few minor other fingerprints
06:54 < waxwing> so it's far more likely to get false positives on that, than say a 6-10 equal output coinjoin
06:55 < waxwing> i can say you'll definitely find a few non-false positives on signet, since i've done some :)
06:55 < DSRelBot> [DS/kermi] ok i see Found SNICKER transaction: ae31b3fbb80dd22c5b55bd83f18ac8470865ce74118cd94fb670a3662f6e0e85 in block: 673841 with the outputs you descibe. that may to common fingerprint
06:55 < openoms> @waxwing it was my bitcoind sorry
06:55 < DSRelBot> [DS/kermi] i belive its not since not even segwit
06:56 < waxwing> kermi see https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmbitcoin/jmbitcoin/snicker.py#L106-L116
06:56 < DSRelBot> [DS/kermi] ok
06:56 < waxwing> ah you're right, this is a mistake on my part. i forgot script type
06:56 < waxwing> i check for the same scriptpubkey type, but i don't check that it's segwit.
06:57 < waxwing> PRs welcome :) iirc in the draft spec i specified segwit as a  requirement, and for sure JM will only use segwit for snicker.
06:57 < waxwing> openoms, understood, thanks
07:00 < waxwing> oh that particular tx is segwit on inputs and could be wrapped segwit on outputs, kermi. not that it matters, it's of course almost certainly false positive anyway.
07:00 < waxwing> (*wrapped* segwit on inputs)
07:04 < DSRelBot> [DS/kermi] p2sh yes  👍🏻 called it not segwit buts the wrapped of couse just not native segwit sry
07:15 < mcv> openoms - what did you do - same here ? and I was *sure* i loaded the wallet in core .....
07:16 < openoms> @mcv check with bitcoin-cli listwallets
07:17 < openoms> just fixing the joininbox wallet load script. Is that what you are using?
07:17 < mcv> it is
07:17 < mcv> ill double check ...brb
07:17 < openoms> will commit in a minute
07:23 < mcv> huh ... seems to be "reading the chain" in QT ( thought I would use it instead of cli
07:23 < mcv> )
07:24 < mcv> but yes it is what I am using
07:36 < openoms> @mcv pushed the fix now
07:37 < openoms> can also do manually:
07:37 < openoms> bitcoin-cli loadwallet <bitcoin-wallet-file>
07:37 < waxwing> was it something specific to joininbox or was it to do with new bitcoind version? i remember they changed the rpc a bit
07:37 < openoms> qt should also work
07:38 < waxwing> we should improve by making a dynamic wallet load right, istr you opened an issue in JMCS about it
07:39 < openoms> @waxwing joininbox was catching a message in terminal instead of the response from the bitcoin RPC :/
07:39 < mcv> openoms - QT found the wallet and accepted passphrade - so i am guessing is working ..
07:39 < openoms> @mcv cool, thank you for contacting
07:39 < mcv> :D
07:40 < openoms> @waxwing yes, the wallet loading can  be confusing when bitcoind restarts and there are other wallets in the system. Now that peopel are connecting more apps to their bitcoind it can come up more often
07:57 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket
07:58 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
08:08 < waxwing> agreed, should prioritise
08:27 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket
08:54 -!- belcher_ is now known as belcher
09:00 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 256 seconds]
09:35 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 276 seconds]
09:41 -!- jonatack [~jon@37.167.192.44] has joined #joinmarket
09:42 -!- KIS [2d57d6c9@45.87.214.201] has joined #joinmarket
09:43 < KIS> My CLI created mixdepth 10 levels deep during a tumble.py run... I want to upgrade to 0.8.2 and want to verify I can manually restore the m depth of my wallet after upgrade  ?
09:57 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 3.0.1]
10:04 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined #joinmarket
10:06 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Quit: ZNC 1.8.2 - https://znc.in]
10:37 -!- jonatack_ [~jon@37.167.192.44] has joined #joinmarket
10:37 -!- jonatack [~jon@37.167.192.44] has quit [Read error: Connection reset by peer]
10:40 -!- jonatack_ [~jon@37.167.192.44] has quit [Read error: Connection reset by peer]
10:41 -!- jonatack_ [~jon@37.167.192.44] has joined #joinmarket
10:41 -!- jonatack_ [~jon@37.167.192.44] has quit [Client Quit]
10:42 -!- jonatack [~jon@37.167.192.44] has joined #joinmarket
10:55 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket
10:57 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds]
11:13 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 246 seconds]
11:19 -!- jonatack [~jon@37.167.192.44] has joined #joinmarket
11:20 < waxwing> KIS by manually restore, what do you mean?
11:27 < KIS> Once I upgrade and load the same wallet file... wallet-tool.py will show me all 10 mixdepths ?
11:28 < waxwing> i jsut tested it and it worked for me
11:28 < waxwing> well, i did a generate with -m 10, then i did a wallet-tool without -m argument and it showed all 10
11:28 < waxwing> i'd have to double check in the code, but it seems so :)
11:28 < waxwing> difference between 0.8.2 and earlier should not be anything here
11:29 < KIS> Could you explain to me why tumble.py would create more mixdepth levels instead of cycling back through ?
11:29 < KIS> When I created the guide I explained in the animation that coins cycle back to m0 after m4... but my experience has been very different. :-D
11:30 < waxwing> well it's not wrong per se; if you do a coinjoin with coins in m4 then they go to m0, if your total is 5
11:30 < waxwing> as a maker, that is
11:31 < waxwing> tumbler goes from start mixdepth, to end mixdepth, and out (basically)
11:32 < KIS> I started a tumble.py in m4 and it created up to m7.. and then another tumble.py left me with m10
11:33 < waxwing> right, it goes from whatever you set as the start mixdepth, up to however many you configure
11:33 < waxwing> as i recall it's the -m and -M parameters
11:34 < waxwing> if you find it's not showing all the mixdepths, you can do a generate with -m to create a new wallet file for the same wallet with the required number
11:34 < waxwing> i think it remembers how many were used in the past, but my memory is vague on this point, i'd have to check again
11:35 < KIS> generate is genwallet.py ?
11:35 < waxwing> no generate method of wallet-tool.py
11:35 < waxwing> that other one is for automation, we probably didn't need to add it to the repo tbh
11:36 < waxwing> look at help of wallet-tool, it's much easier to read nowadays
11:36 < KIS> ok thanks
11:36 < waxwing> huh, kristapsk , if you're reading on hackint, we should alter the help text of -m given your recent change
11:37 < waxwing> because it does something different for display methods
11:37 < waxwing> KIS uh sorry, derp
11:38 < waxwing> i don't mean generate of course, i mean recover. makes no sense otherwise.
11:39 < KIS> you meant to say use wallet-tool.py recover -m *level of depth* ?
11:39 < waxwing> yeah i just tested it, it works
11:39 < waxwing> sorry must have been confusing :)
11:40 < KIS> But thats a worse case because the original wallet file should load same number of mixdepths after upgrading ?
11:40 < waxwing> it also doesn't complain about rescan, because of course the addresses were already imported
11:41 < waxwing> i thought it should but i need to check
11:41 < KIS> ok
11:41 < waxwing> i mean i was assuming that maybe you found a case where it didn't
11:41 < KIS> I was hesitant to upgrade because of my many mixdepths, why I wanted to ask first.
11:42 < waxwing> i see, so try without recover first, if it doesn't work that's your backup
11:42 < waxwing> looking again now
11:46 < KIS> Is it valid to say my taker scripts not working because I haven't upgraded to 0.8.2 ? That has been my experience as of last 24 hours... nothing works for me as taker.
11:48 < waxwing> KIS, oh .. i very much doubt it's to do with 0.8.2 upgrade
11:49 < waxwing> btw i checked the code, yeah, the set of utxos is stored as a dict indexed by mixdepth so, yeah, it remembers how many mixdepths you had last time you saved.
11:49 < KIS> Great, Thanks !
11:49 < waxwing> KIS, do you see anything in your logs telling you what is failing?
11:50 < waxwing> one possibility recently, though i haven't collected any data, is there might be problems related to IRC connections if there are too many bots.
11:50 < waxwing> but just a complete guess. could be something entirely different.
11:51 < KIS> in CLI I keep getting 'Taker not continuing after receipt of orderbook'
11:51 < KIS> Then it loses IRC connection
11:52 < waxwing> yeah that sounds more likely to do with config settings - e.g. your minimum_makers setting conflicting with how many makers you request
11:52 < KIS> ERROR not enough liquidity in the orderbook
11:52 < KIS> thats what I see in logs
11:52 < waxwing> or your fee settings not finding anyone fitting that. or your size of join not fitting what makers can provide.
11:53 < KIS> Thats strange, settings haven't changed and always worked before.
11:53 < KIS> I'll go back and tweak the config file and see if I can fix it.
11:53 < waxwing> how many makers are you requesting, if that's higher than minimum_makers, then, compare your fee limits with what's on offer for your size range in the orderbook
11:54 < waxwing> if you didn't tweak any obscure settings, after that it gets a bit harder to find a possible cause for that.
11:54 < waxwing> i assume you're on the two default IRCs
11:54 < KIS> i was trying sendpayment.py with no flags
11:54 < waxwing> ok, that's helpful
11:54 < KIS> default everything
11:56 < KIS> ya default irc
11:56 < waxwing> can you try increasing maker_timeout_sec to say 90 seconds if it is lower
11:57 < waxwing> it seems to be working for me (i got the requisite offers from makers but didn't do the join)
11:57 < waxwing> just a random, fairly normal/smallish amount
11:58 < waxwing> (doesn't prove the whole join would work but i didn't get liquidity error anyway)
11:58 < waxwing> generally if you're getting the liquidity error it means your net connections are fine, your bitcoind rpc is fine, there's something stopping you actually getting valid offers per your config
11:58 < waxwing> i mean, *generally*
12:01 < waxwing> actually i only had maker_timeout_sec 60s and it was still fine
12:01 < waxwing> (relevance of that is it can take a while for the messages to get through to your bot .. but seems that's fine here)
12:02 < KIS> The only variable I've been changing is the tx_fees because I don't want txns getting stuck in mempool
12:03 < waxwing> yup. that can't affect it since it isn't part of the offers request part.
12:03 < waxwing> or .. it could indirectly, if it changes the coinjoin size i guess
12:04 < waxwing> but then you'd see warnings if you made the fee estimate large cf the coinjoin size, so .. nah
12:05 < KIS> even after warning I still get a second prompt to confirm before finalizing... but its not finding anything
12:05 < KIS> Same prompt again, Aborted because could not find orders
12:05 < waxwing> what does that prompt say?
12:06 < KIS> Im sorry not a prompt... its text in the CLI
12:06 < KIS> [INFO]  ABORT:Could not find orders to complete transaction
12:06 < KIS> [INFO]  Taker not continuing after receipt of orderbook
12:06 < waxwing> yeah. i mean, the info somewhere above should tell you the coinjoin amount it's trying to use and some stuff about fees.
12:06 < KIS> [INFO]  Did not complete successfully, shutting down
12:07 < waxwing> what do you have for max coinjoin fee settings? well, don't have to say, but look at that too
12:07 < KIS> Right... it never gets to that point, been like this the last day for me.
12:07 < waxwing> also do you have a 'considered orders' line?
12:07 < KIS> I use the relative limits in prompt... I haven't set hard parameters for those.
12:07 < waxwing> fine
12:07 < waxwing> also do you see any lines containing 'dusty minsize, capping at' ?
12:08 < KIS> No 'considered orders' line... it just aborts.
12:08 < waxwing> i'm thinking maybe you're not receiving any offers at all
12:08 < waxwing> so somehow you're not 'fully' connected to IRC
12:08 < waxwing> can you try running a  yieldgen and then seeing if it appears in the orderbook (or literally logging on to IRC to look for it)
12:08 < KIS> Is that an issue other instances have encountered ?
12:09 < KIS> Sure let me try
12:09 < waxwing> don't know, haven't heard about it recently
12:11 < KIS> Im showing up in order book
12:11 < KIS> checked it from another instance
12:13 < waxwing> you have native=true? what is your maker_timeout_sec?
12:14 < waxwing> your coinjoin amount looks like what you actually set?
12:14 -!- KIS [2d57d6c9@45.87.214.201] has quit [Quit: Connection closed]
12:14 -!- KIS [2d57d6c9@45.87.214.201] has joined #joinmarket
12:15 < waxwing> i mean i can only guess here, also, you should carefully think about what changed, because it wont' be anything to do with new software version
12:15 < KIS> Yes native segwit. timeout set to 90 sec like you suggested. CJ amount is what it shows in CLI
12:15 < waxwing> or .. well, you updated to 0.8.2 yourself right? so that is a delta
12:15 < KIS> not yet
12:15 < waxwing> oh right you said
12:15 < KIS> i was preparing to before we started chatting
12:16 < waxwing> you can try on signet if you have a wallet; that uses same IRC stuff, just only 3 or 4 bots
12:17 < waxwing> huh i should remember you said you didn't see any of those dusty minsize warnings, so it must be that you're not actually receiving the orders
12:18 < waxwing> they are not strictly required to appear, but they basically always do, because there are a few bots with too small minsize
12:20 < waxwing> if anyone else here could confirm my experiment, just do sendpayment without arguments and quit out after you get the offers, to see if it's working for you.
12:20 < KIS> I don't recall ever seeing those ....
12:20 < waxwing> they look like this: 2021-03-09 19:55:58,684 [DEBUG]  J5CsWrEvrBdWpi63 has dusty minsize, capping at 2730
12:21 < waxwing> but you wouldn't notice them a lot of the time
12:21 < KIS> I've tried sendpayment.py and tumble.py today and niether are working, I tried both from diff mixdepths of varying utxo sizes
12:22 < waxwing> where 'not working' always means 'no liquidity' error?
12:22 < KIS> Correct.
12:22 < KIS> At least the last 24 hours, I've been having this issue...
12:23 < waxwing> i see, so you can isolate this to very recent, about last 1-2 days?
12:23 < KIS> Yes.
12:23 < KIS> Tangentially.. I've also had no activity as maker
12:24 < KIS> yield gen has been running entire time
12:24 < KIS> last activity was few days ago, but I assumed thats due to the high txn fees..
12:28 < waxwing> right now my only experiment showed it working fine.
12:29 < KIS> You'd know better than me.
12:30 < waxwing> scanning last 100 blocks right now just to check
12:30 < KIS> im upgrading to 0.8.2 now... ill see if that makes a diff.
12:30 < waxwing> in the last few weeks i checked a 1 day chunk 2 or 3 times, usually seeing around 30 joins / day (false positives are very rare i believe)
12:31 < waxwing> i mean if you're on the irc channels, the pits show a pretty good estimate anyway via !hp2 .. but you have to be logging it
12:33 < waxwing> i see no way 0.8.2 could change this. i think it has to be connection related.
12:35 < waxwing> meh, *probably* .. i can't be certain from info so far.
12:37 < waxwing> 23 in last 100 so very close to 30/day still, nothing to indicate anything unusual globally so far KIS 
12:46 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 264 seconds]
13:17 < KIS> Just opened an issue on github... got this error when installing 0.8.2 ERROR: Could not find a version that satisfies the requirement PySide2==5.14.2
13:17 < KIS> ERROR: No matching distribution found for PySide2==5.14.2
13:25 < waxwing> KIS, why did you close it?
13:26 < waxwing> i recall we had this issue recently
13:26 < KIS> Because I saw someone else posted same issue, I closed and commented in that issue.
13:26 < waxwing> ah yeah just found it
13:26 < waxwing> you're on Mac too?
13:27 < KIS> yes my working instance is MacOS 10.15.7 Catalina
13:28 < waxwing> yeah it's unfortunate, we had *very* tricky errors triggered on the linux installation of the Qt application due to them removing static linking of certain libs and so we had to pin the version for that reason
13:28 < waxwing> but if it screws up for Mac, there's a decent chance that removing the `==..` parts from these two lines may fix it: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/requirements/gui.txt#L3-L4
13:29 < waxwing> no guarantees though. and to state the obvious, you could also install without qt as according to the prompt, if your priority is just to test
13:30 < KIS> I installed without QT.. and I can confirm wallet file loads up same as in previous version
13:32 < waxwing> made a cross reference there in #815, possibly we can remove the pin to the old version if they fix the linux problem but .. another topic
13:37 < KIS> Is there any *reset* I could do to my instance or config file to troubleshoot my taker issue ?
13:38 < waxwing> yes, i would probably backup joinmarket.cfg, run wallet-tool to create a new one
13:38 < waxwing> then add back in your blockchain connection specific settings
13:38 < KIS> Actually it just worked
13:39 < waxwing> what worked?
13:39 < KIS> only thing i did differently was specify  the amount to send instead of using '0'
13:39 < waxwing> ah
13:39 < KIS> but it could be random chance that it works , no ?
13:39 < waxwing> when you set 0, did it show in the log what amount it came up with?
13:39 < KIS> let me check
13:40 < waxwing> it could be, especially if it *is* connection related
13:43 < KIS> there aren't any logs in the log folder anymore, i just installed 0.8.2
13:43 < waxwing> should be in ~/.joinmarket/logs
13:43 < KIS> looks like the amount flag is what solved the problem, it wont work when i try to sweep a mixdepth
13:44 < waxwing> they don't get deleted
13:44 < waxwing> i just checked in code, there will be a line "choosing sweep orders for total_input_value = .."
13:44 < waxwing> there'll also be a few lines telling you about fee estimates
13:46 < KIS> ERROR: Could not find a version that satisfies the requirement PySide2==5.14.2
13:46 < KIS> ERROR: No matching distribution found for PySide2==5.14.2
13:46 < KIS> oops wrong paste
13:46 < KIS> 2021-03-09 16:43:41,133 [MainThread  ] [INFO ]  INFO:Preparing bitcoin data..
13:46 < KIS> 2021-03-09 16:43:41,164 [MainThread  ] [DEBUG]  Estimated ins: 25
13:46 < KIS> 2021-03-09 16:43:41,164 [MainThread  ] [DEBUG]  Estimated outs: 17
13:46 < KIS> 2021-03-09 16:43:41,164 [MainThread  ] [DEBUG]  rpc: getnetworkinfo None
13:46 < KIS> 2021-03-09 16:43:41,166 [MainThread  ] [DEBUG]  Using this min relay fee as tx feerate floor: 1000 sat/vkB (1.0 sat/vB)
13:46 < KIS> 2021-03-09 16:43:41,166 [MainThread  ] [DEBUG]  We have a fee estimate: 62411
13:46 < KIS> 2021-03-09 16:43:41,166 [MainThread  ] [DEBUG]  choosing sweep orders for total_input_value = 100000 n=8
13:46 < KIS> 2021-03-09 16:43:41,166 [MainThread  ] [DEBUG]  orderlist =
13:46 < KIS> Then it lists many orders
13:47 < KIS> Then 2021-03-09 16:43:41,171 [MainThread  ] [DEBUG]  ERROR not enough liquidity in the orderbook
13:47 < KIS> 2021-03-09 16:43:41,171 [MainThread  ] [INFO ]  ABORT:Could not find orders to complete transaction
13:47 < KIS> 2021-03-09 16:43:41,171 [MainThread  ] [INFO ]  Taker not continuing after receipt of orderbook
13:47 < KIS> 2021-03-09 16:43:41,172 [MainThread  ] [INFO ]  Did not complete successfully, shutting down
13:47 < KIS> 2021-03-09 16:43:41,173 [MainThread  ] [INFO ]  Lost IRC connection to: guybrush.hackint.org . Should reconnect automatically soon.
13:47 < KIS> 2021-03-09 16:43:41,174 [MainThread  ] [INFO ]  Lost IRC connection to: irc-eu-1.darkscience.net . Should reconnect automatically soon.
13:48 < KIS> thats from when I don't specify an amount.
13:52 < waxwing> yeah there's the problem amount input of 100K and fee estimate of 62K
13:53 < waxwing> you're going below the limit of what can be done there
13:54 < waxwing> there was a recent commit in 0.8.1 addressing part of the trickiness around this; for sweeps in particular, fee calculation is *really* difficult, it has to be based on conservative estimates
13:54 < waxwing> but even non-sweep at 100K ish it's a very dicey proposition, i wouldn't bother trying, albeit if you carefully control stuff like small makercount and lowball fee you can in theory get something to work
13:55 < waxwing> so nothing to do with connection in the end
13:56 < waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/release-notes/release-notes-0.8.1.md#constraining-sweep-transaction-fees
13:57 < waxwing> i am a little concerned that the fix there was a bit too strict, but that's entirely another matter. you might find reading the linked issue comment helpful if you want to understand better
14:06 < KIS> So that is helpful with sendpayment.py but with tumble.py I can;t specify an amount... it takes the contents of entire mixdepth. How can I fix this with  tumble.py ?
14:08 < waxwing> the problem isn't specific to an algo; it's that if the amounts are small enough you will just hit a raft of problems
14:08 < waxwing> makers minsizes will be too high; network fees will be too high as a proportion, etc
14:09 < KIS> but in this instance its 100,000,000 sats
14:09 < KIS> so that couldn't be the problem
14:09 < waxwing> but it says total_input_value = 100000
14:09 < KIS> that was for sendpayment.py... the log output was for 0.001
14:09 < waxwing> was there a copy-paste error or something?
14:10 < KIS> but for tumble.py I have a mixdepth with ~ 1 bitcoin
14:10 < waxwing> i see, so you're talking about having a problem with a 1btc tumbler run
14:10 < KIS> Yes.
14:10 < waxwing> well it's a different case, i'd need to know what is wrong, i.e. what happened
14:11 < waxwing> you're saying, i think, that you get 'liquidity error' in that case too?
14:11 < waxwing> or not enough liquidity etc
14:11 < KIS> Correct.
14:11 < KIS> and there is certainly enough liquidity in orderbook
14:12 < waxwing> take a look at the schedule in logs/TUMBLE.schedule and the shortened log in logs/TUMBLE.log and the actual full bot log and look at the transaction that had that liquidity failure, check its amount. at least remove the possibility that one transaction had too small a size.
14:12 < waxwing> the -s flag allows you to create a floor on the size of any one transaction btw
14:13 < waxwing> also don't forget that tumbler uses sweeps of mixdepths at certain points. the first step it takes is to move all coins in the wallet with sweeps from each mixdepth.
14:13 < waxwing> belcher, might explain more on that point.
14:13 < KIS> ok thanks
14:13 < waxwing> but generally it'd need to be checked carefully.
14:13 < belcher> as sweeps dont create a change address for the taker they are more private
14:14 < waxwing> fwiw i find that to run tumbler it's best to go with the simplest setup: coins deposited into m0, then run for say 4 depths with long timeouts and you can use --restart to continue run later if you turn it off for a while.
14:15 < waxwing> obviously all-default settings should not actually fail to work, also, but ofc important is multiple destinations, more being better.
14:24 -!- netkrat [~netk@5.147.10.38] has left #joinmarket []
14:47 -!- jigawatt [~mcfly@2605:2700:1:100e:dc::f01d] has quit [Quit: McFly out.]
14:47 -!- jigawatt [~mcfly@2605:2700:1:100e:dc::f01d] has joined #joinmarket
16:16 -!- mcv [~McViLLaN@unaffiliated/mcvillan] has quit [Ping timeout: 260 seconds]
16:17 -!- mcv [~McViLLaN@unaffiliated/mcvillan] has joined #joinmarket
16:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
16:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
16:36 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]
17:22 -!- asy [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket
17:23 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Ping timeout: 268 seconds]
17:35 -!- DSRelBot [~DSRelBot@p5de4ab64.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
17:36 -!- HackRelay [~jmrelayha@p5de4ab64.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
17:48 -!- HackRelay [~jmrelayha@p5de4acb9.dip0.t-ipconnect.de] has joined #joinmarket
17:49 -!- DSRelBot [~DSRelBot@p5de4acb9.dip0.t-ipconnect.de] has joined #joinmarket
18:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
18:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
18:30 -!- dave_uy33 is now known as dave_uy
18:30 -!- dave_uy [~david@108.61.193.26] has quit [Quit: The Lounge - https://thelounge.chat]
18:30 -!- dave_uy [~david@108.61.193.26] has joined #joinmarket
18:41 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket
18:52 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 268 seconds]
18:58 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket
20:16 -!- KIS [2d57d6c9@45.87.214.201] has quit [Quit: Connection closed]
21:05 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has quit [Ping timeout: 268 seconds]
21:20 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has joined #joinmarket
21:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
21:41 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has quit [Ping timeout: 268 seconds]
21:42 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has joined #joinmarket
21:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
23:42 -!- jungly [~jungly@host-79-55-185-171.retail.telecomitalia.it] has joined #joinmarket
--- Log closed Wed Mar 10 00:00:53 2021