--- Day changed Sun Nov 06 2016
00:31 < waxwing> lol https://twitter.com/hsjoihs/status/792206474902515712
01:06 < JM-IRCRelay> [mrnice] hi all!
01:19 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-yzzalyzuundaokdy] has joined #joinmarket     
02:46 < JM-IRCRelay> [mrnice] hi all!
03:38 -!- emzy [~quassel@raspberry.emzy.de] has quit [Remote host closed the connection]     
03:39 -!- emzy [~quassel@raspberry.emzy.de] has joined #joinmarket     
03:45 < waxwing> mrnice hello :)
03:46 < JM-IRCRelay> [mrnice] ah. sombody is alive ;-)
03:48 < JM-IRCRelay> [mrnice] I am working on some graphing and was wondering how best to graph JM profits. I am using cacti and would eg like to pull daily revenue from the wallet history. Any pointers for me?
03:48 < waxwing> mrnice generally on irc, people don't respond to 'hello' or 'help' type callouts, but doesn't mean people aren't listening :)
03:48 < JM-IRCRelay> [mrnice] ;-) just being polite...
03:49 < waxwing> yeah it's a slightly different etiquette. you can just say "hello all, i want to know X" for example.
03:49 < waxwing> i guess the main point is it's not a real-time conversation. except when it is :)
03:51 < waxwing> for tracking profits you can just read from yigen-statement.csv as it adds new lines. for more sophisticated analysis (in particular taking account of deposits/withdrawals) look into the history option in wallet-tool, or i guess you already did perhaps.
04:04 < JM-IRCRelay> [mrnice] yeah, I saw those options, but cacti is setup for polling, so I need to find a way to poll "the last period xx". This saves me from having to do cumbersome date calculations with the yg log or history option.
04:04 < waxwing> you could read the csv file at intervals, the transactions have timestamps.
04:05 < waxwing> oh "without date stamps", well just look at the diff to last i guess.
04:06 < JM-IRCRelay> [mrnice] yes, sure, but it would require some date analyses. cacti is setup to poll, while JM is more suited to push data.
04:08 < waxwing> i don't know about cacti, but i don't follow why just reading the file at intervals wouldn't work fine as a poll mechanism, again you wouldn't have to read the timestamp if you don't want to, you can just see what's new since last polling.
04:28 < waxwing> alternative, poll the watch-only wallet on Core with an rpc call. better in some sense, but pay attention to doing it securely (especially if there are any non-watch only coins)
04:32 < JM-IRCRelay> [mrnice] yes, that is actually an idea. polling and looking for changes in the csv file (and adding up if there is more than one new line).
04:35 -!- megaddin [aladdin@gateway/shell/fnordserver.eu/x-nxfevqjvgbscfvkh] has quit [Quit: https://fnordserver.eu]     
06:01 < JM-IRCRelay> [mrnice] Anyone know what happened to the yg oscillator in the new 2.2.2 JM version?
06:02 < JM-IRCRelay> [mrnice] sorry 0.2.2 version
06:14 < waxwing> it could be supported in the joinmarket/custom-scripts repo, if raedah (who wrote it) wants to; i've given him and alexcato write permissions there. at the moment there is a randomized script there (which i've started using actually).
06:15 < waxwing> sorry joinmarket-org/custom-scripts is what i meant
06:32 < JM-IRCRelay> [mrnice] thanks for the pointer. Do you achieve better results with it?
06:36 < waxwing> the point of that randomizer is to address a privacy issue (fixed fees are a watermark)
06:36 < waxwing> but it needs more investigation.
06:37 < waxwing> i'm focused on something else at the moment. i've got a primitive setup working with a joinmarketd and a simple sendpayment setup in another (client) process. i'm thinking about how i might make a new repo for it; i could make it a branch but it's going to be a bit different to say the least.
06:38 < waxwing> i might just publish it as a branch for now, but be kind, it is quite ahem "unrefined" for now :)
06:40 < waxwing> here's an interesting point that cropped up as i was doing it: consider that you want the joinmarketd to just implement the protocol and not bitcoin (keys etc). this would have a huge advantage of being able to publish the daemon as a repo with no bitcoin dependency.
06:40 < waxwing> also the client could be published without a dependency on libnacl, somewhat nice.
06:40 < waxwing> but: the protocol uses bitcoin message signatures :)
06:41 < waxwing> so, although it seems fiddly, i think it's worth having the daemon explicitly request signatures by passing protocol messages back to the client.
06:52 < JM-IRCRelay> [mrnice] Yes, of course! (privacy issues). SHould have thought of that.
07:29 < raedah> its possible I may get some time to look at it in the coming months. I would have to get my head around what the new ygs are doing now.
07:29 < raedah> also noticing that some of the improved mixdepth selection code needs to be backported
07:31 < raedah> AlexCato should be capable of doing it too
09:03 < waxwing> raedah: thanks, if you (or anyone else) gets round to looking at that type of thing, you can now derive from joinmarket/yieldgenerator.YieldGenerator ; also i have a vague memory that they were working at the last commit in the 0.2.0 branch before they were removed.
09:04 < waxwing> where "they" is the alts mixdepth, deluxe, maybe not oscillator, perhaps didn't test that one, and in any case, don't take my word for it :)
09:29 < raedah> waxwing: saw your comment here https://www.reddit.com/r/Bitcoin/comments/59t48m/proofofstake_question/  PoS = 'just sit there accumulating more and more money.'  The way I see it, possible future interest returns get priced into the market rate so that all things stay equal.
09:33 < waxwing> interesting; consider the example of land ownership. the price of land, should i choose to sell it, will factor in the potential future income stream; but that doesn't alter the fact that i have that income stream without having to doing any work for it.
09:44 < waxwing> this is unfortunate https://www.reddit.com/r/Bitcoin/comments/5bfvef/wtf_is_up_with_mycelium_fees/ <-- i'd hope they have some kind of "absurd_fee_per_kb" but if they do it looks like it failed there.
09:49 < waxwing> huh, am i mad or didn't we have logs/*.log in our gitignore?
09:50 < waxwing> oh doh it's in logs/ :)
10:08 < waxwing> this : https://github.com/AdamISZ/joinmarket-daemon but very early days, nothing to do really yet, just if you're curious
10:15 < belcher> does the PoS/rentier objection apply to joinmarket? that is near-enough getting money for nothing
10:17 < waxwing> it's a good point! the counter argument that you're getting paid for the risk, but one could argue the same with staking i think? for sure interesting to think about.
10:17 < belcher> mrnice what kind of data do you want to collect for graphing JM profits? is the only problem with history that it requires sync'ing to do it?
10:18 < belcher> a lot of societies have been disturbed by the idea of usury, what you say of just getting an income for owning rather than working
10:18 < waxwing> otoh joinmarket is not a required protocol for participation
10:19 < belcher> i guess "getting paid to take risks" is one way of comforting yourself or justifying it
10:19 < waxwing> it's more like an investor; creditor and debtor choose to get together to perform an exchange of risk for income, not the same as e.g. central bank mandating interest rates/printing money, not the same as stake enforced by protocol.
10:19 < belcher> ah got it
10:19 < waxwing> i don't buy the usury is evil argument because of that voluntariness
10:20 < waxwing> where things go wrong is always where there is enforcement
10:21 < belcher> on one hand you could say using any cryptocurrency is voluntary, but on the other hand currency has a strong network effect so in some way you're forced to use it for some uses, dont know how sound this argument is
10:22 < waxwing> yes; and it's quite possible that, precisely due to the unfairness of unequal roles, network effects for PoS don't develop as strongly.
10:22 < waxwing> people always say mining is unfair, but i just dont' agree. i mean it's not *perfectly* fair, nothing is. but nobody whines about not being able to mine gold, and those who do it, do it in a very difficult competitive environment.
10:24 < belcher> it could be said mining was never *fair*, even when you could mine blocks easily on your laptop, the bitcoins you got were near-worthless
10:24 < belcher> i remember a discussion of mining on reddit where a miner came in saying "mining has never been profitable, yet im still here about ~3 years"
10:25 < belcher> presumably its like this because of how competitive it is
10:29 -!- mode/#joinmarket [+o waxwing] by ChanServ     
10:29 <@waxwing> belcher: i think we can remove the warning?
10:30 < belcher> yep     
10:30 <@waxwing> ok, i'll do it now
10:30 < belcher> we could remove it from the subreddit too?
10:30 -!- waxwing changed the topic of #joinmarket to: Welcome to JoinMarket: Increase Fungibility and Subsidise Your Fees | http://github.com/Joinmarket-Org/joinmarket | @joinmarket r/joinmarket | friends: #bitsquare #tlsnotary-chat | Live View: https://joinmarket.me/ob | Latest release 0.2.2
10:31 <@waxwing> belcher: yeah, if there's still one there
10:31 < belcher> and looking at CGAN, theres maybe 5 or 6 of the old-style names that use <0.2
10:31 <@waxwing> maybe replace it with a new one :)
10:31 <@waxwing> yeah long tail :)
10:32 < belcher> what should the new sticky be?
10:32 <@waxwing> wasn't it what can i do to help before? that was worthwhile, perhaps.
10:33 <@waxwing> i'm thinking to point people at joinmarket-org/custom-scripts too. i started running the yg-randomizer today, seems to be fine
10:33 < belcher> that is still there
10:33 <@waxwing> or was it yesterday
10:33 <@waxwing> oh right :)
10:33 < belcher> subreddits can have up to two stickies
10:33 < belcher> before the spying thing the second sticky used to be "post your effective yield rate"
10:34 <@waxwing> put agora's donation address somewhere might be good
10:34 <@waxwing> i put it in the release notes
10:35 <@waxwing> i noticed a small but annoying detail: we got up to ~ 50 bots on there but fell back. the way the config works is, if a field doesn't exist, the new default will be used, but if the field already exists, it won't be overwritten.
10:36 <@waxwing> and people understandably can't be bothered with joinmarket.cfg -> joinmarket.bak -> start script -> overwrite new default with your customisations.
10:36 <@waxwing> so, when we add *new* fields it's always fine, but when we change existing ones, people don't notice
10:36 < belcher> ah     
10:36 < belcher> hmm     
10:36 < belcher> yes i was wondering why theres less bots in agora
10:37 < kakobrekla> can i expect less fragmentation if i run the maker from single depth ?
10:37 < belcher> dont do that kakobrekla its bad for privacy
10:37 < kakobrekla> i fail to see that, most txes i observe only take 1 output anyway
10:38 < belcher> they make a change address though
10:39 < belcher> and if later the change address and coinjoin address gets combined in a transaction, that would allow unmixing of the earlier coinjoin
10:39 < kakobrekla> actually i have 90% of funds at the last depth right now
10:39 < kakobrekla> it seems they are aggregating there 
10:40 < belcher> depending on which yieldgen algorithm you use, most of them try to keep the coins aggregated
10:40 <@waxwing> kakobrekla: the system only works to the extent that makers allow coins to cycle through several mixdepths.
10:40 <@waxwing> in the extreme, if all makers used one mixdepth, all joins would be dis-entanglable. or whatever that word is.
10:41 < kakobrekla> isnt this contradictory ? trying to keep coins aggregated / cycle mixdepths as much as you can for privacy
10:41 <@waxwing> side note, i have a feeling one mixdepth doesn't even work, but let's say 2, would be terrible.
10:41 < belcher> no? why is it contradictory?
10:42 < kakobrekla> because aggregation implies 1 mixdepth
10:42 < belcher> they dont always aggregated into the same mixdepth
10:42 < belcher> when its choosing which mixdepth to spend from, if possible it will choose one that makes the balance of the highest mixdepth higher
10:43 < belcher> once they're aggregated a bit they can still be spent from that mixdepth
10:43 <@waxwing> belcher: that does depend on the bot.
10:44 <@waxwing> i coded yg-pe to do the opposite, as a way to make something that minimized re-announcements. it works, but it leads to long-run disaggregation.
10:45 <@waxwing> so it kind of brings us back to (a) custom scripts and (b) the various discussions had over the last month about the virtue of *lots* of reannouncement, randomly, as opposed to a strategy of re-announce minimisation.
10:45 < belcher> ah okay
10:45 <@waxwing> well, there's a ton to discuss on this topic, but hopefully other people can pick it up :)
10:46 <@waxwing> the one element that's quite surprising to me is that, after a couple of months, the spy has not reappeared.
10:47 < belcher> what made you think they'd reappear?
10:47 < belcher> like would they buy up some bitcoins and start doing the same thing but burning utxos
10:48 <@waxwing> well like in that "racing" blog post and earlier discussion, yeah, it wouldn't cost too much at all really to give it a go.
10:48 <@waxwing> my suspicion is that they do not feel able to reveal even one of their utxos.
10:48 < belcher> i wonder why not
10:49 <@waxwing> but that's based on ... very little :) the only other evidence that pushed me to say that was, the "blocking" bot recently was specifically not responding to !auth.
10:49 <@waxwing> well, otoh they could "respond" with made up data. but anyway.
10:50 <@waxwing> yeah about 80% chance i'm wrong. but it's hard to guess what's really going on.
10:52 < belcher> i wonder whats happening with the mass connections to bitcoin nodes
10:52 < belcher> they just use up connection slots right?
11:10 < arubi> do yigens usually coinjoin with the same other yigens?
11:11 < belcher> takers choose multiple makers to coinjoin with
11:11 < belcher> most makers are yield generators
11:12 < arubi> right, more makers than only yigens, but yigens tend to stick around to the channel right?
11:12 <@waxwing> arubi: if i get the sense of your question, the answer is generally no due to randomisation in offer choice
11:12 <@waxwing> (on the part of takers)
11:12 <@waxwing> but it does of course depend on how much liquidity is there in the pit
11:13 < arubi> I'm wondering if over some period, you'd have some steady stream of cj's from familiar..  ah so not even over long times?
11:13 <@waxwing> if the liquidity is thin, the taker's choices may be very limited, in those cases, he'd be repeatedly joining with ~ the same set
11:14 < arubi> I see, I guess this isn't usually the case?  was trying to imagine some local reputation system that yigens have with other yigens
11:14 <@waxwing> afk     
11:14 < arubi> thanks waxwing 
11:15 < arubi> thanks belcher too :)  I guess it doesn't happen too much
13:46 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket     
13:54 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 260 seconds]     
14:04 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket     
16:59 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
17:07 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #joinmarket     
18:21 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 250 seconds]     
18:27 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-yzzalyzuundaokdy] has quit [Quit: Connection closed for inactivity]     
18:31 -!- megaddin [aladdin@gateway/shell/fnordserver.eu/x-nroxxmsxsnjurcel] has joined #joinmarket     
19:09 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 258 seconds]     
19:18 -!- adlai [~adlai@unaffiliated/adlai] has joined #joinmarket     
20:00 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket     
21:02 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-amndriljvxezdqkn] has joined #joinmarket     
23:48 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket