--- Day changed Wed Jun 08 2016 00:17 -!- adsf234lk5j [b9104df9@gateway/web/freenode/ip.185.16.77.249] has joined #joinmarket 00:17 -!- adsf234lk5j [b9104df9@gateway/web/freenode/ip.185.16.77.249] has quit [Client Quit] 01:27 < GithubBot5678> [joinmarket] AlexCato opened pull request #564: yg-oscill: fix empty filtered_mix_balance crash (develop...patch-2) https://git.io/vot1z 01:34 -!- proslogion [~proslogio@90.210.173.173] has joined #joinmarket 01:52 -!- RedEmerald [~RedEmeral@c-73-231-129-86.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 01:54 -!- RedEmerald [~RedEmeral@c-73-231-129-86.hsd1.ca.comcast.net] has joined #joinmarket 02:01 < waxwing> fluffypony: pong? 02:01 < fluffypony> gimme a sec 02:19 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 240 seconds] 02:23 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #joinmarket 02:39 -!- veqtrus [~veqtrus@cpe-366758.ip.primehome.com] has joined #joinmarket 02:43 -!- riclas [~riclas@bl6-5-65.dsl.telepac.pt] has joined #joinmarket 03:49 < GithubBot5678> [joinmarket] AlexCato closed pull request #564: yg-oscill: fix empty filtered_mix_balance crash (develop...patch-2) https://git.io/vot1z 03:58 < waxwing> :q 03:59 < waxwing> :) 04:28 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket 04:28 < waxwing> this is mostly for belcher_ ; prob not here right now but reads the log. 04:29 < waxwing> in handling failures of 1 out of N message channels, the issue of "ignored_makers" comes up. if the cause of maker messaging failure is a broken channel (either the taker or the maker or both (channel goes down entirely), then in the current code that maker is going to be set to ignored. 04:29 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Remote host closed the connection] 04:30 < waxwing> it's a cool feature and works well today, but i'm not sure how to deal with it. It came up when i was doing tests injecting connection failure into the taker, so he has to recreate the transaction (because he lost contact with 1 or more makers on the lost message channel) 04:30 < waxwing> if i drop the ignored_makers then the transaction can recreate and complete, but not sure of the best thing to do. 04:31 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds] 04:38 < waxwing> sorry clarification: "if i drop the ignored makers" means "if i don't set the ignored makers", i.e. disable the feature. 04:49 < waxwing> hmm. so from fairly aggressive testing, that works. but: we don't want to just lose that feature. i'll have a think. 04:53 < belcher_> waxwing: that happens because you only talk to a maker via one channel? 04:53 < belcher_> the way imagined it, makers have an incentive to connect to all possible channels, to have their offers reach the most possible takers 04:53 < waxwing> belcher_: it effectively locks talking to one party on one channel when the private conversation starts 04:53 < waxwing> yes, they do that. i'm talking about failing in the middle of tx negotiation 04:54 < belcher_> could you make it that it will use any messaging channel ? 04:54 < belcher_> in my multiirc code it would randomly pick one irc network 04:55 < waxwing> yes, it uses any. now i think of it, i thought i had coded it to "find" a lost party during negotiation (see if they were also available on another). 04:55 < waxwing> i will take another look at the code. 04:56 < belcher_> message channel cluster is a smart idea i think : ) 04:56 < belcher_> making the multi part be a message channel instead of just irc or something 04:56 < waxwing> the idea is to choose a channel to talk to the counterparty on and continue the privmsgs via that channel. if we lose it, it's a little tricky to "pick up" on another. 04:56 < waxwing> yeah the way it's coded it will work with others. 04:57 < waxwing> the main thing i still haven't done is on_nick_change. that's a bit difficult to even think what to do with. 04:57 < belcher_> what if instead for every chunk or message you randomly picked a channel to send it down, checking the maker is actually on the channel before sending 04:57 < waxwing> perhaps. 04:58 < waxwing> one nice thing with the way it's coded now is, one side can be privmsging on one channel while the other sends responses on a different one. 04:58 < belcher_> for nick changes, what i did was require makers use the same nicks on all channels, keep generating random nicks until its available on every channel 04:58 < waxwing> ah yes, i remember that crossed my mind yesterday. also nice is that if you try to get a nick on all channels at once you can't realistically get someone imitating you. but even that's a bit hairy. 04:59 < belcher_> MessageChannelCluster extends MessageChannel, reminds me in java of an InputStream that is made up of many input streams concat'd together 04:59 < belcher_> you could open 3 files and get InputStreams, put them in this InputStreamCluster and transparently read one after another 05:00 < waxwing> oh. i didn't do it like that. I just had MCCollection own a set of messagechannels. 05:00 < belcher_> yep 05:00 < waxwing> the joinmarket code is unchanged, it just has self.msgchan = MCCollection() 05:00 < belcher_> but MCCollection is a subclass of MessageChannel right ? 05:00 < belcher_> yes 05:00 < waxwing> not subclass. ownership. 05:01 < belcher_> but if you do self.msgchan = MCCollection() then self.msgchan.privmsg() and similar must work 05:01 < waxwing> i suppose that might be possible. confusing to me how that would work. 05:01 < waxwing> yes, true 05:01 < belcher_> its up to you how you write it, i just remembered OOP allows a nice way to do it 05:01 < waxwing> https://github.com/AdamISZ/joinmarket/blob/mc-collection/joinmarket/message_channel.py#L29-L46 05:01 < belcher_> like the InputStreamCluster example, its a subclass of InputStream and the data it reads comes from multiple other InputStreams 05:02 < waxwing> yes there might be some small benefit in refactoring it as an inheritance. it's not far off i guess. 05:02 < waxwing> it adds another level to some of the callbacks; others are pass-through 05:03 < belcher_> i get it 05:03 < belcher_> its already quite similar to inheritance from what i saw 05:03 < waxwing> i have it testing now with a configurable set of miniircd daemons, and injecting failure at specified times per test run. it seems to be working OK. but what we discussed above, i am going to look at it again. 05:03 < waxwing> to see if dynamic switching of channels can work better. i think it works in certain failure cases and not others. 05:04 < belcher_> oh another example is BufferedInputStream, which is itself a subclass of InputStream and within it contains another InputStream, but when you do in.read(1) it will read(1024) from the underlying and store it in a buffer 05:05 < belcher_> have you seen my post on github about setting an alert to tell users about the spies attacking joinmarket ? 05:06 < waxwing> no. hmm, that's probably a good thing to do. 05:06 < belcher_> its sad that its come to this but its the best thing to do IMO, we'll implement the fixes to add a cost to that attack and then remove the alert 05:07 < belcher_> ill still use joinmarket for my transfers, since it still provides privacy against everyone who isnt that spy 05:07 < waxwing> amusing thought - that will spam up my logs even more than now :) 05:07 < belcher_> alerts dont get recorded to the .log file, only the terminal 05:07 < belcher_> but yeah i guess it might be irritating 05:07 < waxwing> oh cool, good. 05:08 < waxwing> not that that's really a pressing issue :) 05:08 < waxwing> i think my IRC logs directory is even bigger :) 05:08 < waxwing> i backed it up a few weeks back, it's humungous 05:08 < belcher_> id like to say my blocks directory is bigger, but i run with pruning on this node now :p 05:21 < waxwing> oh, i remember now. the problem is: if you have an mchan fail while waiting for a message, you're never going to get it : the ctrprty sent it to that mchan, not knowing that you were in the process of dropping out. So in that case, no dynamism avoids the fact that you are going to have to recreate the tx. or.. i guess the ctrprty can notice you drop, and resend on another mchan where you've been seen. i'll think a bit on how realistic that is, it mig 05:21 < waxwing> ht be that falling back to recreating tx is more realistic. 05:21 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket 05:24 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 05:41 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket 05:48 < GithubBot5678> [joinmarket] veqtrus opened pull request #565: Alternative Bitcoin Core integration (develop...autojoin1) https://git.io/voqO6 06:47 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #joinmarket 07:05 -!- hill [5f95d33d@gateway/web/freenode/ip.95.149.211.61] has joined #joinmarket 07:06 < hill> I have coins in mix depth 2 and 3 07:06 < hill> How can I use them both for tumbling? 07:06 < hill> or do I have to target one mix depth at a time 07:13 < belcher_> hill: tell your tumbler to start from mixdepth 2 07:17 < hill> Thanks 07:17 < hill> is there anyway to increase teh speed? 07:18 < belcher_> configure it to wait less and create fewer coinjoins 07:18 < belcher_> which all comes at the cost of privacy, although how much is an interesting question 07:28 -!- MrHodl [~fuc@46.166.161.166] has joined #joinmarket 07:31 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket 07:44 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer] 07:44 -!- coins123_ [~coins123@ip-244-225.sn1.clouditalia.com] has joined #joinmarket 07:46 < hill> 2016-06-08 14:46:17,603 [PingThread ] [DEBUG] irc ping timed out 2016-06-08 14:46:17,605 [MainThread ] [DEBUG] line was zero length AttributeError("'NoneType' object has no attribute 'close'",) 2016-06-08 14:46:17,605 [MainThread ] [DEBUG] disconnected irc 07:47 < hill> Has the script stopped? 07:47 < belcher_> no it should try to reconnect 07:47 < belcher_> no, it should try to reconnect 07:47 < hill> Thanks 09:36 < GithubBot5678> [joinmarket] AlexCato opened pull request #566: yg-oscill: fix empty filtered_mix_balance crash (develop...yg_oscill_crash) https://git.io/voqxI 10:47 -!- proslogion [~proslogio@90.210.173.173] has quit [Ping timeout: 250 seconds] 10:59 -!- proslogion [~proslogio@130.159.234.177] has joined #joinmarket 11:01 -!- proslogion [~proslogio@130.159.234.177] has left #joinmarket [] 12:02 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket 12:04 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 12:09 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket 12:12 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 12:20 -!- MrHodl [~fuc@46.166.161.166] has quit [] 12:25 -!- mkarrer [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has joined #joinmarket 12:28 -!- grubles is now known as grbs 12:44 < waxwing> disconnects seem to be handled ok now on mc-collection. i re-instated ignored_makers based on the fact that in that very rare case i described above, it's hardly a disaster to have one less counterparty on a recreate. 12:45 < waxwing> i'll try a few tests on remote servers (freenode/cyberg) tomorrow and do a bit of cleanup, then PR probably. 12:45 < waxwing> belcher_: did you ever find any apart from cyberg supporting Tor? 12:56 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Quit: Leaving...] 12:57 < GithubBot5678> [joinmarket] AdamISZ pushed 2 new commits to develop: https://git.io/vomzB 12:57 < GithubBot5678> joinmarket/develop d01d5b1 Alex Cato: yg-oscill: fix empty filtered_mix_balance crash 12:57 < GithubBot5678> joinmarket/develop dfa25bd Adam Gibson: Merge pull request #566 from AlexCato/yg_oscill_crash... 13:05 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket 13:07 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 13:13 < waxwing> travis: https://travis-ci.org/JoinMarket-Org/joinmarket/requests : potential abuse detected, contact support, it says 13:35 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket 13:38 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 13:45 < hill> Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File "/home/amnesia/joinmarket/joinmarket/blockchaininterface.py", line 315, in run self.output_addresses)))['data'] File "/home/amnesia/joinmarket/bitcoin/bci.py", line 22, in make_request raise Exception(p) Exception: 13:45 < hill> has it crashed? 13:54 -!- viasil [~viasil@198.12.75.25] has quit [Ping timeout: 260 seconds] 14:17 -!- viasil [~viasil@198.12.75.25] has joined #joinmarket 15:12 < Giszmo> hiho. in joinmarket, addresses are derived from a bip32 master seed that you use, potentially for a very long time, right? 15:12 < Giszmo> This makes this master seed the ultimate incriminating material in case some agency was to force you to reveal your finances. 15:12 < Giszmo> Is there anything to address this (issue)? 15:15 < Giszmo> To mitigate, the user could be offered a seed that only covers (current and) future, but not past addresses at each start. This way it would be at his discretion to throw away old backups but that would not be possible with bip39 due to the hashing between 12words phrase and the master seed. 15:33 < pigeons> Giszmo: you can have backups or you can have no evidence but not both 15:34 < pigeons> so you can always choose to send your funds to a new wallet from a new seed and hope you got rid of all traces of the old one 15:35 < pigeons> yeah make sure you dont fall for anyone asking for the "master public key" too 15:48 -!- mkarrer [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has quit [] 15:50 -!- mkarrer [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has joined #joinmarket 16:16 < Giszmo> pigeons, if we would incorporate coinjoin in mycelium, we would want to protect the user from curious actors trying to deanonymize them (and by that, also others) by making it easy to move funds from account to account. 16:16 < Giszmo> If you generate the keys based on hash^n(passphrase), you could store intermediate hashes on the device instead of the passphrase. 16:16 < Giszmo> You could then allow the user to export any such intermediate hash as a new passphrase for example, to safely dispose of the old passphrase and the associated address chain. 16:23 < gmaxwell> by destroying key determinism you unlink the keys.. yes... at the cost of doing so. 17:49 -!- raedah [~x@172.58.41.91] has joined #joinmarket 17:54 < hill> Is there anyway to know if the tumbler is still running or not? 17:57 -!- veqtrus [~veqtrus@cpe-366758.ip.primehome.com] has quit [Quit: Leaving] 18:09 -!- hill [5f95d33d@gateway/web/freenode/ip.95.149.211.61] has quit [Ping timeout: 250 seconds] 19:09 -!- grbs [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 20:40 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket 20:43 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 21:20 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket 21:23 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 21:49 < Giszmo> gmaxwell: I don't want to destroy key determinism. Just create a chain of keys that you can explore in one direction only, giving the possibility of forgetting the key 0 after writing down key 1200, in order to smoothly destroy the generator for your 1200 last transactions. It would still be deterministic. just with the past being deleted. 22:04 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.] 22:23 -!- iinaj [sid110431@gateway/web/irccloud.com/x-ghaozcctjjakpudc] has quit [Ping timeout: 250 seconds] 22:25 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-jwjzkiwinnrrktcn] has quit [Ping timeout: 272 seconds] 22:31 -!- iinaj [sid110431@gateway/web/irccloud.com/x-iayowmdgxywjrnvx] has joined #joinmarket 22:33 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-btoxsexdzqtodijk] has joined #joinmarket 23:24 -!- coins123_ [~coins123@ip-244-225.sn1.clouditalia.com] has quit [] 23:24 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket