12:19:49 sarang: in MRL-0010, there is G, G' \in G (same for H), and the proof is for xG' and xH'. In my understanding G and G' can be chosen arbitrarily, so e.g. G' can be the 'default' generator for secp256k1 and G another chosen generator for the Pedersen. 12:19:58 is my understanding correct? 12:20:50 I ask because of: Suppose |G| = p and |H| = q 12:30:45 Updated my whitepaper about revokable branched outputs to include more details on how the protocol would work: https://github.com/philogy/revokable-branched-outputs/blob/master/revokable%20branched%20outputs.pdf would love to hear your feedback once again especially if I overlooked some crucial details like in the first draft 13:13:31 h4sh3d[m]: the generators are arbitrary, but should have no known discrete log relationship 13:14:02 ok thanks, sure 13:15:13 public string hash-to-point for one of them in each group would be a standard way to do this 14:48:46 UkoeHB_: you may be interested to know I have some early data on output merging 14:48:56 There's a lot to study about it, so it's quite preliminary 15:32:35 cool, do you have public code? 15:33:16 Yes, but you'd have to run it for a while against an explorer API (doing this non-locally would take a prohibitive amount of time) 15:39:48 Hmm, although I found a strange indexing result that makes me suspicious and want to check a few things again before pushing my commits 15:40:24 The gist is that 2-3% of post-CT transactions (confidential only, not those spending pre-CT funds) contain at least one zero-hop merge 15:40:58 and that the vast majority of these merges have a small height difference (plots during meeting) 15:41:50 But there's a consistent tail on this distribution, albeit at very low rates 15:42:35 What I'm going to do is run simulations using the same input/output structure against the current output selection algorithm, and check the distributions to see where the distributions really start to diverge 15:46:27 UkoeHB_: once I've confirmed this indexing is going the right thing, I can post the resulting merge data (which is a reasonable enough size for GitHub) so folks can run analysis on it too 15:54:52 ah today is Wed isnt it 15:56:30 Indeed! Meeting in one hour; was just about to post a reminder here :D 15:57:38 I suppose organic merges would have to be at small heights, since that's where the selection algorithm is picking most ring members from; 2-3% seems significant though 16:03:15 The real question will be the extent to which that's consistent with expectations from the selection algorithm 16:03:41 The whole idea of merging leaking likely spends will depend in part on how often users receive multiple outputs from a single transaction 16:04:11 if it's inorganic, it may be from people naively churning by sending to themselves with explicit amounts 16:04:15 I'm still doing some reclassification based on selection algo to differentiate 16:45:18 Meeting begins here at 17:00 UTC (about 15 minutes from now) 16:58:57 OK, just about time to start the meeting 16:59:16 First, greetings! 16:59:41 Hi 17:00:22 hello 17:01:13 Heya 17:01:20 I suppose we can move to the roundtable, where anyone is welcome to share research of interest 17:01:29 Does anyone want to go first? 17:02:10 If not, I can share a few things 17:02:36 Teserakt has sent me a draft of their analysis of the CLSAG preprint 17:02:36 Test failed 17:02:43 bad bot 17:03:22 The draft report indicates they did not find any major issues with the construction, but they had some comments and suggestions on the formalization that I'm working to update 17:03:30 This shouldn't result in any changes to the code 17:04:11 Separately from this, I started working on some output merging analysis on the Monero chain 17:04:16 Hello 17:04:29 I have preliminary data but am still checking it for a few questions I have 17:05:02 I'll post a plot here, but note that it should not be relied on until checked more thoroughly 17:05:18 https://usercontent.irccloud-cdn.com/file/EHmFolZV/data_all.png 17:05:27 An explanation... 17:06:00 I look for "zero-hop" possible merges, where outputs from the same source transaction appear in separate rings in a later destination transaction, and filter only by post-CT confidential transactions 17:06:24 Then, for each such possible merge, I look at the height difference of the source and destination transaction, and plot them here 17:06:48 The x-axis represents block height difference, and the y-axis is fractional occurrence (note the log scale!) 17:07:06 Hi. What you think about interoperability on Monero? 17:08:01 kiwi_87: one sec 17:08:09 👀 17:08:13 Very interesting 17:08:18 https://usercontent.irccloud-cdn.com/file/UPSZyk6P/data_1k.png 17:08:41 Here is the same data, but zoomed (and rescaled) to the low end of the x-axis 17:09:11 Now, these are only possible merges; there's no good ground-truth data set on chain for post-CT confidential transactions 17:09:16 hi 17:09:30 So I'm going to run a simulation using the same input/output structure and the current decoy selection algorithm 17:09:36 and see if/where the distributions diverge 17:09:57 kiwi_87: what do you mean by interoperability 17:10:24 Oh, and for this data... about 2.3% of post-CT confidential transactions contained at least one possible merge 17:10:38 (this data shows all such possible merges, not just a unique one from each transaction) 17:11:42 @sarang if you want to go deep into the Bayesian weeds, could calculate the probability (always positive, but varying in magnitude) that a pair(+) of these ring members would be selected together if sampled from the standard algo 17:11:43 Isthmus: do you recall what proportion of transactions don't use the standard gamma distribution (approximately)? 17:12:06 UkoeHB_: note that this is _all_ post-CT confidential transactions, regardless of likely selection method 17:12:25 I did a filter for that but may have a minor indexing issue that threw off the data 17:12:48 Isthmus: yeah, I thought about that too (but didn't run the analysis) 17:13:22 The distribution difference is intended to give a very rough idea of how non-ideal this distribution is 17:13:40 The other question is ring size 17:13:43 @UkoeHB_ as of Konferenco (last June) about 1% of transactions used obviously uniform selection algorithm 17:14:12 I haven't updated the analysis pipeline, so can't speak to recent months. 17:14:21 ah if sarang is already filtering those out it's not a big deal 17:14:30 I'm not at the moment 17:14:37 This is all post-CT confidential transactions 17:14:46 @sarang what are you coding this in? I have python code to strip those out 17:14:53 This is Python as well 17:15:05 If you can link the code that'd be great, or I can write something up 17:15:42 But uniform selection seems very unlikely to cause the long tail 17:17:16 Anyway, this is the start of analysis that I hope will be useful to inform safer output selection 17:17:31 very cool thanks for you effort sarang :) 17:17:36 Once I verify this indexing issue, I'll post both the analysis code and the data set 17:17:47 https://www.irccloud.com/pastebin/BChX6gR9/ 17:17:49 I can't post _all_ the data (block, transaction, ring, ...) since it's far too big for GitHub 17:17:50 @sarang, I mean the interoperability, if it can be made between Monero and other chains, there would be more room for the adoption of XMR. I learn about this from the fact that Bitcoin is entering Ethereum network with the amount that is way larger than which on the layer 2 of Bitcoin. It helps BTC to join the DeFi and increase the adoption for 17:17:50 such crypto. Same thing can also happen with XMR, don’t you think? 17:18:02 But I can post the resulting possible merges, which are of reasonable size 17:18:19 Thanks Isthmus 17:18:51 https://usercontent.irccloud-cdn.com/file/fZgJlX2o/image.png 17:18:51 kiwi_87: operating between Monero and other chains is surprisingly tricky, and even moreso if the goal is to maintain uniformity of transactions 17:18:53 https://usercontent.irccloud-cdn.com/file/aQVzvAAq/image.png 17:19:09 Isthmus: what are these plots? 17:20:28 Let ring_member_ages be an array of ring member ages [0.5d, 0.7d, ...] 17:20:43 offset-corrected median age = median(ring_member_ages - min(ring_member_ages) 17:21:14 The correct decoy algorithm produces OCMA's around 100 - 10000 blocks 17:21:33 I used 370000 as a conservative "absurdity limit" 17:21:34 Small sample => high variance, I assume? 17:22:01 Might also have to do with fact that algo reacts to txn vol changes 17:22:20 Anyways, anything above 10^5 is suspect 17:22:23 Red line is 370000 blolcks 17:22:32 Anything above that is absolutely not from the correct decoy algo 17:22:47 Examining the distribution with that filter will be very interesting 17:22:48 And in most cases, when I spot checked, were due to apparent uniform decoy selectioin algo 17:23:05 I'd expect that it wouldn't change much, but I like being proven wrong 17:24:20 Any other speculation about the effects of these selections? (just curious) 17:25:21 Hmm, I'm interested in the Bayesian analysis, which will tell us whether this is a novelty with 10% predictive power, or a damning tell with 95% predictive power 17:25:24 Oh and Isthmus: what transactions does this account for? The entire chain? 17:25:42 From introduction of RingCT until Konferenco 17:25:58 Does it filter out non-CT transactions after the CT cutoff? 17:26:10 These are low quantity, but are still present 17:26:17 and have very different selection of course 17:26:37 I usually ignore non-RingCT since I'm more interested in optimizing current privacy than studying historical easter eggs 17:26:44 yeah 17:26:51 I'll have to work my way back in the analysis pipeline to check 17:26:54 I also filtered those in the plots above 17:27:08 Sorry, by "ignore" RingCT, I mean "exclude them from my data set before analyzing" 17:27:13 roger 17:27:15 s/RingCT/non-RingCT 17:27:16 Isthmus meant to say: Sorry, by "ignore" non-RingCT, I mean "exclude them from my data set before analyzing" 17:28:25 Oh, and I might have mentioned this last week (don't recall), but I'm still working with those CMU student researchers to confirm some updated deducibility analysis 17:28:34 They plan to revise their preprint once again 17:29:07 This is especially nice given that their "30% traceable" (or whatever it was) conclusion regarding spend age heuristics is incorrect 17:29:30 @sarang. Yeah I know it’s the hardest part. Actually our research at Incognito project is currently on this direction. 17:29:32 We have the idea of building a privacy chain learning the technology from Monero, thus allowing the high level of privacy for the chain. 17:29:40 Then build a Portal connecting to Monero with a group of decentralized custodians holding & releasing XMR when users going in & going out the layer 2. The same design can be applied to BTC, which brings XMR & BTC to the same privacy layer. 17:29:40 What do you guys all think? 17:30:05 This might be a better conversation for after the meeting kiwi_87 if it mainly concerns research for another project 17:30:14 Unless the group disagrees 17:30:25 Not this silent part of the group. 17:31:03 Were there any other questions on the deducibility or output merging data? 17:32:23 If not, does anyone else wish to present research of interest for this group? 17:32:40 @kiwi_87 cool, I like seeing these types of projects. 👍 17:32:49 I can give some updates about the swap 17:32:54 Please do 17:33:14 (this may be relevant to you kiwi_87) 17:33:18 I started working on it, I plan to have an updated version of the paper next week 17:33:37 So, the idea is still the same as before 17:34:21 @sarang yeah sure. I’ll talk more about what we are doing in the after-meeting time. Still, I think interoperability on XMR could be a very bright way to increase the Monero adoption. Would love to talk to other researchers who are also diving in the same direction 17:34:34 split the monero spending key in two halfs, and "sell" one half or the other on the bitcoin chain depending if the swap success or not 17:34:47 via multisig, I assume 17:35:13 "You get the even bytes, and I keep the odd bytes!" 17:35:34 Yes, kind of. Before there was the generic zkp for the hash preimage 17:35:39 @Isthmus sure. Would love to share more in the after-meeting time. Now let’s make the convo laser-focused on Monero 17:36:07 h4sh3d[m]: but you're replacing with a cross-group DL equivalence proof via side channel, correct? 17:36:45 @h4sh3d[m] would love to hear about this. Really want to know what’s going on there with the cryptography challenge. Please update us :D 17:36:46 Now, by combining dl equality across group + ECDSA one-time VES, we should be able to achieve the same 17:37:10 ECDSA one-time VES: https://github.com/LLFourn/one-time-VES/blob/master/main.pdf 17:37:35 (it's an ECDSA "adaptor signatures") 17:37:44 Remind me: does this approach assume/require any particular timelock capability on the Monero side? 17:37:51 If so, to what extent? 17:38:16 No, nothing is required on the Monero side, that's the cool part 17:38:21 OK, thanks 17:38:49 Monero supports a very simple timelock of course 17:39:05 but it's a bit inconsistent at the moment, and apparently infrequently used 17:39:14 so if it were required, this could present a uniformity issue 17:39:35 We create an address where Spend = Spend_alice + Spend_bob (same for view) 17:39:51 and send the Monero to corresponding address 17:40:11 Does the address protocol have issues with key cancellation? 17:40:16 Each participant has his own half, and one will get the second one 17:40:21 Or is there precommitment to address parts? 17:41:24 Not sure if I understand what you mean by key cancellation 17:42:47 If you hand me a part of a key, maybe I maliciously generate my own "key" such that the sum is any value I want 17:43:11 Ah yes, I thought about that 17:43:14 If this is problematic, we can each commit to our key portions first, and then check that the keys received match the commitments 17:43:23 it ensures that neither party change their mind 17:43:32 Adds a communication round 17:44:22 There are other methods involving random-oracle linear combinations too, depending on what you need 17:44:28 I thought about the commit, but that also mean you don't know your correct "half" (only the destiantion priv/pub), and without priv half, you are not able to continue the protocol 17:44:30 But sorry, I'm digressing here 17:44:34 @sarang @h4sh3d[m] just thinking out loud, both atomic swap & layer 2 swap are all good for XMR because they make the trustless swap XMR<>BTC. But if we want trustless swap XMR<>other cryptos, we will need more atomic swap designs and Portal designs connecting layer 2 and Monero chain 17:44:46 No, it's a good one 17:44:48 kiwi_87: let's discuss after the meeting 17:45:28 h4sh3d[m]: ok, as long as it's either not necessary or taken care of via a communication round, I suppose 17:45:44 But certainly worth a close eye after the paper is updated 17:46:40 when we get the address, and the initialization phase is done (with zkp dl equality e.g.), one send Monero into it 17:46:46 @sarang sure 17:47:23 at the end, Alice or Bob, will learn the full private spend key = priv_spend_alice + priv_spend_bob 17:47:36 So no, nothing fancy required on the Monero side 17:48:02 nice 17:48:08 You will import the full keys in you wallet and do a regular transaction 17:48:12 Definitely look forward to seeing the updated paper h4sh3d[m]! 17:48:40 same 17:48:46 (keys that are generated withou a seed and a derivation function, so wallet must support "raw" keys) 17:49:18 Right now, I'm in the one-time VES paper, and your MRL-0010 one 17:49:27 got it 17:49:43 * I'm done, thanks for your inputs 17:49:53 I might update MRL-0010 to specify that the Pedersen generators need an unknown DL relationship 17:50:15 Apparently that wasn't listed specifically, but is generally true for Pedersen commitment security 17:50:16 In the interest of time, were there any other research topics that need to be presented before the hour is up? 17:50:46 Quick update: I’m really happy to share that we’re officially beginning our audit of monero’s security and privacy mechanisms against algorithms that could be exploited by hypothetical quantum adversaries. Thank you to everybody who contributed feedback or funds to our CCS 🙏 17:50:50 The first step is a formalizing our adversary model and enumerating of mechanisms of interest. 17:50:53 Right now the attack surface list looks like {Ring Signatures, RingCT, One-time "Stealth" Addresses, Pubkey derivation, Forge amounts?, Bulletproofs, RandomX proof-of-work, Block / Transaction hashing}. 17:50:56 Please suggest other pieces that you’d like to see audited. :- ) 17:51:02 Earlier I was looking at the wallet generation schematic shared to Reddit, and it has me pondering visual ways to communicate results. https://www.reddit.com/r/Monero/comments/gy0m1u/i_made_an_infographic_on_how_a_monero_wallet_is/ 17:51:02 [REDDIT] I made an infographic on how a Monero wallet is generated. Can you find any mistakes? (https://i.redd.it/tv98m10mbd351.png) to r/Monero | 163 points (100.0%) | 18 comments | Posted by Krakataua314 | Created at 2020-06-06 - 22:42:54 17:51:04 https://i.redd.it/tv98m10mbd351.png 17:51:07 For example, the ed25519 scalarmult (used for private view key → public viewkey) is a one-way function for traditional computers (assuming hardness of the discrete log problem) but can be reversed if you can apply Shor’s algorithm. 17:51:12 So perhaps this could be visually annotated with directional arrow for traditional adversaries and bidirectional arrow for hypothetical quantum adversaries. Would that be an intuitive approach? 17:51:33 I like that idea 17:51:45 that's very clever 17:53:14 Can you remind us of the expected timeline Isthmus? 17:53:31 Will be working on this full time for the next 3 months 17:53:36 (with the understanding that research often takes unexpected twists) 17:54:05 Phase 1 should be quick 17:54:14 The scope was modified to focus less on deliverable code, right? 17:54:32 And more on solid understanding, possible mitigations and relevant work, and communication? 17:54:34 Just setting the stage for our object of study and attacker, hoping to have a first "final draft" of that done by next MRL meeting 17:54:39 Oh nice 17:54:42 Yep 17:54:44 That'll be great to see 17:54:51 And then working systemically through the cross sections 17:55:17 (table where each column is a quantum adversary and each row is a piece of Monero tech) 17:55:18 My guess is that we'll be able to fill 80% of the squares in 20% of the time 17:55:24 And then 20% of the squares will take 80% of the time 17:55:24 Do you expect that the final results will be suitable for broader distribution? Like to journals, refereed conferences, or simply IACR archive? 17:56:14 Throughout this entire project, the community will receive updates during the weekly #monero-research-lab meetings. During phase 3 however, several specific documents (the key deliverables from this research) will be freely published 17:56:18 1. User-friendly writeup: This community-facing writeup will provide an approachable explanation of how hypothetical quantum computers may impact Monero, and possible future mitigations. The writeup should minimize FUD and provide the context that these vulnerabilities apply to almost all cryptocurrencies (not only Monero). 17:56:31 2. Technical documentation: An MRL position paper to distill key information for (current and future) researchers and developers. The writeup should formally describe vulnerabilities, and highlight potential strategies and solutions, noting their tradeoffs. Code snippets may be included if appropriate for pedagogical purposes or clarity. 17:56:37 3. Non-technical 1-pager: An ELI5 / TL;DR summary will be provided for journalists, Monero Outreach, etc. This blurb will discuss risks and myths with no technical jargon, with key takeaways that a broad audience will appreciate. 17:56:41 (Results and updates will be also disseminated via Twitter threads, Reddit posts, and Breaking Monero videos.) 17:57:00 And yea, hopefully we can get a paper or two out of this 17:57:16 Much of the research will be broadly applicable 17:57:42 Great! 17:58:00 Nice 17:58:36 Getting a better sense of research trends in this direction, even if not presently applicable, will be intriguing to see 17:59:04 e.g. there are plenty of ideas for post-quantum constructions, but there are generally huge barriers in efficiency that render them unusable 17:59:26 btw Isthmus, this may be off topic but can you talk a little more about the Insight program? 17:59:27 OK, we're just about out of time 17:59:41 atoc: perhaps for right after the meeting? 17:59:44 yes 17:59:55 Are there any other last questions or comments about these research topics before adjourning? 18:00:19 If not, thanks to everyone for attending and participating! 18:00:26 Please feel free to continue discussions 18:00:39 Thank you 18:00:45 It appears that kiwi_87 has left 18:00:54 Perhaps they'll return 18:01:01 * sarang goes to post meeting logs 18:01:43 * Isthmus has to run into another meeting, and will swing back later today 18:03:17 atoc: I believe this is the link to the Insight program where Isthmus works https://insightfellows.com/ 18:04:15 ah okay cool 18:05:06 btw sarang I shot you an email about project interest :) 18:05:42 will check shortly atoc, thanks 18:06:31 no problem just thought I'd give you a heads up 18:06:42 I gotta go for now, but I will be back tomorrow 18:07:18 see ya 18:07:20 sarang: in MRL-0010 when you write |G| = p you mean the order of the generator G, right? Not the group G 18:07:48 The order of the generator of a cyclic group is the same as that of the group 18:08:08 And the groups are assumed to be of prime order 18:08:12 Ok, so |G| = |G'| 18:08:40 Yep, provided they're both nonzero (which should be the case here... again, I should update to make the generator assumptions more clear) 18:09:13 Choosing one generator to be the "common basepoint" and the other to be a (nonzero) public hash would be sufficient 18:09:20 and probably more efficient in practice 18:09:53 Thanks for pointing these things out h4sh3d[m] 18:10:12 I see, I was confused because I lack some math about group theory 18:10:17 MRL-0010 was mainly written so I had a clearer picture of andytoshi's original writeup (which also had some minor errors in presentation) 18:10:31 Thanks for your awesome work :) 18:10:45 Just pick nonzero generators in a verifiably random way (relative to each other) and you'll be good 18:10:57 Oh, to be clear, I didn't invent that cross-group construction 18:11:12 I merely wanted documentation in that form 18:11:47 I remember when you talk about it here weeks ago with andytoshi 18:12:13 s/talk/talked/ 18:12:13 h4sh3d[m] meant to say: I remember when you talked about it here weeks ago with andytoshi 18:12:18 It's certainly a very clever idea 18:12:34 Neat to see it having a use case that could be of value 18:14:59 The one-time VES ECDSA requires a dl equality but in the same group with \exists x | xG = A \and xH = B given (G, H, A, B) 18:15:32 As an implementation perspective it would be nice if we can reuse some parts with the cross-group one 18:15:52 But I think the schemes are too different, what do you think? 18:17:07 (They do it with Fiat-Shamir applied to Sigma protocol) 18:17:50 Sure, that's just a Schnorr-type proof 18:18:00 Very well understood 18:18:11 The cross-group part is the tricky side of things 18:19:18 h4sh3d[m]: in case you didnt see, philogy had a different idea for atomic swaps, although I think it would require a hard fork for both bitcoin (new op) and monero (new kind of tx): https://github.com/monero-project/research-lab/issues/74 18:19:56 By "new kind of tx" do you mean one separate from "standard" transactions that would coexist on chain? 18:20:14 And getting a supported BTC fork sounds... unlikely 18:20:18 yes those with revokable outs 18:20:34 anyway an interesting concept 18:20:43 Oh, the revokable idea, yes 18:20:47 Yeah 18:21:12 Keeping txs uniform and consistent is far more important IMO 18:21:46 I went quickly to the paper today, mostly the atomic swap part, but I'm a bit confuse, the new OP is `OP_CHECK_ED25519_POINT` 18:22:18 So I don't know if the name is correct or if this would requires support for ed25519 in Bitcoin 18:22:23 What's the purpose of the op? (have not read that linked paper yet) 18:23:22 the op would take a tx pubkey/privkey pair and true/false if they are related 18:23:43 Oh, on ed25519 18:23:46 he says you could do a btc<->eth<->xmr swap without the op 18:23:52 Yeah, that's not gonna happen on BTC 18:24:58 I probably spoke too quickly lol, since the OP is for demonstration and not a proposal 18:25:53 I'm not sure if the paper accounts for ed25519 and secp256k1, or if secp256k1 is not needed 18:26:36 (I mean, apart for signing btc tx) 18:26:51 the public revocation key could be added to all transaction outputs to keep outputs uniform 18:27:48 philogy are you a latex diagram expert? these are impressive images 18:28:10 ^agree 18:28:11 I used https://app.diagrams.net/ but thanks :P 18:30:00 I'll be afk for a bit... sgp_ asked if I could make some plots showing transaction types over time, so I need to write some scripts 18:33:19 Could that you mentioned different curves, I just thought that if Bitcoin were to extend their opcode set one day to include an OP for secp256k1 I thought they would just as well add other curves. 19:35:46 Btw sarang -> https://www.reddit.com/r/Monero/comments/h00332/feasibility_of_erlay_integration_into_monero/ 19:35:46 [REDDIT] Feasibility of “Erlay” integration into Monero? (self.Monero) | 8 points (100.0%) | 3 comments | Posted by fort3hlulz | Created at 2020-06-10 - 00:30:43 19:35:50 Maybe worth having a look at 19:39:50 Yeah I'd love to hear more about that 19:40:13 Could be completely pointless, but its an interesting protocol change that could be helpful as the network scales 19:40:21 Thanks for sharing it here dEBRUYNE! 19:52:56 It could probably play nicely with D++ diffusion in theory, but it's not clear how that could subtly affect the conclusions/guarantees that D++ provides 19:53:23 My fellow math grad students and I would sometimes say "it's not obviously wrong" when we didn't have a proof for a particular conjecture! 19:53:39 ;) 19:55:49 Also: is bandwidth and data transfer for transactions considered problematic on the Monero network? 19:56:10 If not, this could be a solution in search of a problem (when applied to Monero, that is) 20:06:06 It may increase the theoretical tx throughput of the network, which may be the most important bottleneck for scaling (setting aside storage costs for full nodes). 20:10:38 we are probably quite far away from that limit though, and it sounds like erlay is opt-in like D++ 20:11:40 Sure, any reduction in over transfer might increase the throughput 20:12:00 s/over/overall 20:12:01 sarang meant to say: Sure, any reduction in overall transfer might increase the throughput 20:23:15 there's no evidence we're anywhere close to that limit yet 20:23:57 but I'd agree it's a hard limit, and one we have to keep an eye on 20:25:33 I mean seriously, I can still run a fullnode on a phone connected only by 3G data, and still websurf, email, etc on the phone at the same time 20:28:10 does that happen to be an unlimited data plan? 20:28:15 yes 20:28:51 like unlimited unlimited or american unlimited? 20:29:10 but now you're raising a different issue. my point is that available bandwidth on current networking technology isn't yet a barrier for txn or block propagation 20:30:04 it's advertised as 20 euro for unlimited data for 28 days. on your billing statement it shows as 2TB capacity. 20:30:07 ya i should have added as an aside. 20:30:29 👌 20:30:30 which, I think, is beyond the bandwidth capacity of the network in that timespan 20:30:39 tho I haven't actually done the math 20:31:57 it used to be 20 euro per month, but whether a month was 30, 31, or 28-29 days was ambiguous, so now it's explicitly 28 days 20:34:09 thats like my cable line cap 😂 20:35:47 just ran the numbers, would require a sustained 964KB/sec for 24/7 for 28 days 20:36:15 I did 6.6TB on my network last month 20:36:16 lmao 20:36:35 But thats obviously far more than just a Monero node 20:36:59 I should start tracking network usage of just monerod though... I always have a ton of incoming peers and see pretty heavy RPC usage 20:38:48 hm, my current statement no longer shows 2TB - it literally has an infinity symbol 20:40:33 Or maybe it just means 8 bytes... 20:40:46 A friend of mine has a 10gb internet to his house 20:41:12 It's free.fr, obviously betting that you're not going to actually try to use it 20:42:02 I make pretty good use of my 1gbps fiber 20:42:40 My seed node has ~275 GB (cumulative up/down) in 28 days. 21:09:10 my network was doing +/- TB/mo until i cut in-peers down to 48. It was around 100. Now I'm in the 400-700GB range 21:11:55 Thankfully I have plenty of spare bandwidth and no cap, so I'm able to seed/provide as much RPC traffic as people need 23:56:07 hello is there a reward for a vulnerability