--- Day changed Thu Nov 10 2016
01:02 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-dbwvyireegjfjkav] has joined #joinmarket     
01:47 -!- owowo [ovovo@gateway/vpn/mullvad/x-eesgnexftnadgctu] has quit [Ping timeout: 244 seconds]     
02:33 < btcdrak> how long to send joins take to complete on average?
03:01 <@waxwing> btcdrak: it *should* be only a few seconds from start to broadcast, with the majority of time is taken by self-throttling to avoid irc getting upset. but:
03:02 <@waxwing> since we have a few makers not responding, the new "complete with subset" feature in 0.2.2 means you will often (even usually) timeout on the first negotiation phase, which adds maybe another 30 seconds or so of wait time
03:03 < btcdrak> also if you're in the middle of a send and accidentally terminate the send command before it has completed, can you resume or what happens?
03:03 <@waxwing> i guess it takes about a minute. i actually did one  this morning that took about 1 minute from !orderbook to broadcast
03:04 <@waxwing> btcdrak: if you're doing sendpayment and deliberately quit in the middle, you just start again from the beginning
03:07 <@waxwing> if you quit at the point where the fees are presented with a yes/no prompt, you don't use up a commitment, so you can do that as often as you like.
03:38 -!- rdymac [uid31665@gateway/web/irccloud.com/x-dydnvbspbzozkubg] has joined #joinmarket     
04:09 <@waxwing> 206 on cgan channel now
05:55 <@waxwing> commenting on a question from btcdrak :
05:55 <@waxwing> on reflection, the answer to your question is just "don't use a mixdepth where you deposited coins to external, and they're still there"; on reflection, this would be quite easy to code: sendpayment without a -m flag, the code chooses any mixdepth that (a) has enough coins and (b) does not contain coins in external
05:55 <@waxwing> (his question was something like "how do i know which coins can be spent and be relatively private", kind of a logical question :)
05:55 < btcdrak> Well it's defaulting to -m 0 which doesnt really make sense to me
05:55 <@waxwing> referring of course to use of sendpayment, rather than tumbler
05:55 <@waxwing> quite so, yes
05:56 <@waxwing> because people will almost always send to that one 
05:56 < btcdrak> I would expect that you'd never spend coins from m0 - but then maybe not everyone runs a yg also.
05:56 <@waxwing> i think it's a tremendously good point :) part of the issue is that it was always conceived that tumbler.py was "the" way to send coins with some privacy to a new location.
05:56 < btcdrak> waxwing: maybe if -m isnt explicitly specified it could be an interactive question
05:57 <@waxwing> yes, sure.
05:58 < btcdrak> waxwing: i see. My assumption was you just funnel in coins to m0, run the yg and your coins get unlinked slowly, then you spend them using sendpayments - if if lazy just grab some coins out of a deeper mixdepth.
05:58 < btcdrak> (directly)
05:58 <@waxwing> see, part of the issue is, what's the use case? we get people who put coins in a wallet, do a sendpayment or two, and that's that. in those cases the -m 0 default is logical, but the real question is, what is the person achieving? it's not *nothing*, but it's not that much. very tricky.
06:00 <@waxwing> whereas, for your use case, a default -m 0 is terrible :)
06:01 <@waxwing> but as we were saying, don't think of the higher mixdepths as "deeper"; after a reasonable number of txs as a maker, the mixdepths have no separate status, all depends on algo etc.
06:21 -!- owowo [ovovo@gateway/vpn/mullvad/x-furilvcnmnzeullu] has joined #joinmarket     
06:21 -!- owowo [ovovo@gateway/vpn/mullvad/x-furilvcnmnzeullu] has quit [Changing host]     
06:21 -!- owowo [ovovo@unaffiliated/ovovo] has joined #joinmarket     
06:21 -!- owowo [ovovo@unaffiliated/ovovo] has quit [Changing host]     
06:21 -!- owowo [ovovo@gateway/vpn/mullvad/x-furilvcnmnzeullu] has joined #joinmarket     
06:26 <@waxwing> btcdrak: the mental model you had (effectively a very slow tumbler, moving coins up the depths) is appealing but seems problematic: to drain coins from 0 to 1, you find as each tx passes, what you can offer (from 0) gets less and less, and most difficult is that you can't realistically empty 0 completely.
06:26 <@waxwing> from the Taker side it's fine of course, do a few txs of size you control, then a final sweep to take the rest.
06:30 < btcdrak> the yg (seems to) produce a lot of dusty outputs. if joins are looking for outputs that are at least 20% of the total spend, seems like coins available for spending will get less and less.
06:31 <@waxwing> you can use merge_greedy e.g. in the config to reduce how much dustiness you get
06:32 <@waxwing> generally speaking you're unlikely to have problems from a yieldgenerator wallet, i'd say very unlikely, even if you do a sweep from a mixdepth and spend all.
06:32 <@waxwing> but in theory i guess it's possible for it to cause a problem.
06:33 <@waxwing> you can also use direct send of course (e.g. you might consider that joins already done represent sufficient privacy upgrade, the extra join at the final step isn't necessarily important)
07:22 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #joinmarket     
09:36 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-ctgdweobnuquhglt] has quit [Ping timeout: 260 seconds]     
09:39 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-yffvmqugbxgpzcnf] has joined #joinmarket     
11:22 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
12:19 -!- Cory [~Cory@unaffiliated/cory] has quit []     
12:25 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
13:33 -!- juscamarena [~jus@2607:f380:a61:650:bcfe:aea5:c6f5:f3e6] has joined #joinmarket     
14:06 -!- juscamarena [~jus@2607:f380:a61:650:bcfe:aea5:c6f5:f3e6] has quit [Read error: Connection reset by peer]     
14:57 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-dbwvyireegjfjkav] has quit [Quit: Connection closed for inactivity]     
19:05 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer]     
19:07 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 252 seconds]     
19:07 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
19:17 -!- adlai [~adlai@unaffiliated/adlai] has joined #joinmarket     
19:23 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-qqhtwqgxpbnzlhow] has joined #joinmarket     
22:27 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-qqhtwqgxpbnzlhow] has quit [Quit: Connection closed for inactivity]     
22:58 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket     
23:02 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jivforlhhjsbmsbt] has joined #joinmarket     
23:03 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 256 seconds]     
23:06 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket     
23:23 < btcdrak> waxwing: if I run the wallet-tool.py <wallet> history command say every 24 hours, why does it always have to import another 500+ addresses each time. There doesn appear to be anything near that actual usage.
23:23 <@waxwing> btcdrak: it's a long story, but that's exactly why i told you to use --fast
23:24 <@waxwing> oh, but sorry there is another point here
23:25 <@waxwing> suppose you did 50 transactions, you might have processed another 50 attempts, that would be 100x2 addresses requested, that's 200 already, plus .. well, it's a long story, but the "extra" import might involve a "chunk" from each mixdepth such that it ends up being 500 more.
23:25 <@waxwing> when we had the spy people were "using up" hundreds of addresses per day like that, easily, but i guess nowadays it'd be rare to have as many failed requests as successful ones.
23:27 <@waxwing> addresses must be requested for new transaction proposals, whether they complete or not, to avoid reuse ofc