--- Day changed Thu Oct 27 2016
00:25 -!- Socket_0x03 [~Socket_0x@c-66-176-87-156.hsd1.fl.comcast.net] has quit [Remote host closed the connection]     
00:30 < waxwing> belcher: re: <belcher> okay this could be accident, ~30sat/kb tx is holding up about 30btc
00:30 < waxwing> interesting, possibly, but then again depending on when it was done, a "tx_fees = 25" in the joinmarket.cfg could end up setting a fee like that perhaps?
00:31 < waxwing> i mean, right now, estimatefee is giving me 60k for 20 blocks, but it's hard to be sure.
00:32 < waxwing> blockcypher right now: "low_fee_per_kb": 34623,
00:33 < waxwing> hence one possibility is blockcypher with tx_fees set to anything greater than 6. but admittedly this is today and that was yesterday, so maybe not.
00:33 < waxwing> i'm more interested in your quote from the day before of 6000 sat/byte ; was that a typo?
00:34 < waxwing> sorry 6000 sat/kB i meant of course
00:38 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Excess Flood]     
00:38 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #joinmarket     
01:05 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
01:32 < belcher> not a typo waxwing 
02:01 < adlai> waxwing: if you're willing to wait a little on the release, i'll revert the dustbump and also toss in my mixdepth range patch
02:02  * adlai was discussing JM with somebody building a bitcoin-enabled service; mixdepth ranges would be convenient for handling accounts
02:02 < adlai> ie, one wallet for the site, range for each account
02:42 < adlai> meanwhile my ResendWalletTransactions backlog is slowly fading away... still a bunch left though
02:43 < adlai> btw, the 'history' method is giving me the following failure: "ValueError: f(a) and f(b) must have different signs"
02:44 < JM-IRCRelay> [digid] Seems like a cool project, i'd love to help with development efforts
02:45 < adlai> has anybody else tried using this on a messy wallet? where 'messy' means, it's been running for over a year, has had multiple deposits and multiple privkey-import-withdrawals, probably also used a negative fee at some point just to see what happens, etc
02:45 < JM-IRCRelay> [digid] any suggestions other than than the wiki? Do you guys use a ticketing system for features/task/bugs other than what's in github and how do i sign on as a developer?
02:45 < adlai> digid: just what's on github and irc
02:46 < adlai> if you want to communicate privately, you can email the other developers, most of us also use pgp
02:46 < JM-IRCRelay> [digid] ok
02:47 < adlai> everybody here is volunteering, so you're welcome to help snag low-hanging fruit from the github issues marked as easy, as a way of introducing yourself to the code
02:48 < JM-IRCRelay> [digid] Ok, sounds good, thanks
02:48 -!- mkarrer_ [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #joinmarket     
02:50 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer]     
02:50 -!- coins123_ [~coins123@ip-244-225.sn1.clouditalia.com] has joined #joinmarket     
02:51 < adlai> also, use testnet and/or regtest for developing
02:52 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit [Ping timeout: 276 seconds]     
02:59 < waxwing> adlai: pls revert dustbump, yeah, but no, don't want to wait for mixdepth range in 0.2.2 . i think it's too big a change, we need to spend time on it. i don't want to delay the partial fix (and the other fixes) any longer. i think like tomorrow is probably right for release.
02:59 < waxwing> maybe day after
03:00 < adlai> ok. one further thought i had re:dustbump, is that we could split into two params, one for the dustiest you create, one for the dustiest you tolerate
03:00 < adlai> leave the tolerate one at the old default, initialize the creation one at the current default
03:00 < waxwing> yeah makes sense i guess. a bit complicated perhaps?
03:00 < waxwing> well, either way is fine really.
03:01 < adlai> not that much. i'd rather do it this way, so Ksat-level dust remains as rare as possible
03:01 < waxwing> ok, if it's easy, thanks
03:04 < waxwing> adlai: so 643 is fine to merge right?
03:04 < waxwing> btw don't merge unless you've figured out github-merge.py yet (and pgp key on github)
03:04 < waxwing> sorry, unclear, i mean, don't merge using github's own "merge pull request" button as it doesn't allow signed commits that way
03:05 < waxwing> some guy on one of the issues has been berating us about this for some time, so now i always use that script to merge PRs so the latest commit is always signed
03:05 < adlai> "pgp key on github"!? i really hope i'm overinterpreting that...
03:06 < waxwing> you know what i mean, put the pubkey there so it can verify
03:06 < adlai> ic     
03:06  * adlai has not used this script yet
03:07 < waxwing> for context, read the last few comments here: https://github.com/JoinMarket-Org/joinmarket/issues/427#issuecomment-250116164
03:08 < waxwing> i don't think it's at all unreasonable that people want signed commits, i suppose it doesn't matter though, if your key is marked "Verified" on github, they should use another verification method anyway
03:08 < adlai> ok, i will. fwiw, one thing i don't like about git's signature model is that it suggests that i'm signing the entire state of all the code, whereas usually i'd rather sign a patch
03:08 < waxwing> right that part confused me too.
03:09 < adlai> there are VCSs that make this distinction but they're much less common
03:09 < waxwing> people said things like "oh if you sign that commit you're effectively signing all the history". well, to me that makes no sense, it should be obvious that i'm signing the diff.
03:09 -!- digidivinity [~digidivin@ool-44c2660f.dyn.optonline.net] has joined #joinmarket     
03:09 < waxwing> i mean maybe that statement is not technically correct, but practically it is surely.
03:09 -!- digidivinity is now known as digid     
03:09 < adlai> well, you're not... technically, you're signing the merkle root of the history to that point.
03:10 < adlai> the diff can be extracted from that, by diffing the last two trees
03:10 < adlai> but you can't eg take a signed commit, rebase it, and have the same signature still work
03:10 < adlai> even if the rebase doesn't affect any of the same files as that commit
03:11 < adlai> so, i'll sign my commit once i've given some nonzero review to the other recent commits
03:12  * adlai lunch
03:12 -!- digid [~digidivin@ool-44c2660f.dyn.optonline.net] has quit [Remote host closed the connection]     
03:12 < gmaxwell> you could use the github merge script from bitcoin-core.
03:12 -!- digid [~digidivin@ool-44c2660f.dyn.optonline.net] has joined #joinmarket     
03:13 < gmaxwell> you run it and tell it a pr number. it applies it locally, sets up so you can verify and test it.. then signs the commit and pushes it up.
03:14 < gmaxwell> this is contrib/devtools/github-merge.py
03:16 < fluffypony> I love that script 
03:17 < fluffypony> use it for all the Monero merges 
03:17 < fluffypony> oh I have the .sh one, I guess it predates the .py
03:18 < gmaxwell> yea, py one is newer I guess.
03:18 < gmaxwell> I only got the extension right because I checked. :P
03:18 < waxwing> gmaxwell: i am  using it, that was kind of the point :)
03:21 < waxwing> <waxwing> btw don't merge unless you've figured out github-merge.py yet (and pgp key on github)
03:32 -!- sturles [~sturles@unaffiliated/sturles] has joined #joinmarket     
04:00 -!- digid [~digidivin@ool-44c2660f.dyn.optonline.net] has quit [Quit: Leaving]     
04:11 < waxwing> anyway, i just wanted a teensy confirmation that 643 was ok to merge :)
04:13 < GithubBot5678> [joinmarket] AdamISZ closed pull request #648: Suggestion for 0.2.2 release notes and 0.2.2 README. Feel free to add… (develop...develop) https://git.io/vXvrT
04:23 < GithubBot5678> [joinmarket] AdamISZ pushed 2 new commits to develop: https://git.io/vXJl3
04:23 < GithubBot5678> joinmarket/develop c89347a Adam Gibson: initial draft allowing takers to optionally complete transactions with less than the initially requested number of makers; sweep function is unchanged...
04:23 < GithubBot5678> joinmarket/develop 3276e3c Adam Gibson: Merge #647: initial draft allowing takers to optionally complete transactions wit…...
04:37 < waxwing> ok now in develop, tested again: used -N 6 with minimum_makers=3 ; got a tx with 3 makers ... so one way or another some counterparties are either maliciously or inadvertently still not responding.
04:39 < waxwing> (that was without -P , still advisable to use that)
04:39 < waxwing> also sanity check debug log setting worked OK
04:39 < waxwing> ah, our 7.49 friend is back, it was indeed "him". or her. or it.
04:40 < waxwing> still can't make sense of that behaviour, why make it so obvious?
04:48 < waxwing> if anyone around would be kind enough to run latest develop, that'd be a useful sanity check, consider it a release candidate (couple more tiny commits that shouldn't affect things left)
05:00 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket     
05:01 -!- Numin0us [~Numin0us@cpe-74-64-92-78.hvc.res.rr.com] has joined #joinmarket     
05:01 -!- Numin0us [~Numin0us@cpe-74-64-92-78.hvc.res.rr.com] has quit [Changing host]     
05:01 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has joined #joinmarket     
05:07 < waxwing> should i kick or ban them? they are blocking txs again. there is at least one obvious flag that they are not using unmodified joinmarket.
05:38 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has quit [Ping timeout: 276 seconds]     
05:44 < waxwing> just did a second sendpayment trial run, the minmakers again allowed it complete, but i did get one of those "sub-dust" change errors which meant it had to restart.
06:17 < waxwing> J58oLkSsg2zgydVu appears to be a naughty person; no btcint= in name, and fired me a request immediately on startup, Authorisation failed. Hmm!
06:19 < waxwing> well, not sure, timing may be coincidence.
06:23 -!- Numin0us [~Numin0us@cpe-74-64-92-78.hvc.res.rr.com] has joined #joinmarket     
06:23 -!- Numin0us [~Numin0us@cpe-74-64-92-78.hvc.res.rr.com] has quit [Changing host]     
06:23 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has joined #joinmarket     
07:11 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #joinmarket     
07:27 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 244 seconds]     
07:28 -!- waxwing [~waxwing@62.205.214.125] has joined #joinmarket     
07:50 -!- tryingout [423786da@gateway/web/freenode/ip.66.55.134.218] has joined #joinmarket     
07:51 < tryingout> anyone knows how to adjust the mining fee in sendpayment.py ? I put 1 in joinmarket.cfg but still too slow getting confirmation due to low mining fee
07:54 < adlai> tryingout: there's no user-accessible way other than targeting next-block confirmation. when the network is quite congested, this may take a while. you could manually edit the code to add a factor on top of the estimate, in the hope of getting ahead of everybody else who uses a similar estimate, but you'll have to edit the code for that
07:55 < tryingout> Thanks adlai
07:56 < adlai> tryingout: if you want to edit it yourself, i strongly recommend some familiarity with the surrounding code, but the place to make your change is probably https://github.com/JoinMarket-Org/joinmarket/blob/master/joinmarket/taker.py#L172
07:56 < tryingout> May I ask which code I have to modify in sendpayment.py? I just want to double up the default mining fee value
07:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
07:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket     
07:56 < tryingout> Sorry I just don't know Python 
07:56 < waxwing> if using Core, i'd dis-recommend using tx_fees = 1 in the config, since it's using "estimatefee" which sometimes returns "-1", and other times gets bad estimates i think
07:56 < tryingout> yes. it gave me -1
07:56 < adlai> waxwing: iiuc tryingout has done that, and wants to overpay for a better chance of quick confirmation
07:57 < waxwing> if using blockr, there is actually no difference between tx_fees =1 and tx_fees = 2, in both cases it uses blockcypher's "high_fee_est" which is usually quite reliable
07:57 < waxwing> adlai: yeah, got it, just saying "1" is unfortunately not working well for Core
07:57 < tryingout> I am using Core
07:57 < tryingout> then maybe I put 2 in joinmarket.cfg
07:57 < waxwing> that should be OK
07:58 < adlai> oh i see what you mean. estimatesmartfee could fix this, and we could fallback to estimatefee if it's unsupported
07:58 < waxwing> fwiw i did 2 transactions as sendpayment today with tx_fees = 10 and both times just waited like half an hour max.
07:58 < waxwing> adlai: yep
07:58 < adlai> but that's for the next release :)
07:58 < waxwing> maybe 45 minutes tops, didn't actually time it
07:58 < tryingout> There was a congestion recently
07:58 < waxwing> yeah next release :)
07:58 < waxwing> tryingout: yeah yesterday was the big spike
07:58 < tryingout> Since the Core gives me the estimatedfee -1
07:58 < waxwing> use 2, i think  you'll find it's OK
07:59 < tryingout> I'll try with 2 in joinmarket.cfg
07:59 < tryingout> Thank you 
07:59 < adlai> tryingout: several people providing liquidity have complained of their coins being unconfirmed, it's quite a nuisance because it lowers market liquidity until they confirm
07:59 -!- tryingout [423786da@gateway/web/freenode/ip.66.55.134.218] has quit [Quit: Page closed]     
08:00 < waxwing> i think we just have to deal with it for now, it's not the end of the world as a maker if a taker provides that problem for him, it happens rarely, and right now having the system work at all is our focus :) considering that we have malicious makers in the pit.
08:07 < JM-IRCRelay> [AlexCato] hm, maybe add a comment to the joinmarket.cfg config that the lowest number to be chosen should be 2 (and not 1)
08:09 < JM-IRCRelay> [AlexCato] can quickly do a PR for that, but then again this is a trivial change and could just be directly pushed by waxwing/adlai. Thoughts?
08:11 < JM-IRCRelay> [AlexCato] or automatically set it to '2' internally when the user set it to '1'; but i prefer to honor user choices, even if they make bad ones
08:12 < adlai> AlexCato, maybe that should go together with the release, which will happen today or tomorrow anyway
08:13 < JM-IRCRelay> [AlexCato] yeah, if its just a comment change, that should be in the release
08:20 < waxwing> def gonna be tomorrow now :)
08:21 < waxwing> as for that, i think don't change it. at the time i did fee estimation (long, long ago) i was not aware that estimatefee 1 was unreliable unfortunately
08:22 < waxwing> could change the comment though, yeah good point
08:30 < waxwing> adlai: ok, i'll just merge 643 then
08:31 < waxwing> for the dust, would it be ok to just revert it and do a new edit after release? as i mentioned above, of the 2 trials i did today one of them timed out and restarted due to a sub-dust change, not that it proves anything, but would be much better to avoid
08:32  * adlai already wrote up the change
08:37 < adlai> (now rebasing onto latest devel)
08:38 < adlai> patch being rebased is at https://github.com/adlai/joinmarket/commit/b908eefa295dc37e9a66e7bf2315fdd105341f25
08:39 < adlai> re: github & pgp, my pgp key has a bitmessage address as the "email" field, so github won't ever mark the commits as "Verified"
08:40 < adlai> sic transit gloria hubris
08:44 < waxwing> yeah i'm with you, that's fine as far as i'm concerned. saw someone else complaining about that recently too.
08:47 < adlai> ugh. i'm going over the history for this rebase, and there are unnecessary merges
08:48 < adlai> AlexCato: please try to avoid things like e3aa943 making their way into PRs
08:48 < waxwing> i'm confused about this line: https://github.com/adlai/joinmarket/commit/b908eefa295dc37e9a66e7bf2315fdd105341f25#diff-e5ebbf3237752f0c78e5834760582020R223
08:48  * adlai will gladly help rebase/untangle history to get rid of such knots, if you're willing to wait for a non-immediate reply :)
08:49 < waxwing> isn't that one "ours" so to speak, therefore we want to use the "new" concept of dust threshold there?
08:49 < adlai> waxwing: old code would donate dust to miners up to the higher threshold
08:49 < adlai> at least, that's how it seems
08:50 < adlai> you can probably convince me we should stick with the new threshold here, but i think it's a fair place to use the old one instead
08:50 < adlai> no strong opinion either way.
08:50 < waxwing> no that's fine, me neither
08:50 < adlai> belcher: ?
08:51 < waxwing> apart from that it all looks good to me
08:51 < adlai> yeah it's a rather trivial change (and a few trivial whitespace snips)
08:52 < adlai> AlexCato: 0847158 also makes me grumpy...
08:53 < adlai> there are a bunch more extra history tangles we could really do without. i'm gonna stop listing each one but PLEASE let's try and avoid these in the future. rebase exists for a reason.
08:54 < waxwing> yes in the old days i saw this kind of thing quite frequently, in my stuff and belcher 's in the old days as i remember, recently i started using rebase too
08:54 < waxwing> this is quite helpful i think: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
08:55 < waxwing> apologies i didn't pay attention in the case of the logging PR actually.
08:56 < adlai> also while we're on gittiquette, it's good practice to use the first line of a commit message as a "subject line", leave a blank line, and then give a more detailed description
08:56 < adlai> pretty much everybody messes this one up sometime or other
08:56 < waxwing> adlai: yes, good point also, will try to start doing that properly from now on. you can maybe add some edits to contributing.md or whatever.
08:56  * adlai focuses rn on rebasing the trivial patch which doesn't rebase cleanly, probably due to the log.debug changes
08:59 < adlai> ... and please stick to 80-column rows in the commit message body
08:59 < waxwing> i would have just done a revert commit on top of what's there, i guess that's too lazy?
09:00 < adlai> well i do want to avoid creating tiiny dust, as much as possible
09:02 < waxwing> oh right i just meant git-wise :) but i'll leave you to it :)
09:04 < adlai> https://github.com/JoinMarket-Org/joinmarket/blob/develop/sendpayment.py#L43 ^_^
09:04 < adlai> can't direct_send over 100btc at once?
09:04 < waxwing> heh i'm scared :)
09:05 < waxwing> i know it's ridiculous, why any particular number. just didn't want to "leave it blank".
09:05 < adlai> i can see the argument for leaving it in, but someday, somebody will show up here asking why they can't drain their wallet in one direct send...
09:05 < waxwing> maybe shoulda set it to like 10, if anyone really cares they can edit.
09:06 < adlai> also general python question, shouldn't we avoid import statements within function bodies?
09:06 < waxwing> i could easily imagine that's considered bad, but i haven't stuck to that rule. i think it appears once or twice elsewhere.
09:08 < waxwing> now i recall, the (poor) thinking behind that assert 100 was the wish to avoid typos, but we don't have that issue it's the other way round (re: satoshis vs btc)
09:27  * adlai motions to bump minimum_makers to 3
09:28 < adlai> 2 is the bare minimum for getting some nonzero privacy increase, i think the default should be higher.
09:29 < waxwing> default 4,6 with min 3 leaves breathing room for only 1.
09:29 < waxwing> first time i tried today with -N 6 i got 3 of the nonresponders.
09:29 < waxwing> i think that was unlucky to be fair
09:29 < adlai> min 3, default 5,7?
09:30 < waxwing> yeah maybe that's better.
09:30 < adlai> gives a breathing room of at least 2/5, and defaults to giving non-minimal privacy
09:32 < waxwing> to be strictly accurate min 1 is a non-zero privacy increase :) just not what we really intended :)
09:33 < adlai> ehh, it gives the taker no privacy from the maker
09:34 < adlai> sorry if i missed the discussion of this, but how does complete-with-subset interact with sweeping?
09:34 < waxwing> it doesn't, it says in the PR, we can't do that. at least i don't know how.
09:34 < waxwing> which is a big limitation of course.
09:34 < waxwing> yes ofc no priv from maker, i was making the observation that that != no privacy at all
09:35  * adlai doesn't understand how the merged patch doesn't interact with the sweep code path?
09:35 < waxwing> choose_orders_recover is not set
09:35 < adlai> aha, thank you
09:37 < adlai> yes that makes sense now.
09:41 < GithubBot5678> [joinmarket] adlai pushed 1 new commit to develop: https://git.io/vXUm7
09:41 < GithubBot5678> joinmarket/develop 7b4b36a Adlai Chandrasekhar: Tolerate counterparties using the old DUST_THRESHOLD value...
09:42 < adlai> waxwing: may i bump to 3,5,7 as well?
09:42 < waxwing> yeah let's go with that, thanks
09:43 < waxwing> i'll merge 643 after  you've done that, and then do the release notes tomorrow. anyone wants to start running the latest that'd be appreciated.
09:44 < waxwing> btw i put an error message in so if anyone does -N 2 with default min 3 it shows an error *before* wallet sync, so that should be OK.
09:45 < adlai> re:643, I do wonder whether it might not be preferable to leave it configurable, and default to NOT accepting notifications from other hosts
09:45  * adlai comments this on the issue
09:45 < waxwing> so educate me, with 0.0.0.0 the difference is it accepts external connections?
09:46 < waxwing> i should read up on it but haven't got round to it
09:46 < adlai> that's how i understand it behaves, yes.
09:47 < adlai> http://stackoverflow.com/a/20778887
09:47 < waxwing> well even if it's like 5% controversial then we can just leave it till later. 
09:47  * adlai adjusts his controvertiality rating to 15%, so mean remains above 5% :P
09:48 < adlai> it does just open up another hole. not one that we know how to abuse, but... another hole.
09:48 < waxwing> k, understood, thanks
09:55 < adlai> while we're on borderline-bikesheds, why does tx_broadcast default to self?
09:57 < waxwing> prob just considered more reliable i guess. never thought about that much.
09:57 < adlai> re:tumbler.py, i suggest bumping from mean=5,sigma=1.5 to mean=6,sigma=1
09:58 < adlai> which should make it quiiite unlikely that fewer than 5 makers are tried in a tx
09:58 < adlai> without significantly increasing the chance of choosing ridiculously large sets (actually, past a certain point - decreasing)
09:59 < waxwing> sure, seems quite reasonable. the disappointment is we can't ameliorate blockages on the most critical transactions (the sweeps).
10:01 < adlai> i assume we should bump tumbler's minimum maker count as well, to at least four? if not five
10:01 < adlai> this is a distinct minimum from the subset-completion minimum_maker_count
10:01 < adlai> it's currently 3, which means we could still end up failing to get 3 non-flakes
10:01 < waxwing> ah. i had run a few tumbler tests with malicious makers before, but that was with min=2.
10:02 < waxwing> i agree, the default at least must not choose less than min..
10:03 < adlai> so, 4 or 5? you're more familiar with this code's behavior than i am.
10:04 < waxwing> we need that sanity check in tumbler as well as sendpayment, else infinite loop.
10:04 < adlai> which sanity check?
10:04 < waxwing> if makercount = 3 and minmakers = 4 it'll always restart :)
10:05 < waxwing> https://github.com/JoinMarket-Org/joinmarket/blob/develop/sendpayment.py#L387-L399
10:05 < adlai> i'm specifically asking about the tumbler.py command-line option minmakercount
10:05 < waxwing> yes i know, but it prompted me to notice this
10:06 < waxwing> i think, 4 for default if mean=5 and sigma=1 and minmakers=3
10:06 < waxwing> is OK, not that i have a very strong opinion
10:06 < adlai> well sendpayment has this, and the configuration i've edited has POLICY.minimum_makers = 3, options.makercount = [5,7]
10:07 < adlai> by minmakers=3 you mean POLICY.minimum_makers?
10:07 < waxwing> yes     
10:07 < adlai> i did put tumbler mean as 6
10:07 < waxwing> oh sorry my mistake, meant to be referring to your edit mean=6 sigma=1
10:07 < adlai> ok     
10:08 < waxwing> wow it's quite crazily over-specified now isn't it, mean makers, minmakercount, POLICY.minimum_makers :)
10:08 < adlai> yes...
10:08 < waxwing> the last two are actually different variables though :)
10:08 < waxwing> one is what you're requesting, one is what you're prepared to accept
10:09 < adlai> another nitpick: https://github.com/JoinMarket-Org/joinmarket/blob/develop/tumbler.py#L480 << this makes it look like the CLI syntax should be paren + comma, imo it should be formatted the same as https://github.com/JoinMarket-Org/joinmarket/blob/develop/tumbler.py#L454
10:10 < waxwing> ah yes, good call. that's pretty old.
10:10 < waxwing> i think that might have confused me once.
10:11 < waxwing> "deveation" spelling error too
10:11 < JM-IRCRelay> [AlexCato] 5,7 seems like a sensible default if we assume that there will always be 1+ non-responding makers. If they disappear, that might be an expensive experience for takers using default values. But I do agree that this is the best way for now, until adlai's improvement idea goes live (the thing i called 'choosing N+x makers')
10:12 < adlai> right now we have multiple reports of people running out of usable commitments
10:13 < waxwing> adlai: go with the 6, sigma 1 and it should be fine. when you push it i can run some tumbler tests.
10:13 < waxwing> actually i can do that now i guess.
10:14 < waxwing> adlai: by right now do you mean something you're seeing today, or generally recently?
10:14 < adlai> latter
10:14 < waxwing> oh, sure, yes, hence the hurry :) well, that and at least one other bugfix that's kind of long overdue
10:15 < JM-IRCRelay> [AlexCato] i also see: the last 10 coinjoin-attempts with my maker were unsuccessful. All in the 0.5-1btc range. So yeah, this problem exists right now. As said, I agree its the best solution for now
10:15 < waxwing> alexcato i'm a little suspicious of at least one bot that's making failed requests, just something i saw today.
10:16 < JM-IRCRelay> [AlexCato] yeah, also have several error messages like this: error<J55ua6iKwuAcMaTd> : Authorisation failed
10:16 < JM-IRCRelay> [AlexCato] from different users
10:16 < JM-IRCRelay> [AlexCato] or the same with different nicks
10:17 < waxwing> yeah it's hard to catch, but one pinged me when i joined, i checked and he had no btcint=
10:17 < waxwing> little point in playing detective though
10:19 < JM-IRCRelay> [AlexCato] btw, afk for a bit, but will read up later. Want a PR for an improved comment about the target block confirmation number (i.e. that 1 is bad and 2 should be lowest) ?
10:19 < waxwing> so i think: mean=6 sigma=1 minmakercount=4 POLICY.minimum_makers=3 ; adlai agree?
10:19 < adlai> ack     
10:20 < waxwing> alexcato i'll just do it now, better not waste another merge commit :)
10:20 < adlai> AlexCato: i can toss that in right now
10:20 < adlai> lol     
10:20 < waxwing> heh go on then
10:20 < waxwing> i'll do the tumbler test instead
10:20 < adlai> ack     
10:21 < belcher> <adlai> has anybody else tried using this on a messy wallet? where 'messy' means, it's been running for over a year, has had multiple deposits and multiple privkey-import-withdrawals, probably also used a negative fee at some point just to see what happens, etc <--- my wallet is like this
10:21 -!- freekevin [freekevin@gateway/shell/xshellz/x-hvlmwcmdesinrouj] has joined #joinmarket     
10:22 < belcher> i havent been able to reproduce the "f(a) and f(b) must have different signs", naturally your wallet is a very private thing so its hard
10:22 < waxwing> yeah i forgot to answer, i *did* try it like that, but it was many months ago. i got it working after some initial problem.
10:27 < adlai> AlexCato: fwiw, revealing too much about which errors you're seeing could tell people which bots are yours
10:28 < adlai> there's a fine balance between giving helpful bug reports, and compromising your own privacy :)
10:29 < belcher> <adlai> while we're on borderline-bikesheds, why does tx_broadcast default to self? <--- when i wrote it i wanted to test it a bit for one release, planned later to make the default random-peer
10:29 < adlai> should i make the default random-peer now, while i'm making this bikeshedding commit?
10:29 < belcher> <waxwing> wow it's quite crazily over-specified now isn't it, mean makers, minmakercount, POLICY.minimum_makers :) <waxwing> the last two are actually different variables though :) <---- this might mean the variable names are not descriptive enough
10:29  * adlai is in favor of default random-peer
10:29 < waxwing> yes that's true. to be fair, i bet very few are altering the default --minmakercount
10:30 < belcher> im in favour of random-peer
10:32 < waxwing> perhaps change for next (0.2.3?)
10:32  * adlai just amended it into his commit...
10:32 < adlai> speak now before i push?
10:34 < adlai> the only possible downside i can think of for random-peer is that it increases the chance your tx won't be broadcast, but you can always broadcast by hand
10:34 < adlai> i do think the privacy improvement is worth this inconvenience
10:34 < belcher> theres timeouts and retries
10:34 < belcher> its in Taker iirc
10:34 < adlai> it's still an increased chance of failure
10:35 < belcher> it was a necessary thing before coming up with random-peer, not-self, random-maker and all the other fancy broadcast methods
10:35 < adlai> waxwing: do you have a specific reason for not wanting this in 0.2.2?
10:35 < waxwing> yes, i don't want to do more tests mainly. what if there's some weird reason that it tends to fail a lot more?
10:36 < waxwing> i mean if you do it, i won't cry :)
10:37 < adlai> what happened to "move fast and break all the things"!
10:37 < belcher> was that ever in our philosophy? i was always more about "worse is better" ;)
10:38 < belcher> "make it crappy"
10:38 < belcher> ;) ;) :(
10:39 < belcher> brb rebooting
10:39 < adlai> "rename every variable minimum_makers"
10:40  * adlai flips a coin, for extra randomness
10:40 < waxwing> i did a lot of testing before pushing that complete-with-subset PR because it was a very invasive change. but also, always needed more eyes, like we just saw on minmakercount
10:41 < waxwing> also note the comment to push_tx in MessageChannel , it was way back in the day, almost forgot
10:41 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
10:41 < waxwing> i never made push to non-tx-peer work. hopefully random_peer is fine.
10:41 < waxwing> i have actually seen it used from time to time
10:42 < waxwing> hmm, i suppose it might work by luck, not actually sure
10:43 -!- freekevin [freekevin@gateway/shell/xshellz/x-hvlmwcmdesinrouj] has quit [Quit: vagina]     
10:43 < adlai> there is a test for it...
10:43 < waxwing> yes there is that :)
10:45 < waxwing> it doesn't actually test it though
10:45 < waxwing> it was written by belcher before the MessageChannel change, it's not testing that part of the code
10:45 < waxwing> what, you thought our tests actually did something? :)
10:49 < GithubBot5678> [joinmarket] adlai pushed 2 new commits to develop: https://git.io/vXU4l
10:49 < GithubBot5678> joinmarket/develop 7a41623 Adlai Chandrasekhar: Bikeshed defaults, update release notes, cleanup whitespace
10:49 < GithubBot5678> joinmarket/develop 107b270 Adlai Chandrasekhar: Add another release note
10:50  * adlai tried so hard to get this all in one commit, but the damn trapdoor wouldn't open
10:50 < waxwing> i thought you were just shooting for 1000 :)
10:50 < adlai> 1000 what?
10:51 < waxwing> we're up to 993 (including our stupid merge commits) :)
10:51 < adlai> oic     
10:51 < adlai> we should probably aim for the release before then
10:52  * adlai dinner
10:54 < waxwing> looking good so far, thanks
10:56 -!- freekevin [freekevin@gateway/shell/xshellz/x-hhpznvuangummvqw] has joined #joinmarket     
11:21 < waxwing> 14 tx tumbler ran ok with those defaults
11:25 < waxwing> cant' help having second thoughts about the bump from 2 to 3 now :) what's absolutely critical is that it should work, even if not optimally. i want this to reduce the amount of failures to a bare minimum, i fear it might not because people won't want to do -N 7 and up, because of the cost. it does rather depend on the user though.
11:25 < waxwing> afk for a little while
12:30 -!- buckowski [buckowski@gateway/shell/elitebnc/x-tqgiqniwwaahsdvu] has quit [Excess Flood]     
12:30 -!- buckowski [buckowski@gateway/shell/elitebnc/x-dshfyqzavccfhxnd] has joined #joinmarket     
12:47 -!- Socket_0x03 [~Socket_0x@c-66-176-87-156.hsd1.fl.comcast.net] has joined #joinmarket     
12:58 < GithubBot5678> [joinmarket] AdamISZ pushed 1 new commit to develop: https://git.io/vXUya
12:58 < GithubBot5678> joinmarket/develop a579ff4 Adam Gibson: tumbler: disallow minmakercount < config.POLICY.minimum_makers
13:07 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 260 seconds]     
13:09 -!- waxwing [~waxwing@62.205.214.125] has joined #joinmarket     
13:36 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
13:40 < JM-IRCRelay> [belcher] AlexCato ping
13:40 < JM-IRCRelay> [belcher] do you want to be op here? im the only op here and if someone came in spamming it would be annoying to have to mute the relay bot on freenode
14:20 < belcher> so all my coinjoins got confirmed, including the 4000sat/kb and 6000sat/kb
14:20 < belcher> even though https://bitcoinfees.github.io/#30m still says 53000sat/kb for 6 confirmations
14:21 < belcher> i thought it would only confirm when that line dipped to around about 5000sat/kb but seems this fee market functions differently
14:30 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has joined #joinmarket     
15:14 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Remote host closed the connection]     
15:57 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has quit [Ping timeout: 245 seconds]     
16:01 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Read error: Connection reset by peer]     
16:01 -!- lnostdal [~lnostdal@90.149.73.62] has joined #joinmarket     
16:06 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
17:06 -!- Socket_0x03 [~Socket_0x@c-66-176-87-156.hsd1.fl.comcast.net] has quit [Quit: Leaving]     
17:48 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has joined #joinmarket     
19:10 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 244 seconds]     
19:15 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #joinmarket     
19:38 -!- Socket_0x03 [~Socket_0x@c-66-176-87-156.hsd1.fl.comcast.net] has joined #joinmarket     
20:04 -!- Socket_0x03 [~Socket_0x@c-66-176-87-156.hsd1.fl.comcast.net] has quit [Quit: Leaving]     
20:05 -!- Socket_0x03 [~Socket_0x@c-66-176-87-156.hsd1.fl.comcast.net] has joined #joinmarket     
20:07 -!- Einherjer [~einherjer@69.64.40.177] has quit [Ping timeout: 256 seconds]     
20:22 -!- Socket_0x03 [~Socket_0x@c-66-176-87-156.hsd1.fl.comcast.net] has quit [Quit: Leaving]     
21:04 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has quit [Ping timeout: 245 seconds]     
21:16 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
21:18 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket     
21:35 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket     
21:37 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
21:53 -!- lnostdal [~lnostdal@90.149.73.62] has quit [Read error: Connection reset by peer]     
21:53 -!- lnostdal [~lnostdal@90.149.73.62] has joined #joinmarket     
21:54 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
22:59 -!- Numin0us [~Numin0us@cpe-74-64-92-78.hvc.res.rr.com] has joined #joinmarket     
22:59 -!- Numin0us [~Numin0us@cpe-74-64-92-78.hvc.res.rr.com] has quit [Changing host]     
22:59 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has joined #joinmarket     
23:04 -!- Numin0us [~Numin0us@unaffiliated/numin0us] has quit [Ping timeout: 250 seconds]     
23:27 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer]     
23:48 -!- coins123_ [~coins123@ip-244-225.sn1.clouditalia.com] has quit []     
23:49 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket