--- Day changed Sun Oct 16 2016 00:23 < waxwing> alexcato - as i was mentioning yesterday, this: "The problem of TailsUser above was self-made: first the UTXOs were not old enough. Once they were, they had been used too often already" 00:23 < waxwing> is not correct, if they are not old enough, they will not be sent into the pit in the first place. 00:27 < waxwing> 2nd, yes the crash in the commitments failed-to-source was fixed some days back (the crash on trying to add + commitment when it's None to a string/message) 00:28 < waxwing> third point: 100000 is way too small an amount to be using on JM. there are a lot of glitchy things that go wrong there as far as I know. it might be that the recent bump of dust_threshold to 10*bitcoin's dust threshold made that even more impractical. 00:32 < waxwing> re dust: well, maybe and maybe not, but irrelevant since that's just develop for now 00:34 < waxwing> next one: re: tailsjoin, arubi has made an upgrade to the tailsjoin repo in our org, it needs more people to try it out: https://github.com/fivepiece/tailsjoin 00:37 < waxwing> there was a reddit thread but i think the originator deleted it unfortunately 00:50 -!- Yohkii [~IceChat9@unaffiliated/yohkii] has joined #joinmarket 01:05 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection] 03:03 -!- TailsUser [1810d321@gateway/web/freenode/ip.24.16.211.33] has quit [Ping timeout: 260 seconds] 03:53 < waxwing> adlai: having remembered a bit more of what you said on Monday, i added an extra "bold" note in the gist: https://gist.github.com/AdamISZ/79457f1c20bc0702d299d873c899676a 03:53 < waxwing> i like that idea of explaining it as a 2-phase filtering system instead of our current 1-phase. well, as before, let me know what you think (or rewrite it another way if you prefer) 03:55 < Yohkii> Do several bots on the same wallet really help? 03:56 < Yohkii> help in getting more joins that is 03:57 < waxwing> Yohkii: "help" ; well, it's bad, the code is not intended to support that and things can go wrong (e.g. address reuse). it *can* help in getting more joins, although for sophisticated users it has the opposite effect: i pick manually and deliberately avoid them. 03:57 < waxwing> that gist is describing a way to disincentivize it more. 03:57 < Yohkii> hm, ok. 03:58 < waxwing> this has always been a (potential) problem since day 1, but i think no one decided to do it in such a dramatic fashion before :) 03:58 < Yohkii> Only running one atm, although I was playing with the idea of running one on TOR and one with no proxy 03:58 < waxwing> you can run more if you like but just use different wallets. 03:59 < Yohkii> Sure, but then again I could just add to a current wallet 04:00 < Yohkii> To me it seems very much that there are more than enough makers currently. Is that right? 04:01 < waxwing> Yohkii: i see 40 atm, i think at peak we had 70+ .. there's no fixed good amount really, more is always nice especially if it extends the range of btc amounts for which there's decent liquidity 04:02 < Yohkii> I see. Thanks. 04:32 < JM-IRCRelay> [AlexCato] thanks for your answers from this morning, waxwing! 04:32 < waxwing> np, i guess he had dusty problems right, i see he mentioned that error. although figuring out exactly why, dunno. maybe we can configure a warning not to try with < 200k or something like that. 04:33 < JM-IRCRelay> [AlexCato] one more thing i noticed last night: the readme.md in the master branch (which the majority of new users will use) is outdated/not really working. Should update that single file from the develop branch quickly imho 04:33 < waxwing> yeah i guess so 04:34 < JM-IRCRelay> [AlexCato] yeah, a warning would be nice, but I'd have a hard time finding the right level to set it at 04:36 < JM-IRCRelay> [AlexCato] i'll try a 200k join or two later, if that doesnt work increase in 100k increments. But that will also only give use empirical 'evidence' from a snapshot of the offers right now 04:36 < waxwing> damn, it's quite confusing that max_mix_depth is actually the number of mixdepths (in Wallet) 04:39 < JM-IRCRelay> [AlexCato] i'll also do a yg-pe randomization PR later; thinking of halfing the default reloffer cj from 0.2 to 0.1; i'd prefer no to go too low with the default, otherwise the incentives for new makers to join might be reduced. Which number did you have in mind? 04:40 < waxwing> i think we could make the default reduction a separate single commit (i can do it in a little while). 04:40 < waxwing> i honestly think reducing it by a factor of 10 might be the right thing. 04:41 < waxwing> my perspective has changed a bit from experiencing it in practice, i think the Takers are somewhat overpaying generally and discouraging bigger fees is logical to me. 04:42 < waxwing> alexcato re: randomisation on -pe i didn't quite get your idea 04:42 < waxwing> the whole idea of yg-pe was to reduce re-announcment as much as possible; to do the opposite approach, maybe just do a completely new one, or re-instate mixdepth or one of the complicated ones? 04:43 < waxwing> which brings me back to yet another thing i haven't got round to mentioning, i feel like it makes sense to have a separate repo with a bunch of different optional scripts. but i can never make up my mind what the best way is. 04:43 < JM-IRCRelay> [AlexCato] true, wouldnt fit the 'PE' name any more 04:43 < waxwing> my main point is i don't want to have 4+ scripts with large complexity that we have to maintain as part of 'core' 04:44 < JM-IRCRelay> [AlexCato] the idea was to change all parameters after every join, within a range. E.g. cjfee = 0.01% +/- 0.005%, same for txfees, min and max offer amounts 04:44 < waxwing> if you're inclined to do it, maybe just make your own repo with that script(=) that subclasses yieldgenerator.py 04:44 < JM-IRCRelay> [AlexCato] so that chain analysis alone is made a lot harder as you explained in one of the issue posts 04:45 < waxwing> yes i agree, that was the idea basically 04:45 < waxwing> script(+) i meant 04:46 < JM-IRCRelay> [AlexCato] About default reduction by an order of magnitude: from a maker perspective, i'd dislike keeping big amounts of coins in the hot wallet, just for the occasional 1-2 joins/month if the majority of other makers; i'd prefer to be rewarded for the risk i take. From a taker perspective, i totally see your point. In an ideal world, the free market would find 04:46 < JM-IRCRelay> the sweet spot itsself 04:46 < JM-IRCRelay> [AlexCato] in our real world, default configs distort the outcomes a lot 04:47 < JM-IRCRelay> [AlexCato] "if the majority of other makers use the default" <-- this somehow vanished in the text above, seems it was only in my head 04:49 < waxwing> if we take the cue from the market, fees tend to drop an order of magnitude lower than this default over time. it's far too large imo. 04:52 < JM-IRCRelay> [AlexCato] might be distorted as well by the sybils, who want to be part of most joins, driving the price down and making the 'real, honest' makers go away. But I only see the problem, I have no solution 04:53 < JM-IRCRelay> [AlexCato] though reducing the default could even help with that a little. Under the assumption that it's the real users who dont change defaults, this might make it harder for the sybils to get all the traffic 04:54 < JM-IRCRelay> [AlexCato] so reducing it a lot could even improve things from a privacy perspective 04:55 < JM-IRCRelay> [AlexCato] so, basically: disregard what I said :) I've no real insights at the interplay between all those incentives 05:07 < JM-IRCRelay> [AlexCato] 200k sendpayment: worked like a charm with -P. Now trying without selecting manually 05:09 < JM-IRCRelay> [AlexCato] ...: 05:10 < JM-IRCRelay> [AlexCato] [PaymentThrea] [INFO ] additional coinjoin fee = -0.751% 05:12 < JM-IRCRelay> [AlexCato] alright, this did not work with exactly the same error the TailsUser described yesterday 05:12 < JM-IRCRelay> [AlexCato] what happens imho (simple 200k sendpayment with -N 3): i accepted that first -0.751% offer. none of the makers answered 05:13 < JM-IRCRelay> [AlexCato] it automatically times out, chooses other makers. Next fee was: 0.2% 05:13 < JM-IRCRelay> [AlexCato] times out again, offers 0.4% in the next try 05:13 < JM-IRCRelay> [AlexCato] times out again, then it crashes with "TypeError: cannot concatenate 'str' and 'NoneType' objects" (running the latest develop version) 05:14 < JM-IRCRelay> [AlexCato] commitment-debug tells me: UTXO has been used too many times now 05:14 < waxwing> oh you get that crash on latest develop? huh. (not that it's the main thing here but i was sure i pushed that fix, will check) 05:14 < waxwing> do you have only 1 utxo in the wallet/mixdepth alexcato? 05:15 < JM-IRCRelay> [AlexCato] yes 05:15 < waxwing> https://github.com/JoinMarket-Org/joinmarket/wiki/Sourcing-commitments-for-joins#fund-your-wallet-with-multiple-utxos 05:16 < waxwing> so it times out on the 0.2% and 0.4% hmm 05:16 < JM-IRCRelay> [AlexCato] yes, but i believe there still might be some negative CJ fee in there, just off-set by non-negative ones 05:18 < JM-IRCRelay> [AlexCato] point is: those misconfigured sybil-nodes combined with commitment-usage for each try actually DoS the system, unless we manually choose the makers? 05:18 < waxwing> i've done 17 txs since i came back from milan, two from taker side, never had an issue :) but then again i'm not trying amounts which are so small. 05:18 < waxwing> yes they certainly can cause issues, no doubt about that, hence the gist above 05:19 < JM-IRCRelay> [AlexCato] and yes, only true for small amounts 05:19 < waxwing> when i raised this point around the time we were thinking about commitments, the counterpoint made to me was that well, sybils can DoS the system already. commitments can magnify the effect. 05:19 < waxwing> hence stuff like the above wiki notes on multiple utxos, and hence the idea of sophisticating the Taker algo etc. 05:20 < waxwing> and external utxos feature. if i was running a tumbler i would do that, but i'm not sure anyone has used it yet (apart from in testnet) 05:21 < waxwing> alexcato although it's a bit obscure, this commit seemed to fix the crash on no commitments found: https://github.com/JoinMarket-Org/joinmarket/commit/906a7166083ffb4068d838b5c3424918f7a7ddfb 05:22 < waxwing> it's supposed to shut down everything, but, even if i missed something there, it's largely academic, the program is shutting down anyway 05:22 < waxwing> did you get any "Authorisation failed" in the log? 05:25 < waxwing> as for the -0.7% fee, i'd have assumed it was due to someone still running old code (or modified code) that didn't respect minsize properly, it was an old bug that got reintroduced in 0.2.0 but then immediately fixed again, it's possible but shouldn't really matter i guess. 05:28 -!- jj_ [dfb1a5e3@gateway/web/freenode/ip.223.177.165.227] has joined #joinmarket 05:28 < JM-IRCRelay> [AlexCato] well, those makers use one 'commitment use' because they fail to respond when the taker tries to accept their offer; and since it's the sybil bots, that basically gets utxos blacklisted really fast? 05:28 < JM-IRCRelay> [AlexCato] no authorisation failed anywhere 05:29 < JM-IRCRelay> [AlexCato] here's my console/log/debug commitments: http://pastebin.com/PiC8x40m 05:29 < JM-IRCRelay> [AlexCato] running develop branch from yesterday, commit e1ca488a6b503052ea8a4d795d5c1ffcf8090f9e 05:29 < waxwing> you're assuming it's malicious sybils, but i'm not sure about that at all (notice btw our friend with tons of duplications is not there right now) 05:32 < JM-IRCRelay> [AlexCato] yeah, in this 3rd, last one there's no sybil. But in the first two he was (first try: 2 out of 3 are sybils, second try: 1 out of 3 are sybils). If the 3rd try fails for any reason, the multiple commitments need to be used then 05:33 < JM-IRCRelay> [AlexCato] but anyways, unless there's sybils intentionally not responding to hgiher cj amounts, this problem is only present in very small cj attempts. So probably not that big of a problem 05:34 < waxwing> the tailsuser guy referred to "dust" errors; you didn't get that? 05:34 < JM-IRCRelay> [AlexCato] oh, lots of dust debug messages, mainly those which are irrelevant: 05:35 < JM-IRCRelay> [AlexCato] [DEBUG] J52yTBJfArWZ2wKQ has dusty minsize, capping at 27300 05:35 < JM-IRCRelay> [AlexCato] one other one in there as well though: 05:35 < JM-IRCRelay> [AlexCato] [WARNI] ERROR counterparty requires sub-dust change. No action required. nick=J5E6s4XTjLRkuDNEtotalin=210000 cjamount=200000 change=10200 05:35 < waxwing> yeah i think thta's the one he saw 05:36 < waxwing> in develop DUST_THRESHOLD has been set to 10 * bitcoin dust threshold, which is bigger than 10200 05:36 < waxwing> which means i think that that one will not be allowed 05:36 < JM-IRCRelay> [AlexCato] yeah, i see the problem. Those YGs choose the wrong utxo for the join if they use another dust threshold 05:37 < waxwing> yes, it is in a subtle way a protocol break 05:37 < waxwing> adlai: ping , thoughts on that ^ ? 05:38 < waxwing> iirc it came out of a discussion between adlai and some other people on reddit, it hadn't occurred to me that it could be rather a big deal for small size joins 05:39 < JM-IRCRelay> [AlexCato] again, this mainly should happen for the very small joins. Would be quite a coincidence in big joins that the makers have a UTXO close enough to the cj amount for the dust to be a problem, even if it's 10*dust 05:40 < waxwing> sure, we're agreed on that 05:40 < waxwing> if it causes hassle though i'd be inclined to get rid of it, but i want to know what adlai thinks about it 05:53 -!- jj_ [dfb1a5e3@gateway/web/freenode/ip.223.177.165.227] has quit [Quit: Page closed] 06:12 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket 07:56 -!- Yohkii [~IceChat9@unaffiliated/yohkii] has quit [Quit: Download IceChat at www.icechat.net] 08:26 < GithubBot5678> [joinmarket] AdamISZ pushed 1 new commit to develop: https://git.io/vPiEE 08:26 < GithubBot5678> joinmarket/develop 502b6a8 Adam Gibson: prevent crash on tumbler restart due to index_cache not including extra mix depths 09:01 -!- JJ_ [dfb1a5e3@gateway/web/freenode/ip.223.177.165.227] has joined #joinmarket 09:47 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #joinmarket 09:58 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 11:38 -!- yield [b84bd102@gateway/web/freenode/ip.184.75.209.2] has joined #joinmarket 11:51 -!- yield [b84bd102@gateway/web/freenode/ip.184.75.209.2] has quit [Quit: Page closed] 12:14 -!- pigeons [~quassel@94.242.209.214] has joined #joinmarket 12:18 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #joinmarket 13:13 < waxwing> if anyone has another idea for this guy it'd be appreciated: https://github.com/JoinMarket-Org/joinmarket/issues/628 13:19 < arubi> I wonder if he just didn't wait enough for bitcoind to load and rpc returned "error" 13:20 < arubi> er, maybe not. looks like he kept on trying 13:41 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 14:40 -!- viasil_ is now known as viasil 14:43 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #joinmarket 15:50 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 15:58 -!- JJ_ [dfb1a5e3@gateway/web/freenode/ip.223.177.165.227] has quit [Quit: Page closed] 16:06 -!- GAit [~GAit@101.ip-213-32-22.eu] has joined #joinmarket 16:11 -!- GAit [~GAit@101.ip-213-32-22.eu] has quit [Changing host] 16:11 -!- GAit [~GAit@unaffiliated/gait] has joined #joinmarket 16:11 -!- GAit [~GAit@unaffiliated/gait] has quit [Quit: WeeChat 1.0.1] 16:13 -!- GAit [~GAit@unaffiliated/gait] has joined #joinmarket 17:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 17:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket 17:20 -!- pigeons [~quassel@94.242.209.214] has quit [Quit: No Ping reply in 180 seconds.] 17:25 -!- pigeons [~quassel@94.242.209.214] has joined #joinmarket 17:47 < GithubBot5678> [joinmarket] WyseNynja opened pull request #636: add Dockerfile and entrypoint.py (develop...add_dockerfile) https://git.io/vPixY 18:18 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 18:19 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #joinmarket 22:31 -!- pigeons [~quassel@94.242.209.214] has quit [Read error: Connection reset by peer] 22:43 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection] 23:36 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 23:40 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer] 23:40 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket