--- Day changed Tue Aug 16 2016
00:30 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket
01:29 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket
01:32 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
01:34 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
02:56 -!- Iriez [wario@distribution.xbins.org] has quit [Quit: changing servers]
03:05 -!- Iriez [wario@distribution.xbins.org] has joined #joinmarket
03:44 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket
05:21 -!- fqtw_ is now known as fqtw
05:30 < waxwing> emzy: still problems? all seems normal here
05:37 -!- megaddin [aladdin@gateway/shell/fnordserver.eu/x-tvantzhrviibwege] has joined #joinmarket
05:39 < emzy> still Host irc.cyberguerrilla.org not found: 2(SERVFAIL)
05:40 < emzy> some problem with the Nameserver of google (8.8.8.8)
05:40 < emzy> others work
05:41 < waxwing> emzy: ah ok i see, google specific
05:41 < waxwing> yeah host works for me, not sure what my nameservers are
05:42 < emzy> try # host irc.cyberguerrilla.org 8.8.8.8
05:46 < waxwing> yeah SERVFAIL
05:46 < waxwing> emzy: 
05:52 < emzy> its a dnssec problem: http://dnsviz.net/d/irc.cyberguerrilla.org/dnssec/
05:54 < waxwing> interesting, 'fraid i don't know how dnssec works, what are the implications of this?
06:00 < emzy> All NS-Resolvers with dnssec activated will give a SERVFAIL. Not only google
06:03 < emzy> real problem! The guy with the domain cyberguerrilla.org has to fix it at the provider Hetzner
06:03 < emzy> maybe problem at hetzner.de
06:04  * emzy is bussy at work... so slow replay
06:15 < emzy> waxwing: do you know the owner of cyberguerrilla.org?
06:18 < waxwing> no i don't. can anyone talk to the guys on cgan and chase this up?
06:19 < waxwing> i remember the name RedAcor somehow
06:48 -!- lnostdal_ [~lnostdal@155-117-11.connect.netcom.no] has joined #joinmarket
06:48 -!- lnostdal [~lnostdal@143-6-11.connect.netcom.no] has quit [Ping timeout: 244 seconds]
07:11 -!- HostFat [~HostFat@host16-126-dynamic.21-79-r.retail.telecomitalia.it] has joined #joinmarket
10:40 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 250 seconds]
11:11 <+JM-IRCRelay> [AlexCato] interesting, a crash
11:11 <+JM-IRCRelay> [AlexCato] AttributeError: 'NoneType' object has no attribute 'crypto_box'
11:12 <+JM-IRCRelay> [AlexCato] it's an
11:12 <+JM-IRCRelay> [AlexCato] AttributeError: 'NoneType' object has no attribute 'crypto_box'
11:12 <+JM-IRCRelay> [AlexCato] will upload crashlog
11:13 < waxwing> alexcato thanks
11:15 <+JM-IRCRelay> [AlexCato] full log: http://pastebin.com/zfJjSJbP
11:16 <+JM-IRCRelay> [AlexCato] or from where it gets interesting
11:16 <+JM-IRCRelay> [AlexCato] there was no activity 1.5 hrs before the first line
11:20 < waxwing> hmm, that makes perfect sense. i'm surprised it didn't crop up before (or maybe it did)
11:20 < waxwing> what i don't get is why we're getting podle verify fail, because the taker side checks that before it sends.
11:21 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket
11:22 < waxwing> several things to look into here, thanks
11:24 <+JM-IRCRelay> [AlexCato] got one more with a failed verify poodle on another yg, sec
11:25 <+JM-IRCRelay> [AlexCato] here: http://pastebin.com/K0iRkDCc
11:28 < waxwing> thanks. working up through the layers :) First fixing the crash on no crypto_box, then the higher stuff.
11:29 -!- ThisIsZenified [~ImCool@176.123.26.59] has joined #joinmarket
11:35 < waxwing> alexcato my bots don't have crashes, i'm going to check for verifypodle fails
11:37 < waxwing> interesting. doing "grep "reason:" logs/*.log shows a few fails, all of them are due to already consumed utxos or not old enough, or too small. no verify_podle fails.
11:37 <+JM-IRCRelay> [AlexCato] the bots both keps on running. The first one just couldnt reconnect to one of the IRC servers, but still was on the 2nd
11:37 <+JM-IRCRelay> [AlexCato] the 2nd bot just kept on going on all servers
11:37 <+JM-IRCRelay> [AlexCato] no crash there
11:37 <+JM-IRCRelay> [AlexCato] the first wasnt technically a crash, it was an exception. My bad.
11:38 < waxwing> right. i'm interested in the verify_podle fail. can you sanity check that your taker_utxo_retries is 3? that would cause it, but v unlikely
11:38 <+JM-IRCRelay> [AlexCato] its indeed set to 1
11:38 <+JM-IRCRelay> [AlexCato] wasnt me though iirc?
11:39 < waxwing> hmm could be a borked commit from me, i'll take a look around
11:39 < waxwing> it's set to 1 in test/regtest_joinmarket.cfg that's for testing runs
11:40 <+JM-IRCRelay> [AlexCato] all three YGs have set it to 1. I'll manually adjust it to 3
11:41 <+JM-IRCRelay> [AlexCato] wondered why one of the three YGs didnt have failed podle verifies, but i just didnt notice them. There they are as well
11:42 < waxwing> this will happen for real of course, the idea is that they get ignored on the re-create of the tx in recover. utxo still gets used up though.
11:43 < waxwing> (well, 1/3 of a utxo)
11:43 < waxwing> huh, and of course not if it's the first try :)
11:47 < waxwing> (no, in regtest version it's age that's reset to 1, not retries, cancel that)
11:56 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket
11:57 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Quit: Leaving...]
12:09 < waxwing> fixed that crypto_boxes bug; feel free to update when convenient, thanks
12:17 <+JM-IRCRelay> [AlexCato] all ygs updated. Thanks for fixing this!
12:19 < waxwing> k, thanks too, starting another tumbler
12:20 -!- Giszmo [~leo@2001:a61:32cf:d301:d12d:6d17:d34c:ed36] has joined #joinmarket
12:21 < waxwing> might be my busiest day yet on realnet; did they not get the memo? :)
12:22 <+JM-IRCRelay> [AlexCato] still better than not tumbling at all :) And if they happen to join with me, the anti-snoop protection works fine so far. So they'll still be able to improve privacy or at least plausible deniability
12:23 <+JM-IRCRelay> [AlexCato] but i concur, looots of activity the last 2 days
12:23 <+JM-IRCRelay> [AlexCato] also huge joins
12:23 <+JM-IRCRelay> [AlexCato] huge as in >30 btc in one go, etc
12:23 < waxwing> alexcato: anti-snoop protection?
12:24 <+JM-IRCRelay> [AlexCato] its more security by obscurity. I've modified my yieldgen to not answer to specific requests
12:24 <+JM-IRCRelay> [AlexCato] its still rather easy to detect the snoop
12:24 <+JM-IRCRelay> [AlexCato] but if that would be pushed to the repo, it would be super easy to adjust for the snoop
12:24 < waxwing> oh, good stuff. well they follow certain patterns as far as i can see, but the pattern can change, no?
12:24 < waxwing> i don't see a fundamental way around it
12:25 <+JM-IRCRelay> [AlexCato] it can, but didnt for weeks now
12:25 < waxwing> right
12:25 <+JM-IRCRelay> [AlexCato] i dont see a fundamental way around it either
12:25 < waxwing> it's a quantum phenomenon though, if you see what i mean :)
12:25 < emzy> DNSSEC Key is still expired: http://dnsviz.net/d/irc.cyberguerrilla.org/dnssec/
12:26 < waxwing> alexcato: second paragraph here, would be interested in your thoughts: https://github.com/JoinMarket-Org/joinmarket/issues/171#issuecomment-240118596
12:26 < waxwing> emzy: i was hoping someone would chase it up. we use an authenticated e2e encryption though, so only worry is potential dos
12:26 < waxwing> also that's why 0.2 has multiple servers :)
12:27 < waxwing> altho' it would help if someone could source another Tor-supporting server for us.
12:27 < waxwing> well say Tor/HS
12:28 < emzy> waxwing: main problem is that may will not find the IP-Adresses to the host.
12:28 < waxwing> alexcato "2nd paragraph" means starting "Apologies.." sorry
12:28 < waxwing> emzy: yes understood. there is the hidden service too btw
12:28 < emzy> and will only see sim python error
12:28 < waxwing> but i agree that is fairly fundamental :)
12:28 < emzy> some
12:29 < waxwing> there are 52 yg bots in the pit atm, actually a bit higher than a week ago, not sure what that means (if anything)
12:31 <+JM-IRCRelay> [AlexCato] about that paragraph: good idea in theory, but it might cause problems. On individual basis: if there's 50 btc in a maker's wallet and that last utxo is a 45 btc one, that will greatly reduce this makers potential income until it's able to be spent again
12:32 <+JM-IRCRelay> [AlexCato] on a group theory basis: if someone does a big join with 50 btc which is close to the limit of many makers, doesnt that effectively kill big joins for new takers for quite some time?
12:33 < waxwing> i'm struggling to apply Lagrange's theorem here :)
12:33 < waxwing> seriously though, probably for a little while, yeah, unless i missed something
12:35 <+JM-IRCRelay> [AlexCato] if a maker's goal is his own gains (and not necessarily privacy), from a game theoretic standpoint it is wise for him to ignore that limitation
12:35 < waxwing> there's a small race condition period before it's widely seen on the network, but then it gets removed from available utxo list
12:35 <+JM-IRCRelay> [AlexCato] eventually most people would do that, but maybe some dont have the skill to modify the code themselves to do it
12:35 <+JM-IRCRelay> [AlexCato] so it might still be a net positive for JM's overall privacy
12:35 < waxwing> i got a bit lost, what would the makers do? double spend?
12:36 <+JM-IRCRelay> [AlexCato] ignore the limitation that the last UTXO is unspendable by making their YG ignore that limitation
12:36 < waxwing> yes but if no opt-in RBF it probably wouldn't work would it?
12:37 <+JM-IRCRelay> [AlexCato] oh, you'd enforce that with a timelock?
12:37 < waxwing> it seems a bit over the top, if you're in a low liquidity environment like that, it seems a bit of a mess for what purpose? to accept a higher fee?
12:37 < waxwing> i'm pretty sure we're talking at cross purposes here :)
12:38 <+JM-IRCRelay> [AlexCato] alright, back to start. The idea is to "filter out" the last used UTXO from being used again right away; that filtering is done by the YGs themselves, basically voluntarily censoring themselves from using that UTXO. Did i get that right so far?
12:39 < waxwing> they remove that utxo from the available list when they see it broadcast on the network, basically
12:39 < waxwing> then recalc orders and reannounce (if necessary, not always so)
12:39 < waxwing> orders = offers :)
12:39 <+JM-IRCRelay> [AlexCato] alright. What stops those YGs from not removing the UTXOs because they still want to offer more coins to get more potential business?
12:40 < waxwing> but if they leave that offer unchanged (e.g. they have 2 utxos, 1 of 10btc, 1 of 50btc, and 50btc appears in a tx on network), ie they leave the 60 offer up, if someone asks for 40, the only thing they can do is allow for a double spend right?
12:41 <+JM-IRCRelay> [AlexCato] ah, we're talking about unconfirmed UTXOs. I didnt see that part
12:42 <+JM-IRCRelay> [AlexCato] Then I dont really see a problem with that. They shouldnt double-spend, just ignore the 2nd big request
12:42 <+JM-IRCRelay> [AlexCato] even under normal circumstances they wouldnt have been able to service it
12:42 <+JM-IRCRelay> [AlexCato] so nothing lost, no harm done to anyone
12:43 < waxwing> you can imagine allowing a re-use if it uses opt-in RBF *and* pays the maker more than the first one
12:43 < waxwing> but, meh, that's a bit over the top, can't see anyone doing that really
12:43 < waxwing> i mean, if the *first* one uses opt-in RBF :)
12:44 < waxwing> which it won't :)
12:44 <+JM-IRCRelay> [AlexCato] thats sort of what i"m already doing btw... i only re-announce offers if they deviate more than 30% from my previous announcements. If a big offer comes in, i just dont reply and provoke a timeout for myself at the taker's end
12:45 <+JM-IRCRelay> [AlexCato] true about RBF, but i believe this is such a unlikely thing to happen. Can you even replace an RBF transaction which isnt signed only by yourself?
12:45 < waxwing> right, this is similar thinking to what i had in that comment
12:45 < waxwing> (re "that's sort of")
12:45 < waxwing> essentially it's about "fuzzing" your offers(orders)
12:46 <+JM-IRCRelay> [AlexCato] then I've thought about it before within the last weeks, just implemented that a few days ago. Works nicely so far, should be additionally more confusing to snoops
12:46 < waxwing> re: RBF haven't looked into it, maybe a bitcoin wizard can chime in :) it certainly seems logical that everyone would have to sign that option
12:46 <+JM-IRCRelay> [AlexCato] so agree :)
12:47 < waxwing> yeah that's the main point of yg-pe, although it's very weak right now: don't reannounce unless you absolutely have to
12:47 < waxwing> 'cos reannouncement helps targetting, so it's like: with reduced reannouncement and utxo commitments, costs to spy are maximized. theoretically.
12:47 <+JM-IRCRelay> [AlexCato] then again, I guess this is more a double-spend thing, less an RBF issue. Just announce the new transaction with the double-spent UTXOs and a higher fee: miners will mine the higher fee one first
12:48 <+JM-IRCRelay> [AlexCato] but there comes a JM specific thing to the rescue:
12:48 <+JM-IRCRelay> [AlexCato] the maker doesnt actually set the fee!
12:48 < waxwing> although, i haven't figured out how much it hurst the spy's analysis to just have to wait and find out much later about the utxos you won.
12:48 < waxwing> s/won/own/
12:49 <+JM-IRCRelay> [AlexCato] yeah, all this will make it harder for snoops with minimal impact on regular use of JM, imho. So I'd say go for it
12:50 < waxwing> alexcato: you may consider PR-ing against 0.2.0 any improvements to yg-pe that make offers less likely to reannounce
12:51 < waxwing> yg-pe is really just -basic with that one tweak described above. also i factored out an abstract YieldGenerator class, so it's only the order creation algos in there.
12:51 <+JM-IRCRelay> [AlexCato] "sadly" I"ll be gone on holidays for a few weeks in a few days and still have tons of loose ends to tie up at work first. Doubt I'll be of much use coding-wise until I'm back
12:52 < waxwing> no worries. ideas are useful too; you can always write them down somewhere.
12:53 <+JM-IRCRelay> [AlexCato] e.g. i'm not sure that announcing 30% higher offers (worst case) are a good thing if everyone did that. Just me doing it wont create much problems. Need to think about it some more
12:54 < waxwing> yes, the fuzzing has problems on both sides.
12:54 < waxwing> lying high means creating confusion for taker, lying low reduces your profit.
12:55 < waxwing> that's why i wanted to start with the most solid concept: always better to not reannounce by the fact that your outputs didn't change the size of your biggest mixdepth.
12:55 < waxwing> unfortunately that has a trade-off too: it tends to equalize mixdepths rather than concentrate.
12:57 <+JM-IRCRelay> [AlexCato] ...which again reduces profits. I've played around with that at the beginning as well, but didnt come to a clear solution: should i keep mixdepths equal? To still offer big joins, i reduced the mixdepths to 3. But is 3 equal mixdepths better for privacy than 5 unequal ones? I have no idea.
12:58 < waxwing> lower number of mixdepths is def worse for privacy in general; although it's hard to quantify.
12:59 < waxwing> unfortunately it's that old free market problem: without truly excellent measurement tools of your counterparty's behaviour, you can't judge whether the service they're offering you is worth the price.
13:00 < waxwing> if we had analytical tools that showed bad privacy setups by counterparties then the pricing signal would work better.
13:00 < waxwing> it's a bit like if you were selling a random number generator, you'd want a set of statistical tools to tell you whether the output was "truly" random.
13:01 <+JM-IRCRelay> [AlexCato] yeah, there were some "age of UTXOs as quality" ideas thrown around, which sounded like good starting points. But also like hard to implement
13:01 -!- HostFat_ [~HostFat@host16-126-dynamic.21-79-r.retail.telecomitalia.it] has joined #joinmarket
13:01 < waxwing> not too hard to be fair; that's already in the commitments code.
13:01 < waxwing> but age of a utxo is just one factor here.
13:02 <+JM-IRCRelay> [AlexCato] and yeah, same conclusion: thats why im back to 5 depths. Another way that comes to mind (assuming 5 depths, trying to balance income/privacy): keep one mixdepth at 50% of the total sum. Use the others for the majority of all joins, which are smaller anyways, and only tap into the 50% if absolutely necessary. That will reduce the need to re-announce as
13:02 <+JM-IRCRelay> well
13:02 <+JM-IRCRelay> [AlexCato] while probably not losing much business
13:04 < waxwing> that's kind of sort of what happens anyway in yg-pe; it'll source from smaller mixdepths and send back to that smaller set. but the algo needs tweaking if it's to preserve the big one in the widest range of scenarios.
13:04 < waxwing> just haven't had time to go into more detail on it
13:04 <+JM-IRCRelay> [AlexCato] oh. As you notice, I didnt even look at it yet
13:05 -!- HostFat [~HostFat@host16-126-dynamic.21-79-r.retail.telecomitalia.it] has quit [Ping timeout: 258 seconds]
13:05 < waxwing> well i haven't actually gamed out all the scenarios, i just wrote code that didn't tamper the biggest mixdepth if that's avoidable. that's all.
13:05 <+JM-IRCRelay> [AlexCato] the only thing i dislike about the basic-YG (=PE? as said, didnt look at it):
13:06 <+JM-IRCRelay> [AlexCato] i want to offer smaller amounts a lot cheaper to have some coins move around a lot (probably in the <5btc range), so offering them cheaper. Bigger amounts should be paid for a lot better though, so I prefer to have a lot higher cj fees there
13:06 < waxwing> yes, i commented on this in the blog post, privacy and "marketability" are at odds: the latter requires giving over as much information as possible.
13:07 < waxwing> consider though, that a taker who sees multiple orders may deduce "this maker is prioritising profit over privacy, i will choose the ones that announce the least"
13:09 <+JM-IRCRelay> [AlexCato] too easy to game that. Makers could still move around coins a lot, just not ever announce changes. This rewards "cheating" makers even more than honest ones
13:10 < waxwing> we could consider removing offer broadcast entirely, the problem is it's the most efficient way of allowing people to update their state db.
13:10 <+JM-IRCRelay> [AlexCato] what do they need that for, actually?
13:11 <+JM-IRCRelay> [AlexCato] even as a tumbler, cant they just join the channel, !orderlist, do their thing, then disconnect until the next tumbling step, even using a new username (and if they use tor stream isolation, even a new irc identifier)
13:11 < waxwing> i guess it'll just gum up the message server since all the non-makers will just be !orderbook-ing all the time
13:12 < emzy> I have send an email to cyberguerrilla.org. maybe this will help
13:12 < waxwing> it's something that idly crossed my mind a few times, should look into it more. it makes it a lot harder to do things like orderbook watch, but that's not an issue really.
13:12 < waxwing> emzy: thanks
13:13 <+JM-IRCRelay> [AlexCato] yeah, losing orderbook watch isnt great; but you still get a rough idea about the market by looking at the number of nicks in the channels. That could be gamed too, of course, but thats no different than gaming the orderbook anyways
13:14 < waxwing> yes tumbler would have to !orderbook at every step, but no big deal really. in the worst case it leads to more N^2-y scaling instead of N but, still
13:14 < waxwing> note that if we consider it OK for every participant to !orderbook, the attacker does the same. it probably doesn't change much.
13:15 < waxwing> watching tumbler, yg-pe seems quite good at not reannouncing. i have one with that and one without.
13:15 < waxwing> but amount is small so there's that.
13:17 < waxwing> hmm not sure my logic is totally sound about "attacker does the same". it's a bit tricky.
13:17 <+JM-IRCRelay> [AlexCato] its definately a big improvement. Unsure about oscillator (never looked into it), but basic/deluxe announce quite often, due to concentrating the coins
13:19 <+JM-IRCRelay> [AlexCato] !orderbook only ever becomes a problem in trying to correlate coin movements to the !orderbook requests imho. If current tumblers stay in the irc channel all the time with their unchanged irc nick, correlation should be not that hard to tie to different joins?
13:20 <+JM-IRCRelay> [AlexCato] attacker doing the same somewhat helps for outside parties to "balance the lines" (as a poker player would call it, basically adding noice for other watchers). But for the attacker himself, he knows when it was him !orderbook'ing
13:20 <+JM-IRCRelay> [AlexCato] noice=noise
13:21 <+JM-IRCRelay> [AlexCato] and forget the same irc nick thing. I forgot that a tumbler doesnt have to !orderbook again, as he can watch the announcements in the channel
13:21 <+JM-IRCRelay> [AlexCato] not relevant.
13:21 <+JM-IRCRelay> [AlexCato] anyways, lots of food for thought. I'm gone for a while, thanks for the chat!
13:22 < waxwing> thanks to you :)
13:34 < waxwing> btw i didn't understand the last few messages. the attacker is looking at order (re)announcements to narrow down who to spy on, i don't think the occurrence of "!orderbook" is useful for spying?
14:32 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]
14:49 -!- HostFat_ [~HostFat@host16-126-dynamic.21-79-r.retail.telecomitalia.it] has quit [Ping timeout: 244 seconds]
15:01 -!- HostFat [~HostFat@host16-126-dynamic.21-79-r.retail.telecomitalia.it] has joined #joinmarket
17:13 -!- Giszmo [~leo@2001:a61:32cf:d301:d12d:6d17:d34c:ed36] has quit [Ping timeout: 250 seconds]
18:31 -!- HostFat_ [~HostFat@host54-89-dynamic.7-87-r.retail.telecomitalia.it] has joined #joinmarket
18:34 -!- HostFat [~HostFat@host16-126-dynamic.21-79-r.retail.telecomitalia.it] has quit [Ping timeout: 244 seconds]
19:59 -!- fqtw_ [~me@x590cbcb4.dyn.telefonica.de] has joined #joinmarket
20:03 -!- fqtw [~me@x590c042f.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
21:29 -!- fqtw_ is now known as fqtw
22:50 -!- HostFat_ [~HostFat@host54-89-dynamic.7-87-r.retail.telecomitalia.it] has quit [Ping timeout: 244 seconds]
22:55 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket