12:46:49 Hey everyone, I'm a journalist at Cointelegraph, I was looking to ask a few questions about Tryptych if anyone's available. 12:55:33 Shvandrew: sarang/surae are in US timezone so it’s still early there. 12:56:14 Best to wait in this channel. 12:57:48 Yeah make sense, thanks selsta 12:58:09 Or you can write them an email. 13:03:38 I was never able to find one for MRL members, only core. 13:05:04 I'm sure there's an encryption joke in there somewhere... 13:05:30 Hi, I'm one of the authors of the paper 13:05:43 (our emails are listed on it, FWIW) 13:06:35 sarang: would you be ok with putting your emails on getmonero as it is for core? 13:07:02 I thought they were listed 13:07:16 they are not. Only reddit and github 13:07:22 Hmm I see 13:07:57 Shvandrew: how may I help you 13:08:27 i think could be useful in these kind of situaations. Maybe a general "research lab" address instead of multiple single addresses? 13:09:03 or whatever you guys prefer 13:11:50 I could have sworn our getmonero dot org emails were listed... oh well 13:12:14 I prefer protonmail dot com anyway, since it plays more nicely with encryption (something something PGP is bad) 13:13:24 sarang thanks, we actually spoke before for the 0x OpenZKP stuff, you've been a great help. Anyway, for Triptych I was curious about the more practical matters since we do have a fairly lay audience. Specifically: How realistic is it to see Triptych implemented live, and in how long? You've mentioned you're working on even better stuff, does that 13:13:24 involve logarithmic verification or it's minor upgrades? 13:14:51 I can't reasonably speculate on the likelihood of projects implemented Triptych, since it's still early work that has not undergone any formal review (preprints do not need any kind of review before being submitted to preprint archives) 13:15:57 The other version of Triptych that we're working on would allow for signing with multiple keys in the same proof, while also directly including a balance test, leading to even smaller overall transactions 13:16:13 However, verification is still linear (up to multiscalar multiplication optimizations and batching, which help this) 13:16:46 That version of Triptych is not quite ready yet due to some technical questions that aren't answered yet 13:19:17 Thanks. So as I understand the point of Triptych is to reduce size of ring signatures to be able to increase the anonymity set. You need to strike a balance between anonymity, verification speed and size here, right? 13:22:39 Yep, that's the idea. Triptych is one of several newer constructions with such a goal. 13:26:26 How important do you think this goal is? Would you say that the current ring size is at least partially inadequate in providing a good anonymity set? I'm especially curious for another article of mine on privacy coins in general. Basically I'm looking for a reply to fireice's claims that A. churning is ineffective and B. metadata leaks are a huge 13:26:26 issue. 13:27:28 That's a subtle question that depends highly on particular threat models, and doesn't have an easy answer 13:27:35 lol fireice 13:28:08 There's network-level metadata floating around, which may or may not affect a particular user depending on their threat model (and is tricky to reduce) 13:28:33 There's on-chain metadata floating around (including things like timing, input/output structure, non-standard transaction data, etc.) 13:29:16 Reducing exploitable metadata is important, but eliminating it entirely is impossible 13:30:18 I liked what surae mentioned in his konferenco speech, that different levels of anonymity/plausible deniability have different meanings depending on who the 'adversary' is 13:31:00 Yeah, it's very important to keep the threat model in mind; and this can vary 13:31:27 some adversaries will only act with high levels of certainty, while others aren't as concerned with making mistakes 13:31:34 The downside is that it's difficult to convey this subtlety 13:32:07 Some things, like fixing the ring size, are relatively easy ways to mitigate distinguishability 13:32:44 Other things, like trying for a completely uniform transaction structure or getting rid of network-level metadata, are extremely challenging (or likely not possible in their entirety) 13:34:06 That being said, being able to increase the size of the input anonymity set in a big way would be a great step in the right direction 13:34:26 Hence research by many people that's led to constructions like Lelantus, Omniring, RingCT 3.0, Triptych, et al. 13:34:48 Each of these comes equipped with different tradeoffs and security models 13:35:40 I'm sure this is an entirely unsatisfying answer, Shvandrew! 13:36:12 Isthmus likes to talk about anonymity puddles within the anonymity system. Different groups that use Monero have different distinguishing features, that is leads to metadata patterns. If someone can be identified as member of one group, it reduces plausible deniability and so on. 13:37:00 Yeah, it's the curse of default-but-not-mandatory aspects to transaction structure 13:37:10 The biggest puddle is everyone using the standard implementation, probably 13:38:08 sarang no worries it still works just fine for the article(s). Thanks a lot, should be enough for now. Do you prefer email or IRC for future contact? And can i quote you directly? 13:39:09 Either IRC or email are fine 13:39:10 sarang: ok, so protonmail it is. SuraeNoether could you let me know if it's fine for you as well? 13:39:53 ErCiccione[m]: there are {sarang,surae} at getmonero addresses too, but I happen to like protonmail for its security 13:40:02 I've been inconsistent about which email has gone onto preprints 13:40:21 Although actually one more thing, if you could elaborate on fireice's claims against churning that'd be great. Is it really so easy to trace transactions with his proposed attack? 13:40:35 ErCiccione[m]: I assume the address won't be directly included on the site without some kind of masking, to avoid spam scraping 13:40:49 which attack? 13:41:00 Sure, whatever you prefer is fine. I agree better to keep them consistent 13:41:28 https://medium.com/@crypto_ryo/on-chain-tracking-of-monero-and-other-cryptonotes-e0afc6752527 13:41:32 Like most aspects of using distributed digital assets, there are better and worse ways to use them; this includes churning 13:42:00 final nail, very dramatic! 13:42:08 We're presently working on a graph-theoretic and statistical formalization that tries to address this 13:42:18 sarang: core team have theirs unmasked, but we can change them all to something a bit more soam resistant 13:42:56 Similar to how to choosing decoy inputs poorly can lead to heuristics about what is more likely to be the true signer, churning "badly" could lead to heuristics trying to identify the process 13:43:35 This also depends on what your threat model is, and what the hypothetical adversary is assumed to know 13:43:52 Interesting. What constitutes bad churning though? Like is there a wrong way to send transactions to oneself? 13:45:28 For example, transactions tend to follow certain statistical distributions on inputs that are selected (and this idea has appeared in research for a few years now), so churn transactions should ideally follow this as well to reduce distinguishability 13:46:47 If you were to presume that some hypothetical adversary has additional data on transaction information for whatever reason (ISP, remote node, etc.), then that could change the picture as well 13:48:04 If your transactions bring in additional inputs that could have been identified to you (from an exchange, perhaps), then that could be an additional piece of data 13:48:35 I am not saying that any particular piece of information renders a particular transaction or churn process "broken" or "optimal" here 13:49:18 The point of doing more formalized analysis and simulation is to take these ideas and use them to build models about what information such an adversary could reasonably gain, and how different types of churning help or hurt 13:49:29 It's research that is still very much ongoing 13:51:04 Well I guess it's always easier to deanonymize transactions if you have additional information. Thanks Sarang, now I'm fully satisfied :) 13:51:16 What does "deanonymize" mean in this context? 13:52:08 Even if you were to gain or possess enough information to identify the true signing input(s) of a transaction, this doesn't inherently link to wallet addresses 13:52:19 Once again, back to threat models 13:54:06 Someone who is concerned about an ISP colluding with an exchange probably has a much different threat model than someone just buying coffee 13:55:20 Designing for all possible threat models is exceptionally difficult 14:06:24 I would guess that the primary threat model one thinks about is against government investigations. That is bound to pose the biggest threat level. 14:10:12 It's the 'really big gang' threat, who can obtain the records of ISPs and exchanges passively, or interact with you directly in different ways. And also has the technical expertise or financial capability to investigate the blockchain. 14:21:23 What's the goal of the piece you're doing on privacy Shvandrew? 14:24:19 Im skeptical about this churn analysis.. isn't churn where you take all your outputs and turn them into one output? Not multiple new outputs? The 'ring' analysis only works if the change output is non-zero, so it actually makes a lot of sense for NON-churn transaction behavior. If you solve the metadata problem I don't see churn being problematic 14:24:19 if used properly. 14:25:00 Two outputs is the new minimum 14:25:13 right but one can have 0 amount 14:25:15 afaik 14:25:18 yep 14:25:27 0 amounts never get spent 14:25:34 but they appear in rings 14:25:51 and therefore have an ideally ambiguous "spend state" 14:27:02 sure, I'm saying they can't be used for a new branch in a ring analysis (ring in the sense fireice uses it, a ring between transactions) 14:27:15 One reason I like the idea of very large ring sizes is that the use of fixed contiguous output sets means you're more likely to use multiple outputs from a transaction even if they aren't the true signers 14:27:15 unrelated question: if you look in the mempool right now, someone issued 200+ transactions, 120 inputs each. Is it safe to assume they all come from the same wallet? 14:29:04 seems weird, someone owns 25000 outputs? 14:29:18 I think block size limit will increase today, look at recent block sizes 14:32:17 maybe a big miner? quick go see if there are 25000 unique coinbase inputs spread between them! 14:33:15 how to find coinbase inputs? 14:33:22 @sarang it's a general overview of privacy coins. Specifically I highlight that coinjoin has been already compromised and that stuff like monero and zcash have various compromises on performance or anonymity that make it difficult to say which one is best 14:34:12 I'm curious if you can say (or if we must wait for the article)... what tradeoffs do you see with Zcash? Do you mean that shielded operations are optional? 14:34:14 can probably find them from the offsets, using rct_offsets 14:35:27 I thought that the earlier research on using amount data to track "temporary shielding" was a fascinating example of how practical use of shielded operations could lead to data leakage 14:36:24 Centralization, large transactions, the conversion step between shielded and unshielded that can introduce vulnerabilities. 14:36:48 I think we're referencing the same research paper for that data leakage 14:37:01 The word originally done with Quesnelle? 14:37:04 *work 14:38:12 Not sure. The paper is from University College London 14:39:03 Hmm, do you have a link? There was early work by Jeff Quesnelle that examined transactions that put funds into the shielded pool and then removed them... a simple amount linking (accounting for fees) could give unique links for a very large fraction of them 14:39:24 I recall someone at UCL mentioned wanting to look into a more recent version of this, but I don't recall seeing results 14:40:12 Also, what parts of transactions are large, in the tradeoff sense you mean? 14:40:45 Sapling proofs are very small, but of course Zcash transactions are not just composed of a Sapling proof 14:41:20 Well shielded transactions are physically just as large as Monero's. Lighter than before but still way bigger than BTC's 14:41:31 https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-kappos.pdf 14:43:19 Ah, Heuristic 5 in that paper seems to capture the idea of what Quesnelle did 14:44:36 I wonder what data they're using to get the claim I found about a shielded txn being 2 kB 14:44:48 That would depend on the transaction structure 14:44:56 But that's very interesting to see 14:47:26 interesting, it looks like these transactions are spending pre-ringct outputs (amounts are in cleartext) 14:51:35 apparently max tx size is 100kB, which implies max weight clawback factor is 1.5; does that sound right? 16:11:35 Shvandrew: did you have any other questions, or things to be clarified? 16:13:00 For now no, I'm just keeping the page open for some reason. Article will be published soon 16:13:13 Glad to help 16:14:33 sarang: i'm having a numerical problem with matching and i want to pick your brain 16:14:43 Sure 16:15:04 okay, so originally I was weighting edges of this graph with log likelihood, running from -infty to 0 16:15:23 but the algorithm i use to find maximal matching has to assume all edges exist and the ones that we don't care about have weight 0 16:16:00 so i switched, with 2 weeks of effort, from weighting using sums to weighting using products, and assuming edges that don't exist really are edges with weight zero 16:16:06 or a week i guess 16:16:30 Does this mean the graph is complete? 16:16:51 implicitly; i don't track all edges, but i assume any pair of nodes can count as an edge, and if i'm not yet tracking it, then it has weight 0 16:17:08 Doesn't that blow up immediately? 16:17:23 what do you mean? 16:17:40 do you mean time until matching is complete? 16:17:45 Oh, you're not tracking the zero edges as part of the graph structure 16:17:48 right 16:17:52 otherwise it would be huge yes 16:17:55 No, I meant complete graph in the sense of edges 16:17:57 ya 16:18:00 but likelihood is a number between 0 and 1, and is formed by the products of such numbers, and i'm getting likelihoods smaller than 10^-9 for most edges, and it's getting to the point where i'm concerned about numerical stability in computing these likelihoods. 16:18:32 now that i've talked it out i know what i need to do. :P 16:18:48 https://en.wikipedia.org/wiki/Rubber_duck_debugging 16:18:51 so... sarang, thanks for rubby ducking me 16:18:55 yass 16:19:02 we rub ducks here at mrl 16:19:49 o_0 16:26:37 Reminder: research meeting is today at 18:00 UTC (90 minutes from now) 16:27:52 Article seems to be out: https://cointelegraph.com/news/moneros-triptych-research-could-vastly-improve-its-anonymity 16:28:10 One mistake is that there are 10 per-input decoys, not 24 16:28:28 And users cannot alter this value 16:30:04 I would also not call it a "major innovation" 16:30:15 There have been other logarithmically-scaling proposals that came before 16:30:39 And other solutions have comparable performance 16:32:30 And heck, I'm happy to talk about the technical questions surrounding the other variant of Triptych: it has to do with an equivalence between proof relations 16:33:22 Triptych: just another logarithmically-scaling proposal to add to the list 16:33:27 ;-) 16:33:39 Hmm, the 100 ms estimate quoted in the article is for Omniring, but with a 2-in-16-out transaction, which isn't really a fair comparison to the info that I gave in the reddit comment 16:34:33 If anyone knows how to contact the author, it'd be nice to clarify these errors 16:38:40 I think it's important to put all this different research into the right context and give credit where it's due 16:39:40 I do, however, still consider Triptych to be a badass name 16:51:25 If the author is on twitter, can someone see if he can get in touch for clarification? I don't see an email listed on the cointelegraph site 16:52:27 (I am not on twitter) 17:08:03 sarang I can try to shoot him a PM, provided it is actually him https://twitter.com/shvandrew 17:08:18 Cool 17:08:51 The parameter errors are fairly minor, but I think it's important to give accurate credit to the other constructions he mentions in the article 17:09:07 But "major innovation" is subjective so I wouldn't bother trying to correct him, that's what journalists need to throw out there. Can correct the factual stuff you mentioned though :) 17:09:31 I mean as long as he is not misquoting anyone 17:09:43 Plus the estimates that I gave are very rough and not based on full implementation 17:11:03 He's not misquoting, but I think misinterpreted some data 17:11:25 It makes Triptych look great, but isn't really fair to other work 17:12:26 this is cointelegraph not IEEE-telegraph 17:12:52 not surprising... Hopefully he can correct the most glaring mistakes or misrepresentations 17:14:40 I want to be technically correct, the best kind of correct 17:14:43 =p 17:25:47 sarang: what's a better estimate? 17:26:24 triptych is great. will bring us ringsize 1 bajillion 17:26:47 ah, probably 67 17:28:08 For Omniring (which doesn't support batching), a better number is to use the 2-2 N=128 value of 67.2 ms 17:28:12 And RCT3 17:28:40 Which is 44 ms, basically the same as Triptych for N=512 17:29:11 Sarang, from author: "Still, on average confirmation times are higher for other solutions, right?" 17:29:19 The benefit there is size, if you use the non-aggregated (and therefore not input-padded) RCT3 17:29:37 Does he mean verification time, which is not the same as confirmation (as it's usually used)? 17:30:05 RingCT 3.0 has very comparable verification performance for ring sizes of interest 17:30:54 Since those numbers are from a single machine's operation-count test data, the estimates should be considered very rough; drawing precise comparison conclusions from them isn't a good idea 17:31:11 At best it shows they're comparable in expensive group operations 17:31:28 (also note these are only for 2-2 transactions, the most common type) 17:34:34 In case this background is useful, RCT3 is based on the underlying Bulletproofs proving system (with modifications), while Triptych is based on a Groth/Bootle proving system (with modifications)... so while performance is similar, the math is quite different 17:34:40 I find that fact fascinating 17:35:26 I'm also going to update the preprint to make the size and time comparisons more clear, in case that could lead to any confusion 17:35:47 That being said, I appreciate that the article highlighted the research being done in this area :) 17:36:42 Thanks for reaching out binaryFate 17:39:10 np. He said he will fixed it (not sure what/how) as soon as he can. 17:39:17 *fix 17:39:23 Cool, thanks 17:39:38 He is welcome to stop by this channel or email me with any questions on the data 17:39:48 sarang dot noether at protonmail dot com 17:43:52 Speaking of other constructions... suraeNoether if you're bored later, let me know; I'm trying to hunt down the effects of a possible Omniring math issue using some test code 17:44:22 Trying to avoid doing all the vector algebra by hand since it blows up really quickly 17:45:10 and I'd like to make sure I can reliably pinpoint the issue before asking the authors 18:00:15 Looks like it's time to get started 18:00:18 pinging suraeNoether 18:01:19 GREETINGS to everyone 18:01:46 Hi. 18:02:02 hi hi 18:02:23 * Isthmus waves 18:02:40 Let's start with ROUNDTABLE 18:03:02 The preprint for Triptych, a new linkable ring signature construction that can be extended for use in transactions, is on the IACR archive 18:03:12 Link: https://eprint.iacr.org/2020/018 18:03:37 CoinTelegraph just released an article about it (but note there are some errors in the data presented there, that I'm told will be fixed) 18:04:12 I plan to make an update on the size and time data, to properly account for batch verification and ensure fair comparison 18:04:54 More work was done on the multi-index version of Triptych, fixing soundness in exchange for a separate proof relation that we need to show is equivalent to another proof relation 18:05:00 This would allow even better performance 18:05:23 I worked out an MPC for that version of Triptych as well, which would be useful for multisig 18:06:12 And I'm presently working on some questions relating to Omniring math that I've brought up with that paper's authors 18:07:08 Does anyone else wish to share interesting research work? 18:07:12 When the time is right, at a key juncture, we could have a press release on Triptych. Monero Outreach could support that. Maybe when it is established that it is going into a release. 18:07:39 To be clear, there are no guarantees that Triptych, or any presently-known construction, is fit for deployment 18:07:45 Right. 18:07:53 I've got some fingerprinting stuff, and n3ptune just completed a pretty cool network analysis 18:07:57 Ooh 18:08:31 Isthmus: what sort of data have you uncovered? 18:09:30 Ah my fingerprinting notes are nothing new or exciting, just an idea that might make data presentation more intuitive. So, I tend to think about wallet fingerprinting in a kind of abstract way - every transaction sits at some corner of a hypercube in a high-dimensional space made of different heuristics yadda yaddaaa yadda 18:09:45 So even though I work with sets of boolean features on the backend, wanted a good way to show results 18:09:56 This is my first attempt: https://mitchellpkt.github.io/fingerprint.html 18:10:03 What, you can't accurately present visualizations of high-dimensional hypercubes? =p 18:10:23 llol 18:10:33 This is somewhat by @suraeNoether adding human-interpretable output to the graph matching 18:10:39 I like the idea of enumeration like that 18:11:52 thanks! It figure it's also an easy way to pass around data in a 2-column CSV chart, and researchers can do substring matching on portions that they find relevant to a given analysis 18:12:14 Ack sorry! I'm here! Time change got me unawares 18:13:12 Isthmus: is there anything to share about the network analysis you mentioned? 18:13:40 Re: questions on block propagation timing asked last month, I've collected and analyzed block receipt timing data from our global nodes recorded during the past 6 months 18:13:58 Nice! 18:14:04 What conclusions? 18:14:16 Isthmus has notes about interpretation and I have more to write but you can look at the graphs here https://github.com/noncesense-research-lab/archival_network/wiki/Block-propogation-time 18:14:22 This was RE a question that @moneromooo asked, right? 18:14:52 Units are size in bytes and timestamps in milliseconds, right? 18:15:00 that was my question ^ 18:15:04 we used this formula where NRT is Node Received Timestamp: prop_time_lower_bound(h) = MAX[NRT(h,1), NRT(h,2), NRT(h,3)] - MIN[NRT(h,1), NRT(h,2), NRT(h,3)] 18:15:28 What are the changing indices there? 18:15:38 Different nodes? 18:15:49 hello 18:15:50 yeah, that goes up to 3 but there are 4 nodes total 18:16:01 got it 18:16:03 so block prop time is reliably at least 0.1s. interesting. 18:16:23 Oh scatter heatmap is height from dark=old to light=new 18:17:20 ^ color scale 18:18:42 And those are the differences between the miner-reported timestamp and the node's wall clock upon receipt? 18:19:16 Miner reported timestamps are not considered anywhere in this study 18:19:22 But we did that elsewhere 18:19:25 * Isthmus digs around github 18:19:51 hm then what is being measured for prop time? 18:19:59 So these are blocks only passed between your nodes? 18:20:10 Where you look at local times on send and receipt? 18:20:27 ^ Was going to ask that, as the min propogation time seems particularly low, as 100msec is quite low in our experience to cross the globe. 18:20:31 Or better question: how is NRT computed 18:20:36 it's the difference in timing between different nodes receiving the same blocks 18:20:47 Ah, ok 18:20:49 Yea, not passing between our nodes, but passing through our nodes 18:20:50 NRT is recorded from the node system time when a block arrives 18:20:55 Independent of the peer from which they receive 18:21:01 (which would differ) 18:21:59 Seeing the difference between miner-reported time (which could be inaccurate) and wall-clock receipt time would also be interesting 18:22:08 hmmmm 18:22:21 o/ 18:22:25 https://usercontent.irccloud-cdn.com/file/brPsQyeU/image.png 18:22:28 @sarang just for you 18:22:43 So what we're really seeing here is not propagation time directly, but variability in one layer of propagation time 18:22:51 here = the initial plots, not this one 18:23:08 I'll have to check pool log data, as I might be able to give some extra data points if you're interested. We started to log the time in which a pool node finds a block, versus when that block is stored into our database, which means it's been processed by the local node, as we skip all monerod timings on the pool itself. 18:23:19 oooop 18:23:21 that's cool 18:23:32 Very high times 18:23:36 @Snipa very nice! 18:23:47 "So what we're really seeing here is not propagation time directly, but variability in one layer of propagation time" < can you elaborate? 18:24:19 isthmus well it's how long it takes for the block to propagate from one of your nodes to another of your nodes; not time it takes to propagate from a miner to one of your nodes 18:24:25 I mean that for the initial plots you showed, you can't directly interpret the time for the block to reach your node after it's mined 18:24:32 suraeNoether: no 18:24:41 no? 18:24:45 Yea, we very deliberately labeled all of the axes "prop time lower bound" for that reason 18:25:05 Also, we could always posit that there is an old PC on dialup somewhere in Nebraska with a 4 minute prop time, but that's not meaningful 18:25:10 suraeNoether: it's looking at the difference in receipt time, whichever path the block took in total propagation 18:25:27 Hrm, auctually, I can provide a data stream of our global block propgations, as every node has a local reporter that we can hook. 18:25:45 @Snipa yes please! 18:25:49 sarang that's true also 18:25:54 that data would be awesome to work with 18:25:57 I'll posit something that might be wrong: 18:26:06 It's a hacky data science way of thinking - 18:26:17 Hit me up a bit later and we can discuss how to get it to you, and go over data formats. 18:26:39 Shoot, I gotta get off the bus 18:26:43 isthmus: you have two sensors set up to detect propagation time. but you need 3 to triangulate, ala seismic detection of epicenters 18:26:45 * Isthmus sticks a pin in it, and will be back in 3 - 6 min 18:26:53 Don't leave us with that cliffhanger Isthmus! 18:26:58 i'm on the edge of my seat 18:27:01 i spilled my tea 18:27:13 i'm so upset at isthmus right now i could just light myself on fire 18:27:32 Stay on the bus Isthmus... it'll loop back around to your stop eventually 18:27:52 In the meantime, any other interesting tidbits on this work? 18:27:57 This is very interesting data 18:28:16 while we are waiting on Isthmus, I'll give my super-brief update: after some discussions with endo, my matching code has been made significantly more efficient, easy to understand, and easier to debug; i'll be making a push later today. my two categories of work today are re-reviewing CLSAG and working on matching 18:28:40 that's it for now, we will update 18:28:45 his pseudocode now fits onto one sheet of notepad paper.. 18:28:55 isthmus and i also technically had a conversation about writing up a proposal to encrypt and enforce all lock times, but we haven't gotten details worked out yet 18:29:32 You mean using DLSAG-style commitments? 18:29:40 We'd discussed it earlier in a meeting 18:29:54 yep, last meeting iirc. but i actually had a call with isthmus about it. i view this move as a very good boost in privacy in the sense that it covers up a source of non-randomness in the large data sets that isthmus likes to comb through. 18:30:12 I can work out the size and time implications on that if you like 18:30:20 i'm not convinced it is worth the additional cost to our txn sizes, but we'll see how it shakes out 18:30:24 Since it could be bundled into the existing bulletproof 18:30:26 ^ ah 18:30:37 Yeah, size is not the issue here due to the logarithmic scaling 18:30:55 yeah, and verification times are speedy as a cheetah's balls 18:31:16 pardon me, this is a public meeting, i should be less vulgar. please accept my apologies. 18:31:17 Right... there's a linear increase in verification time, but with the benefits of multiexp that's reduced a bit 18:31:27 CoinTelegraph has updated their article: https://cointelegraph.com/news/moneros-triptych-research-could-vastly-improve-its-anonymity 18:31:44 Thanks to the author for taking care of that so quickly 18:33:23 A press release could get more coverage, when and if it is desired. 18:33:32 suraeNoether: interestingly, due to bulletproof padding, for many transactions there would be no size increase aside from the space taken up by the commitment data 18:33:34 good on cointelegraph 18:33:40 (as opposed to a smaller plaintext representation) 18:34:00 sarang: could a similar approach be used to include a ciphertext of a message? 18:34:35 ie moneroMail 18:34:43 Sorry somebody got in a fight with the bus driver right before my stop 18:34:47 Not really... there's some spare space in bulletproofs that could hold something 1-2 proof elements of arbitrary data by controlling randomness (I'd need to check the details) 18:34:48 Sigh San Francisco 18:35:02 Welcome back Isthmus 18:35:02 Ok lemme whiteboard some stuff 1 sex 18:35:14 n3ptune: do you want to share the padding? 18:35:19 In the blocks 18:35:52 sure 18:35:54 sarang so enough for a key exchange but unlikely enough for a ciphertext? 18:36:19 Well, you're limited by space 18:36:37 Is there a known purpose for the null padding tag in tx_extra? 18:36:45 I don't remember if Poelstra and friends found 32 or 64 bytes of space 18:36:59 n3ptune: good question for moneromooo et al. 18:39:38 While we await Isthmus' continued update, anything else of interest to share? 18:39:49 Or ACTION ITEMS, according to the agenda? 18:40:36 i want to provide final comments to you on clsag but i'm very unlikely to get that finished today 18:40:42 but it's on my mind for this week 18:40:51 Back 18:40:58 Front 18:41:17 Mine are to get CLSAG submitted (after review), to hopefully nail down this Omniring issue and pass it to the authors, work on a few EC curve library updates for proof of concept code, and get preprint stuff taken care of via monero-site MR 18:41:26 Isthmus: please go ahead 18:42:36 (oh, and update the Triptych preprint performance data with better clarity) 18:42:37 https://usercontent.irccloud-cdn.com/file/gAM3VbDV/1578508953.JPG 18:43:00 wat dis 18:44:43 So let's say that we have 100 of n3ptune/NRL's archival nodes running 18:46:30 If we have only 2 nodes, then our propagation envelope will have a lot of variability, be topology dependent (assume archival nodes don't connect to each other), and just t_second - t_first 18:46:57 As we add a 3rd node, it has the possibility of increasing the measured prop time (since it could hear before or after) but can't decrease the prop time since it's max-min 18:48:27 As we get up to 100 nodes, the variability will probably smooth out and we approach the true reasonable prop time (from miner to global nodes with broadband internet) 18:48:32 Doesn't prop time depend on max/min among all nodes? So the third node could fall outside the envelope of the other two and affect the value? 18:48:41 Yeah, that's the point 18:49:05 OK, I must have misinterpreted 18:49:22 Oh, can't _decrease_ 18:49:24 Painting very broadly, when we adad the 3rd node there's a 2/3 chance that it'll fall outside the N=2 and increase the prop time, and a 1/3 chance that it'll be between the first 2 nodes. 18:49:25 nvm 18:49:51 Sorry, I'm giving a kind of scattered description cuz I just realized this on the bus 18:50:14 Max-Min is a very sensitive metric, sensitive to outliers. 18:51:27 Hmm lemme ponder on that 18:51:37 Skipping over that for now 18:51:54 How're you pulling the time in which the block is received? Tweaked monerod/using it's logs or polling on the RPC interface to determine when it's auctually viably added to the box? 18:52:29 That's a n3ptune question, they do all the DevOps and data engineering. All ended up in a SQL database by the time I got to it 18:52:39 tweaked monerod 18:52:49 On P2P receive then? 18:53:20 So for each height we have epsilon (green line) which our many-node approximation of global prop time 18:53:27 you can also use monerod --block-notify, if you point that to a shell script that writes the timestamp 18:54:11 --block-notify waits until the block is committed, which is why I ask, because nodes that do not use NVMe have much slower propagation times in general, as you're waiting on disks to write. 18:54:15 i like that better because then you can use the stock daemon. but we don't use that yet 18:54:20 OK, so using the max-min metric, assuming relatively even node placement across the network topology? 18:54:44 Yeah, though after @almutasim I'm considering a few other less sensitive metrics 18:54:52 slap all those epsilons into a histogram, and that's the plot on the right. 18:54:59 The outliers being nodes close to the miner and far from it, topologically 18:55:17 Uhm, the outlier might be only 2 hops away but one of the hops is really slow 18:55:21 P2P Receive: no it happens when it adds it to the blockchain, after it determines whether or not it's an alt block. this was because we had another original goal to capture alt blocks data. the daemon patch is shared here https://github.com/neptuneresearch/monerod-archive 18:55:58 @sarang so it depends if topological distance definition is just the p2p connectivity graph or takes into account time between vertices 18:56:32 right 18:57:22 And that epsilon plot is basically what n3ptune shared earlier except instead of "max-min with 4 nodes" it is "asymptotic approximation of global prop time" 18:57:34 ^talking about x-axis of histogram 18:57:47 --block-notify waits until the block is committed >> oh then i guess this method of doing it in blockchain::add_new_block() at least occurs before block-notify would. but yes it isn't *immediately* on receive 18:59:37 Since we're just about out of time, any last bits of information before adjourning (discussion can of course continue) for log purposes? 18:59:58 Oh yea 19:00:20 just a quick note that tx_padding is used in the wild, but unclear why 19:00:42 In the scatter plot showed earlier, the vertical bands from left to right are empty blocks and then N=1,2,3... transaactions 19:00:57 That's a question for someone like moneromooo 19:01:12 Of course there's variability in the horizontal width of the vertical bands due to transaction size differences, but the variability in coinbase-only blocks was straange 19:01:13 https://xmrchain.net/tx/acdf8eac41a7a76fd899e09640db34023abff66b3ae2c9ea86e49f19c0720af4 19:01:30 Not really, coinbase only blocks are quite common due to pool design. 19:01:45 No no, the size*variability* in coinbase-only was strange 19:01:52 Turns out some (now fingerprinted) miners are using lots of null padding, check out the tx_extra for this coinbase 19:01:59 gadzooks 19:02:13 Not super surprising. 19:02:28 Looks like bloat to me 19:02:36 Bunch of blocks waste space with nulls in tx_extra 19:02:41 Possibly, it's also something that can be requested by a pool. 19:02:51 As that's the block padding that we use for extra nonce storage space. 19:03:23 "As that's the block padding that we use for extra nonce storage space." block nonce or transaction nonce? This is padding in the coinbase transaction 19:03:35 Oh sorry, txn, my bad. 19:04:17 Do you know why some miners use the padding and some don't? 19:04:31 * Isthmus is very naive about practical mining stuff 19:04:45 Lemme look through some of my decoding code I wrote for that. 19:05:21 I'd been comparing: 19:05:24 https://xmrchain.net/search?value=1988283 19:05:25 and 19:05:30 https://xmrchain.net/search?value=1985042 19:05:39 Since they seem to be exactly the same besides different padding 19:05:46 * Isthmus wraps up that train of thought 19:06:48 Anyways, thanks for letting me ramble and shifting meeting time 19:07:22 For quick reference: The block's CB TXN contains an "extras" section, which is requested from Monerod as the extra space in which arbitary data can be written. This data is used by pool implementations to implement the per-pool nonces as well as any custom nonce data used by more advanced techniques. 19:08:16 "extra space in which arbitrary data can be written" 19:08:17 * Isthmus cringes 19:08:44 You can use this data in a number of ways, particularly with knowledge of pool design, as the two main pool implementations use this space similarly, but have different sizes based on various addon support. 19:09:00 Ooh, what are the current use cases? 19:09:16 You also can identify what pool instances are submitting blocks, as pools use unique identifiers in particular bytes. 19:09:17 (I have no knowledge of pool design) 19:09:39 https://github.com/Snipa22/nodejs-pool/blob/master/lib/coins/xmr.js#L115 19:09:43 For those of you who are interested in helping out with Monero Kon 2020 in Berlin, there is a meeting happening right now for prospective volunteers. This is research related, but otherwise off-topic, so I'm just dropping this here. 19:10:07 ^ is the implementation you'll find on pools that support the XNP extensions I wrote awhile ago. 19:10:24 Yeah, we can formally adjourn the meeting, but carry on the conversation 19:10:27 Thanks to everyone for attending 19:11:51 And yes, we're bad on the pool development side and write stuff directly into the blobed out buffers at fixed offsets. My new code is slightly better about auctually implementing the parsing that Monerod does internally for safety. 19:12:44 In particular, the minerNonce is the pool's internal counter for the miner. The instanceID is used as a unique data point for the pool thread. 19:14:15 Ooh very interesting 19:15:01 suraeNoether: don't know if you already answered and i missed it. Would you be ok with putting yur email address on getmonero like it is for core team members? 19:15:26 The current NodeJS implementations use one thread per CPU core, so it's not an ideal map of block <-> server, but can identify common threads. 19:15:37 Oh yea, the "implications" portion of this article mentions why I care about block fingerprintability: https://hackernoon.com/utter-noncesense-a-statistical-study-of-nonce-value-distribution-on-the-monero-blockchain-f13f673a0a0d 19:16:03 @Snipa cool, I'm taking notes on all of this 19:16:44 If we can figure out how to get you data from our feed, I can provide block find information w/ the pool region it came from, so that might be useful too. 19:17:12 @ErCiccione[m] if you're making updates, could you add my email too? Isthmus⊙go 19:17:24 ErCiccione[m]: yeah, although put both surae⊙go and surae.noether⊙pc 19:17:37 At least, for our blocks. 19:18:15 ErCiccione[m]: as mentioned before, please mask to avoid obvious spam scraping 19:18:23 will do isthmus suraeNoether 19:18:44 sarang: yes, no problem :) 19:18:50 thanks 19:22:44 @Snipa are you usually around on IRC? I have to scoot soon, but we'd love to chat more. 19:22:49 @almutasim still pondering your comment, and I agree with your observation that (max-min) is probably more sensitive than we want. 19:22:53 What do you think about (t_95% - t_first), in other words, how long it takes for 95% of nodes to hear the block. 19:22:58 (this is probably close to what we mean when talking about meaningful "global propagation time") 19:23:13 I'm around most of the time (GMT-8) during the workday/evenings. 19:23:33 If you've got specific pool/mining related stuff, I'm always glad to help. 19:23:53 :- ) 19:24:20 And actually, using dt95% allows us to formulate the question slightly differently: 19:25:42 How many nodes do we need so that the dt95% measured by our archival network adequately approximates dt95% for the whole network (including unobserved) 19:41:33 No known purpose for padding. 19:43:54 ^ Isthmus 19:44:52 net.psp.msg:INFO will give timestamps of message received in the p2p layer. 19:46:15 Why are coinbase only blocks quite common due to pool design ? 19:47:42 Sxmr is somewhat bad about it in particular, though we do it mostly to avoid monerod. The functional implementation that we utilize doesn't rely on Monerod block propogation, as it's a little too slow. 19:49:20 The functional implementation takes advantage of a secondary overlay network that talks directly to pools from the daemon that submits the BT to the network, as it confirms first, and broadcasts the BT out through a dedicated sub-network. If that node has no txns at that point in time, then the pools will not receive any txns as part of that broadcast. Mix that with the pool's default handling of "Once I get a BT for a new height, don't 19:49:20 accept another BT and reset miner work." 19:50:19 Sxmr is the name of some pool software ? 19:50:26 SupportXMR, which uses my software. 19:50:57 The other main implementation does similar block-template blocking work, to avoid messing with miners. 21:00:39 suraeNoether: I've updated Triptych (iacr.tex) on Overleaf to include batching and fix some typos; notably, I made a slight error in size computations as well, based on how I was trying to compare Triptych with the modified version of old-RCT3 21:01:22 The size computations apply only to the signature/proof portions, not complete transactions (which depend on implementation, as I discuss in my markdown writeups on the sublinear branch) 21:07:41 Please review suraeNoether 21:08:32 Proposed changes are in this commit if that helps: https://github.com/SarangNoether/skunkworks/commit/946dd65738eeae63fc1192291cd72ac95560e185 21:08:47 I'll hold off on revising on IACR until I get your thumbs-up 22:59:43 Did anyone look into thos pre-ringct giant sweep transactions that were mentioned earlier? Does anyone have a link to them in a block explorer? 23:03:12 gingeropolous pasted a link before 23:03:31 here's 1 I think https://xmrchain.net/tx/1ff38f1fb4f6556f4d5953c33bafca56e5de2fd1e44c3b77974a2305fec3f366 23:06:10 suraeNoether: it would also be helpful if you can first give a quick review of the title/abstract change on CLSAG, so I can update the monero-site language file strings 23:06:24 even before reviewing the paper itself 23:22:34 Thanks hyc, veru strange indeed 23:26:00 I assumed it would be a larger amount in the clear from that long ago 23:37:27 looks like mostly dust