--- Day changed Sun Nov 27 2016
00:09 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
01:02 -!- Goood [64084466@gateway/web/freenode/ip.100.8.68.102] has quit [Ping timeout: 260 seconds]     
01:41 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]     
01:41 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket     
02:44 -!- so [~so@unaffiliated/so] has joined #joinmarket     
04:17 -!- Anduck_ [~Anduck@unaffiliated/anduck] has joined #joinmarket     
04:17 -!- Anduck_ [~Anduck@unaffiliated/anduck] has quit [Client Quit]     
04:32 <@waxwing> does anyone know what he meant by "Released V4"? seems a bit worrying.
04:42 < teenis> JMBinary is v4
04:42 < teenis> but I doubt that's it
04:42 <@waxwing> teenis: yes, i know, but apart from the fact it's not currently working, you wouldn't see that string.
04:42 <@waxwing> yeah. had the same thought.
04:52 < belcher> AlexCato thats actually not what i meant regarding the < 144 thing
04:52 < belcher> posting on the PR
04:57 < belcher> fee rates have dropped, at least for this weekend
04:58 <@waxwing> belcher: i pushed alexcato in that direction because it makes more sense (imo) to keep the change within the class, rather than assuming the function will only be called in one place
04:58 < belcher> i see
04:59 < belcher> right well the word "estimate" implies it would somehow guess rather than take a user input?
05:00 <@waxwing> true
05:00 < belcher> its a style/aesthetic thing ofc
05:04 <@waxwing> yeah. i guess it comes down to whether the behaviour should be considered global or not, i.e. should it always work like that. but, i take your point for sure.
05:05 < belcher> im happy with it going either way
05:05 < belcher> maybe its better to keep it this way just because its already written?
05:06 < belcher> then maybe replace the word "estimate" with "get" ?
05:06 < belcher> i think the wording of stuff is quite important since after a few months they can really help with remembering what certain parts actually do
05:07 <@waxwing> yeah i could see both being OK, maybe i lean more towards your original POV now, which i'm reluctant to say because i was the one who suggested changing it :) i just didn't like the cognitive load of, if in future you need to call estimate fee somewhere else, you have to remember to add the >144 interpretation.
05:08 <@waxwing> but maybe not, if things like this are well encapsulated in the wallet.
05:09 < belcher> right so you could call wallet.estimate_tx_fee()
05:09 < belcher> well one day we will have maker offers that talk about fee rate instead of just fee, so this estimate_fee_per_kb() would be used there..
05:09 <@waxwing> yes. working on electrum helps bring this into focus. there is so much advantage when everything bitcoin related (e.g. signing) is deferred to the wallet. but that broadens the discussion a bit too much :)
05:10 < belcher> how about a new function inside BlockchainInterface called something like get_fee_per_kb() which is in the abstract base class and has the 144 logic inside, so then all code just calls that and nobody calls estimate_fee_per_kb()
05:11 < belcher> and that way new implementations of blockchaininterface just implement estimate_fee_per_kb() however they know
05:11 <@waxwing> i don't follow exactly how that's different from what alexcato has now?
05:12 < belcher> 1) it makes the name estimate_fee_per_kb() wrong and 2) every new implementor of blockchaininterface has to have the two lines involving fee_per_kb_has_been_manually_set()
05:13 <@waxwing> definitely agree for the name. i just didn't quite follow how it's avoiding that duplication? oh, you mean you call the method of the base class?
05:14 <@waxwing> if so, yes, got it, that's cleaner
05:21 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Read error: Connection reset by peer]     
05:21 < sturles> I get the following from wallet history: BUG ERROR: wallet balance (x.799...) does not match balance from history (x.813...)
05:21 < sturles> BUG ERROR: wallet utxo count (38) does not match utxo count from history (59)
05:21 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has joined #joinmarket     
05:22 < belcher> yeah sturles it sometimes happens
05:22 < belcher> i can never figure it out because the problem fixes itself more often than not
05:22 < belcher> do you have any unconfirmed transactions? thats probably one way of it happening
05:22 < sturles> No, not that I know of.
05:23 < belcher> 38 utxos vs 59 utxos is quite big.. im normally used to a difference of one or two
05:49 < sturles> Yep, and the balance difference is much more than a couple of fees.
05:54 < sturles> My addresses are reaching quite high numbers with large spreads.  E.g. m/0/1/1/703, m/0/1/1/825, m/0/0/1/007, m/0/0/1/452, m/0/2/1/001, m/0/2/1/521, m/0/4/1/000, m/0/4/1/145.
05:54 < sturles> Could this be a source of confusion?
05:59 < belcher> nah, my indexes are in the ~3000s 
06:01 < sturles> More weirdness.  I compare the output from wallet-tool now with an older version, and the balance at mixdepth 0 has increased.  How is that possible?  Shouln't my balance move from lower to higher mixdepth, not in the opposite direction?
06:01 < sturles> Balance at mixdepth 1 had decreased a little, while mixdepth 3 and 4 are the same.
06:02 < sturles> Total balance has increased by about 0.0002 BTC in the period.
06:02 <@waxwing> sturles: if you're running yg the balances move around both in up and down direction. depends on algo, but in general it's certainly not only one way.
06:03 < sturles> OK     
06:46 -!- Empty2k12 [~Empty2k12@p5790792D.dip0.t-ipconnect.de] has joined #joinmarket     
06:57 -!- tergi [4a4aed8d@gateway/web/freenode/ip.74.74.237.141] has quit [Quit: Page closed]     
07:28 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #joinmarket     
07:41 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 258 seconds]     
07:56 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #joinmarket     
08:41 < sturles> On which conditions will balance move from a higher mixlevel to a lower?
08:42 <@waxwing> sturles: depends on yg algo. example: say you want to avoid reannoucing orders. then, you want to make your output go to a mixdepth with a lower balance, so that maximum mixdepth doesn't change, and you don't reannounce.
08:43 <@waxwing> or, say you want to concentrate coins. then, you send the output to the mixdepth with the biggest balance at the moment.
08:43 <@waxwing> etc.
08:43 <@waxwing> just going upwards all the time can't work, not only do you have to manage an infinitely growing list of mixdepths, but the coins spread out and you're left with smaller and smaller amounts in each over time.
08:44 <@waxwing> or, well, depends on *exactly* how you did it i guess.
08:47  * waxwing will one day start using "offers" instead of "orders"
08:48 <@waxwing> worst is when you're writing code and trying to use "offers" but "offerbook" is not a word :(
08:50 < sturles> OK, so -pe will send to a lower depth to avoid reannouncing?
08:50 <@waxwing> yes.
08:51 <@waxwing> tbh i'm now not at all convinced that it's a good strategy. personally i'm running -randomizer now from alexcato
08:51 <@waxwing> see the custom-scripts repo
08:52 <@waxwing> there's a discussion about this on an issue opened by GAit 
08:52 <@waxwing> i don't mean to say it's a *bad* strategy, only that what it was trying to prevent does not really seem to be an issue, and in any case might be better addressed differently.
09:30 < sturles> I use -pe, and my coins are moving from a depth with high balance to a lower depth with much lower balance.
10:29 -!- mol [~molly@unaffiliated/molly] has joined #joinmarket     
10:32 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]     
12:29 < belcher> so i made the transaction sending the donation address money to me and other developers, went with a very low 2k sat/kb thinking it could take 24hours or more, in fact it confirmed after about 7 blocks
12:30 < belcher> this site (https://bitcoinfees.github.io/) is saying 70,000 to 50,000 sat/kb is needed, this site too https://statoshi.info/dashboard/db/fee-estimates so looks like many of these algorithms are overestimating? i know they add some safety but it still seems like a lot
12:32 < belcher> maybe implies the bullish "wow look how much people are paying in fees to use bitcoin" view is wrong/oversimplified?
12:32 -!- Goood [64084466@gateway/web/freenode/ip.100.8.68.102] has joined #joinmarket     
12:33 < Goood> isn't there supposed to be an IRC channel where yieldmakers publish orders?
12:33 < Goood> how can I join that, I want to test to make sure my bot is publishing orders
12:33 < belcher> yes, read your joinmarket.cfg to see the details
12:34 < belcher> theres two actually, cyberguerilla irc and agora irc
12:34 < belcher> but an easier way to do check if your offers are being published is to use the ob-watcher.py script
12:34 < Goood> awesome thanks Belcher!
12:34 < Goood> btw, I think I got JoinMarket working on Heroku, will put up a guide if this all works
12:36 < belcher> cool :)
13:22 < sturles> FFS!  Now almost all my balance is back in mixdepth 0.  How can I make my balance move in the other direction, to higher mixdepths?
13:22 < sturles> This time it came from mixdepth 2, and went directly to mixdepth 0.
13:23 < sturles> mixdepth 4 is almost empty.  One tiny output.
13:23 < sturles> mixdepth 3 is not enough to mention either.  So what is the point?
13:23 <@waxwing> sturles: what's wrong? i thought i'd explained that this is expected.
13:23 < JM-IRCRelay> [AlexCato] @belcher / miner fees: you were just lucky that the miners were finding blocks every 8-8.5 mins on average, clearing the backlog. Most fees would have worked... the estimation algos seem to adjust very slowly by probably just looking at the average fee per block
13:23 <@waxwing> you only make 1 offer from your maximum balance mixdepth at any time.
13:23 < JM-IRCRelay> [AlexCato] which can still be quite high, even if the block isnt full
13:24 < JM-IRCRelay> [AlexCato] thanks btw!
13:24 < sturles> waxwing: No.  It cannot be.  It used to be mixlevel 2 for a lont time, but coins have been moving from both mixdepth 1 and 2 to 0.
13:25 < sturles> Now it is mixdepth 0, of course.
13:26 <@waxwing> so what's wrong exactly? is the offer not the amount you expect?
13:26 < JM-IRCRelay> [AlexCato] sturles: it takes the lowest mixdepth, which is not max. So if you have 4 mixdepth (example: 0=15btc, 1=5btc, 2=10btc, 3=1btc) it will never touch mixdepth 0 if possible
13:26 < sturles> And why does it move the balance down?  Is this a new behaviour?  Am I supposed to fill up the wallet at mixdepth 0 or 4?
13:26 < JM-IRCRelay> [AlexCato] and just use the first mixdepth which fits, so starting with 1, then 2, then so on
13:27 <@waxwing> sturles: why does it move which balance down?
13:27 < JM-IRCRelay> [AlexCato] you're not supposed to fill anything. The YG is there to offer liquidity to takers, and it achieves that perfectly by this behavior. If you intention is to get you own funds mixed slowly, yg-basic might be a better fit
13:27 < JM-IRCRelay> [AlexCato] which just moves funds down
13:27 <@waxwing> alexcato what do you mean by "just moves funds down"?
13:29 < sturles> waxwing: It movws my coins from the higher mixdepths to the lower.  2->0 1->0.  I have been filling up my wallet at mixdepth 0, because I thought this was the low privacy depth, andit would mix my coins and move them upwards to higher mixdepths in the process.  This is obviously wrong.  Should I fill up at mixlevel 4 and spend from 0 instead?
13:29 < JM-IRCRelay> [AlexCato] using mixdepth0 for coinjoins, until it cant any more. Then continuing with mixdepth1
13:29 < JM-IRCRelay> [AlexCato] and so on
13:29 < JM-IRCRelay> [AlexCato] this was the default behavior in jm 1.x
13:29 < JM-IRCRelay> [AlexCato] changed with yg-pe
13:29 < JM-IRCRelay> [AlexCato] (0.1.x of course :)
13:30 < JM-IRCRelay> [AlexCato] i've tempered around with the mixdepth selection quite a lot on my own, so i'm familiar with the selection algorithms
13:30 < sturles> JM-IRCRelay: I have to fill the wallet when I spend something from it.  An empty wallet is useless.
13:30 < JM-IRCRelay> This is a relay bot
13:31 <@waxwing> sturles: oh i see, that's what your motivation is. the algos like mixdepth and -pe move in unpredictable directions. the -basic tends to move 0-1-2..4-0-1-2.. in a cycle.
13:31 < JM-IRCRelay> [AlexCato] sturles, you assumption is that running any YG is meant to make your funds more private. That assumption is not justified. yield-generator-basic fulfills your needs, but yg-pe does not
13:31 < sturles> So yg-pe will always move funds to depth 0 to have funds to use?
13:32 < JM-IRCRelay> [AlexCato] no, yg-pe moves it randomly
13:32 <@waxwing> sturles: as i said earlier today, its destination is basically unpredictable because it sends to the currently lowest-balance mixdepth, where that's possible.
13:32 <@waxwing> when i add coins to my yg wallet, i just add to one of the mixdepths, i don't see it making that much difference which. usually top up a lower balance.
13:33 < sturles> Wo it is the same where I spend from, then.
13:33 < sturles> *So     
13:33 < sturles> Same level of privacy at all mixdepths.
13:33 <@waxwing> after a while, it's more or less the same, i'd say.
13:34 <@waxwing> i mean, you could track it i guess; and early on, when very few transactions, then for sure theyre not all the same
13:34 <@waxwing> but i echo alexcato's comment that that isn't the basis on which the yg scripts were designed; they were designed to generate yield :)
13:34 < JM-IRCRelay> [AlexCato] you cant tell the privacy level of your mixdepths in yg-pe. If you have one mixdepth with a HUGE amount in it, it might never be moved at all. So as a default, i'd say: the mixdepth with the most coins in it probably is the least mixed one
13:34 <@waxwing> the privacy enhancement for the users is a (certainly very important) side effect
13:36 < sturles> IMHO there should be a yigen which mixes upwards to a certain level, then let the coins stay there.  Just spend from the lower levels, and when coins get to depth 4 they are done.  I.e. the user can transfer the coins back to a lower level if he or she wishes.
13:37 <@waxwing> yes, that's basically the tumbler design, but you want to do it passively. it's a nice idea i think.
13:37 <@waxwing> in practice, after reasonably long running, all the coins in a yg wallet have tons of mixes behind them.
13:38 <@waxwing> analysis tools to assess "mixed-ness" of utxos in a wallet would be nice, but that sounds hard, haven't thought about it.
13:39 < JM-IRCRelay> [AlexCato] i think adlai expressed ideas about that a while ago
13:39 <@waxwing> i guess it's worth saying that yg-basic kind of sort of half does what you want, because it *tends* to move coins up the levels. but don't forget that Makers have the issue that they cant choose the amount.
13:39 <@waxwing> in tumbler, we use sweeps to get everything out of one mixdepth up to the next. you can't do that maker side.
13:39 < sturles> I have some tiny outputs which tends to never move.  E.g. one at level m/0/0/1/001.
13:40 <@waxwing> yes this definitely happens. using a nondefault selection algo in the .cfg helps, but i think you can still get them.
13:40 <@waxwing> you can also think about minsize.
13:41 <@waxwing> well, minsize doesn't prevent dusty change, at least not "by force".
13:42 <@waxwing> at a general level, part of being a Maker is you don't get control over what your wallet looks like, at least not ultimately. you can for sure tweak it.
13:43 < sturles> IMHO yigen shouldn't create outputs smaller than 2 x txfee.
14:11 -!- tergi [4a4aed8d@gateway/web/freenode/ip.74.74.237.141] has joined #joinmarket     
14:27 < belcher> AlexCato the algorithm on bitcoinfees.github.io uses a fancy monto carlo solver, but it predicted 70k-40k sat/b
14:27 <@waxwing> plugin working not too bad now, from fresh ubuntu vm, just download joinmarketd, run, download electrum tar from releases in my repo, untar, run electrum and transaction worked OK.
14:27 <@waxwing> belcher: how many blocks did it take out of interest?
14:27 < belcher> i propose we change the names 'mixdepth' and 'mixlevel' since up here it just lead to confusion
14:27 < belcher> waxwing 7 blocks i think
14:28 <@waxwing> yes i agree it's an interesting finding. seems predictors have a very hard time getting it right.
14:28 <@waxwing> i suspect they have to include a lot of smoothing, and they should, but it makes it hard for the users who are edge cases (very high or very low time preference)
14:30 <@waxwing> ah so you mean that people would interpret 'mixdepth' as meaning that you actually have gone through N depths. yeah. never thought of that.
14:31 < belcher> yeah from reading how sturles got the wrong idea about it
14:31 < belcher> <JM-IRCRelay> This is a relay bot <--- forgot about this, lol :D
14:31 < belcher> maybe a better name would be "pocket" ? darkwallet used that name for a similar concept
14:32 < belcher> "mixpocket" even, would help get through the idea that the point of them is to separate coins for privacy
14:33 <@waxwing> yes. the fact that it's just separation, not necessarily ordering. that's quite a good name. "buckets" :) "accounts" is bip32, but that's not much help.
14:34 < belcher> buckets is good
14:35 < belcher> mixbuckets ?
14:36 <@waxwing> thanks for the transfer btw, must be a bit of a chore :)
14:36 <@waxwing> belcher: ^
14:36 < belcher> :)     
14:36 < belcher> i do it with a spreadsheet
14:36 <@waxwing> somehow that doesn't surprise me :)
14:37 <@waxwing> arubi would do it with `bc` :)
14:37 < arubi> I probably would and it'd take x20 the time :)
14:37 < belcher> bc ?
14:38 < arubi> `man bc` :P
14:38 < belcher> ah     
14:38 < belcher> iv never heard of this
14:38 < belcher> interesting
14:38 < belcher> for that kind of thing could you also use the python repl ?
14:38 < arubi> belcher, https://github.com/fivepiece/btc-bash/tree/master/bc :)
14:39 < arubi> it's WIP, always.  some things had to be done in bash, like hashing
14:40 < belcher> if its your program, how did it end up on my ubuntu ?
14:40 < belcher> did i misunderstand
14:40 < arubi> no no, bc isn't mine, but I write a lot of stuff for it
14:40 < arubi> such as ^
14:40 < belcher> ok     
14:41 < pigeons> its the second terminal window i open after screen to my irc and leave it open all day
14:41 < pigeons> (bc)
14:42 < pigeons> i know not as useful as piping stuff in and out of it but that's one main way i use it is interactively
14:42 < arubi> <3     
15:05 < adlai> bc is for quiche eaters, Real Programmers speak directly to dc
15:08 < pigeons> mmmm quiche
15:11 <@waxwing> test instructions updated; https://github.com/AdamISZ/electrum-joinmarket-plugin (quick install worked on vm earlier).
15:19 <@waxwing> heh, someone says he sent money to the donation address in the Electrum console (server operator), thinking it was his own address(?!) and now complains that the postal code corresponds to Buckingham Palace.
15:19 <@waxwing> https://www.reddit.com/r/Electrum/comments/5f79by/send_donation_adress_instead_of_mine/
15:20 <@waxwing> a bit suspicious, big multi-output tx.
15:20 <@waxwing> reminds me of that time i had to send coins back to the input because the guy had put it into the null seed :)
15:22 < arubi> ouch.
17:34 < tergi> for the mixing levels name thing, since bitcoin is commonly thought of as coins... coin purse, coin bag, coin pouch, 
17:44 -!- Goood [64084466@gateway/web/freenode/ip.100.8.68.102] has quit [Ping timeout: 260 seconds]     
17:57 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 248 seconds]     
18:00 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
18:18 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
18:50 -!- Empty2k12_ [~Empty2k12@p579061BF.dip0.t-ipconnect.de] has joined #joinmarket     
18:50 -!- Empty2k12 [~Empty2k12@p5790792D.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]     
20:33 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket     
20:33 -!- molz is now known as moli     
20:36 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 245 seconds]     
22:06  * sturles has dc in his second terminal.  Primed with some useful self-written macros.
22:43 -!- Good [64084466@gateway/web/freenode/ip.100.8.68.102] has joined #joinmarket     
22:43 -!- Good is now known as Goood     
22:44 < Goood> hey, so if I wanted to mix coins from my current non-JMKT wallet, could I just copy the .wallet file and run it off of that?
22:45 < Goood> on the other hand, its somewhat of a bind, because doing so will Tumble the coins, but return the coins to 'known' addresses, so it may be a worthless effort
22:45 < Goood> maybe its better to Tumble first, into a JM wallet, and then once mixed, then run the yieldgenerator on top of that mixed wallet
22:45 -!- coins123 [~coins123@unaffiliated/coins123] has quit []     
22:46 < Goood> is that the best approach?
23:06 -!- HostFat [~HostFat@host243-181-dynamic.61-82-r.retail.telecomitalia.it] has joined #joinmarket     
23:54 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket