--- Day changed Mon Feb 11 2019
01:07 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
02:13 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 250 seconds]     
03:34 < undeath> is #331 a useful metric for joinmarket? The calculated rate seems to depend only on the anonymity set of previous cjs and the current one, so is strictly monotonically increasing for every cj
03:35 < undeath> looking at the mix level inside the wallet does seem to give an almost identical metric
04:24 < undeath> oh, it's not strictly monotonically increasing, but that seems to just make it even more similar to the mixdepth
04:24 < waxwing> undeath, agree re: docs
04:24 < waxwing> haven't read 331 yet
04:27 < undeath> the major part of 331 consists of the Boltzmann.update method, which really doesn't do that much
04:27 < undeath> https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/331/files#diff-11f05e76035469edaa236f6441f8c418R90
05:17 < belcher> i also think that boltzmann metric is not necessarily helpful
05:18 < belcher> for example addresses can also be linked together if you use bip37 or electrum servers, that isnt taken into account by the boltzmann calculation
05:19 < belcher> i suppose it has to be made clear the metric is for an adversary who only passively analyses the blockchain
05:20 < undeath> the github repo he referenced actually mentions a few other things in their writeup for more accurate ratings, but those are not part of the pr
05:20 < undeath> like, closure leaks and stuff like that
05:23 < belcher> its definitely a hard topic with lots of different aspects
05:25 < waxwing> belcher, remember that chat we had on tuesday, about different interpretations. that's essentially the same line of argument as boltzmann, it just now occurs to me.
05:25 < belcher> yep, though a very brief skim seems to show that boltzman doesnt consider that the coinjoin peers pay each other?
05:26 < belcher> theres also the aspect that single coinjoin transactions dont happen in isolation, so theres that attack where a taker user creates a single coinjoin but the linkage is revealed because all other coinjoin outputs get used in later coinjoin transactions because they belonged to yieldgenerators
05:26 < waxwing> i'll def read it again; only briefly read through it some month or two back (and i know it was created ages ago!)
05:26 < waxwing> well that's not really an 'attack' right, we considered it from the beginning, note hamish mcewan recently opened an Issue because he noticed that.
05:27 < belcher> i guess its an attack in the same way that double spending is an attack on bitcoin
05:28 < waxwing> well i mean that it's not suggested to use a single coinjoin to gain meaningful privacy.
05:28 < belcher> yes     
05:29 < waxwing> right, so it's not an attack on JM per se?
05:30 < belcher> yes     
05:30 < belcher> its not taken into account in the boltzmann calculation is my point
05:30 < belcher> thats nothing against that calculation, just theres the point that its hard to express privacy as a single metric because theres so many different aspects
05:31 < waxwing> hmm; if it's just trying to enumerate possible interpretations, then i strongly agree it needs to take account of CJ peers paying each other. well, anyway, i will definitely look at it again later. i do like the idea of a self-contained mathematical measure that looks only at payment interpretations.
05:32 < undeath> the actual boltzmann rating might actually be useful, but the pr only calculates a tx's entropy, which is not extremely helpful
05:32 < waxwing> not yet sure if it really is possible to do that unambiguously, if it is, that's cool in itself, even if it definitely doesn't capture everything.
05:32 < waxwing> undeath, right, i seem to be taking the opposite position to you. i like the idea of having the entropy in isolation from any more complex metadata-including measure.
05:33 < belcher> and then how do you rate different privacy breaks? if you have a 5-peer-coinjoin where everyone used a full node alongside a 10-peer-coinjoin where some used electrum servers
05:33 < belcher> if you go up to a 50-peer-coinjoin does it cancel out the electrum server usage?
05:33 < waxwing> right. so your position is it may be dangerous to have a misleading sense of security from a number.
05:33 < waxwing> i dunno. we *always* have that problem.
05:34 < belcher> IMO the best way is approach it from threat models, so you say your adversary can or cannot run spy electrum servers
05:34 < undeath> i think the entropy is just not much better than just knowing the mixdepth
05:34 < waxwing> undeath, hmm, i guess, in as much as it's JM and so has a fixed structure. it's still not *no* information, though.
05:35 < undeath> yes, the mixdepth ignores the number of participants
05:35 < waxwing> individual txs vary even beyond that.
05:35 < waxwing> sometimes more than one maker contributes the exact same input value.
05:36 < waxwing> not particularly uncommon, either, for reasons that are obvious.
05:36 < belcher> yes     
05:36 < waxwing> (and the change variation, in particular sweeps/non sweeps but i guess that's obvious)
05:37 < belcher> we seem to be in a situation where we're pretty sure we have privacy but we're not sure how to measure it and see how much privacy
06:47 < waxwing> re: threat models, agreed. i think we should focus on the least ambitious goal: the adversary with the blockchain and only the blockchain. other stuff is of course partially in scope of Joinmarket, but only partially: there are too many things that we can't defend against and/or quantify.
06:56 < belcher> surely you'd want there to be a full node interface for joinmarket, even thought its not a blockchain-based privacy feature
07:02 < waxwing> i don't follow the connection between that and what i said.
07:03 < belcher> i think you said we should focus on an adversary who only analyses the blockchain and not for example any electrum servers or the p2p network
07:04 < waxwing> it's not that i'm advocating err ... not advocating using a full node; if anything it's the opposite, i'm advocating for not considering non-full node usage as part of the threat model.
07:05 < waxwing> and similar privacy failures on user part. e.g. querying their addresses at bc.i. handing over their ID to a merchant or something. using a free VPN which collects their data. etc. etc.
07:06 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Remote host closed the connection]     
07:07 < belcher> 1) theres no 'the' threat model, everyone has their own depending on their circumstances 2) full node usage should certainly be part of people's threat models because its quite cheap to create lots of electrum servers, nodes that collect bip37 filters and that kind of thing
07:09 < waxwing> well but if we define Joinmarket usage as using a full node (which is accurate today) then it's not part of the threat model is it?
07:10 < waxwing> although that line of thinking doesn't really work generally i guess. not sure.
07:10  * waxwing takes a look at #uasf on slack ... "several people are typing .." ... closes tab.
07:12 < belcher> it is part of that threat model, but we've beaten it because almost everyone uses full nodes
07:52 -!- trotski2000 [uid206086@gateway/web/irccloud.com/x-wfgkyshzykgtrepl] has joined #joinmarket     
09:30 < d3spwn> shouldt a watcher loop terminate after "Abandoning monitoring of un-broadcast tx"?
09:40 < d3spwn> strange the transaction was actually already confirmed but the watcher loop was still running
10:18 < waxwing> d3spwn, are you sure it's not another tx? they happen in parallel
10:19 < waxwing> oh but also there's a quasi-bug lurking where, iirc, 6 hours after you sometimes see that "Abandoning" message when it doesn't correctly apply. somebody opened an issue for it.
10:20 < waxwing> re: 6 hours i mean the confirm_timeout_minutes variable. by 'doesn't apply' i mean i think it can be shown even when a tx never reached the network. not 100% sure.
10:34 < d3spwn> oh right, it could have been from another tx. the watcher loop log doesnt say which tx its tracking
10:35 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
10:37 < waxwing> d3spwn, good point that'd be helpful eh.
10:37 < waxwing> oh no hang on, but doesn't it tag the address?
10:38 < d3spwn> it does when it starts, but i mean the line that says "[DEBUG]  rpc: listtransactions ['*', 100, 0, True]"
10:39 < waxwing> yes, hmm .. that line i'm unsure about. it's very log spammy for debug. maybe we can add a 'trace' debug level or something.
13:01 -!- trotski2000 [uid206086@gateway/web/irccloud.com/x-wfgkyshzykgtrepl] has quit [Quit: Connection closed for inactivity]     
15:40 -!- emzy_ [~quassel@raspberry.emzy.de] has joined #joinmarket     
15:42 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3]     
15:46 -!- Netsplit *.net <-> *.split quits: emzy, johnhmay
16:59 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-vrtdtuigbvrolcbh] has joined #joinmarket     
17:46 -!- AgoraRelay [~jmrelayfn@p5DE4AC3D.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
18:04 -!- AgoraRelay [~jmrelayfn@p5DE4ACA9.dip0.t-ipconnect.de] has joined #joinmarket     
19:11 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #joinmarket     
19:37 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Remote host closed the connection]     
19:37 -!- StopAndDecrypt [~StopAndDe@pool-141-155-179-159.nycmny.fios.verizon.net] has joined #joinmarket     
19:37 -!- StopAndDecrypt [~StopAndDe@pool-141-155-179-159.nycmny.fios.verizon.net] has quit [Changing host]     
19:37 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #joinmarket     
23:21 -!- emzy_ [~quassel@raspberry.emzy.de] has quit [Changing host]     
23:21 -!- emzy_ [~quassel@unaffiliated/emzy] has joined #joinmarket     
23:21 -!- emzy_ is now known as Emzy