02:44:31 <***> Buffer Playback... 02:44:31 [22:11:43] most years don't see that much growth; intuitively, 5x seems reasonable to me 02:44:31 [22:12:43] if it grows more, people can elect to pay the fees for a bit, or not. not the end of the world really 02:44:31 [22:12:59] otoh, downsides of too much growth are pretty big 02:44:31 [22:13:23] There could be a further limit, ie 32x yearly, but only 100x every 5 years, say. It makes the thing even more complicated though. 02:44:31 [22:13:53] And sucks even more wrt keeping a running median of shitloads of values in memory. 02:44:31 [22:14:31] But it'd allow the large 32x surge while not allowing it to compound. 02:44:31 [22:16:06] is it a try to predict throughput demand by users or to calculate practically feasible throughput by hardware / network / implementation ? 02:44:31 [22:22:48] it was originally unlimited before the big bang attack was identified 02:44:31 [22:26:46] I'm in the camp of not thinking it's the end of the world if demand exceeds block space by a little bit for a short period of time. Some people will just pay more fees temporarily or wait longer, and I think that's okay 02:44:31 [23:29:27] 32x seems extremely excessive. 02:44:31 [23:29:36] I think allowing 2x yearly longterm is already pushing it. Neither bandwidth, storage nor compute grows that fast. 02:44:31 [23:29:58] I'm fine with short term scaling that allows a x10-25 increase for special events (e.g. holiday purchases), but long term should be much more conservative imo. 02:44:31 [23:30:13] Scaling too fast ultimately pushes out legitimate users when they can no longer conveniently sync their clients. 02:44:31 [23:30:26] Wasting an hour waiting for your wallet to sync because you forgot to open it for a week is worse for UX than paying a $0.25 tx fee. 02:44:31 [23:30:38] Private transactions are a niche use-case, it can cost something. 02:44:31 [00:23:22] In my ideal world I'd let it scale to BTC's capacity and then grow maybe 2x from there. But maybe that's a bad idea also 02:44:31 [00:52:53] sgp_[m] added 02:44:31 [00:56:50] Thanks! 02:44:31 <***> Playback Complete. 05:04:48 "Private transactions are a niche..." <- arguably it *should not* be a niche use case, that is the point of this project.... besides transactions exceeding block size temporarily is actually fine, if they regularly exceed block sizes (as in the case of bitcoin) blocks must be increased to sustain the network, as it would be obvious in that case that demand exceeds the infrastructure supplying it 05:07:12 I think a conservative choice for growth initially is fine, if it creates issues, expanding it will be obvious and easy in that case 05:32:23 Wasting an hour waiting for your wallet to sync because you forgot to open it for a week is worse for UX >>>. IMO, this is not a concern. The "wait for wallet refresh" is an element that can be engineered away at some point 05:34:38 well, that requires a fully syncd daemon for sure. 05:34:41 gingeropolous: How ? 05:35:11 if you have a fully syncd daemon, you can do it just be selectively scanning the blockchain. 05:35:34 the user has their own internal knowledge (in their head) of the current state of their wallet. Today, I know my wallet has 2 xmr in it. 05:35:51 7 days from now, I assume my wallet still has 2 xmr in it. I don't need the wallet to scan the chain to tell me. 05:36:21 I construct the tx with the outputs i already know about without scanning the intermediate week. 05:36:58 i call it "fast forward" 05:38:07 i imagine it as a button on a GUI wallet. Fast forward or skip. with a pop up that says "some silly warning" that a user can disable 05:38:51 some dude started working on something related, i think the PR actually made it in 05:39:05 Can work with remote nodes aswell ? 05:39:10 yep 05:40:10 Should be looked into, will improve wallet usability 05:41:04 but in general, yeah. i dunno what the magic numbers are for the various windows for capacity 05:43:15 i mean, ideally, to perhaps get at some real numbers, someone would get a bunch of numbers and find the current rates of growth and optimizations etc 05:44:38 i mean, that doesn't necessarily mean they will be the correct magic numbers, but we'll be able to say we used science to come up with them 05:46:54 this is prolly more for lab. but do the current formulas for this allow for contraction after an expansion? I remember thinking a decay function would be necessary 05:48:44 i guess it probably does contract. Because there might be logic in the protocol saying something like "Well, there was enough activity for it to grow to this size, therefore the system needs this capacity from this point on." 05:49:50 otherwise, assumptions are being made about the real world economy. Because if it contracts, it costs fees to increase it again. 05:51:00 so to increase the capacity of the network (to increase monetary velocity), there is a cost (because of the fees), so you temporarily decrease monetary velocity 05:51:34 blargh. this is economics. where the economists? 05:54:19 Cause i think the juries still out on which policy is actually best. I mean, in theory, with an expansion / contraction system, there will be a negative pressure on monetary velocity because people will want to wait for fees to go down. So at that point, its only people with capital to spare that prime the pump. 05:55:11 so it encourages people to save (perhaps?)? But, should the wheels of money always be greasy as possible? 05:55:51 of course, this all also depends on the nature of the mining network and who is participating in that, because the fees are being redistributed along with newly minted money 05:56:12 so many arrows! somebody, get a whiteboard! 06:09:59 "blargh. this is economics. where..." <- Economist here. Sounds like an interesting research project. 06:12:36 "so it encourages people to save..." <- In 1993 Douglass North won the "Nobel Memorial Prize in Economic Sciences" in part for his work demonstrating that reductions in transactions costs played a major role in economic growth throughout history. 06:14:11 Draw your own conclusions. 06:22:44 "so it encourages people to save..." <- A certain amount of savings can be good since in a closed economy (i.e. simplified so there is no trade or capital transactions with other countries), the amount of savings exactly equals investment, in a given unit of time. Investment is a (and in many cases _the_ ) key driver of economic growth. Many developing countries in the mid 20th century, including the Soviet Union, made 06:22:44 "forced savings" official policy through various means to boost investment. In general it has been assessed in hindsight as being more or less successful, but mainly in a particular stage of economic development. 06:26:55 But here savings means deposit into a loan-making bank -- not just sitting in a non-custodial wallet. Of course, no cryptocurrency today is a currency of any policy or economy in a traditional sense, so conclusions about fiat may not apply here. I guess we'll see what happens in El Salvador over the next several years. 06:35:44 * But here savings means deposit into a loan-making bank -- not just sitting in a non-custodial wallet. Of course, no cryptocurrency today is a currency of any polity or economy in a traditional sense, so conclusions about fiat may not apply here. I guess we'll see what happens in El Salvador over the next several years. 06:56:03 it's important that we don't get into extremes of defending either 0-cost txs (else we go the Nano route of no reasonable security) or extremely limited blockchain sizes. Hence why we need to agree on a somewhat liberal max growth rate as a compromise 06:56:13 picking either extreme sucks for everyone 07:05:52 My example of forced savings may seem irrelevant because it may in fact be irrelevant. It's hard to justify restricting individuals' freedom to transact without reference to some sort of externality -- a pecuniary externality in this case. When externalities exist, governments (or in this case the XMR consensus rules) might justifiably restrict individual freedom in order to enhance the common good (Pareto efficiency) within a 07:05:52 neoclassical, i.e. mainstream, economic framework. So, increasing transactions costs to encourage hodling should be justified on network security grounds or the like and probably not justified by its effect on encouraging saving. 07:18:44 "it's important that we don't get" <- I agree, which is why I said an initially conservative growth rate is probably for the best, again if it turns out things are a little wonky we can easily patch it to have a more accurate growth rate... increasing it too quickly will however cause significant issues for smaller nodes, and not increasing it will cause excessive fees, so both of those extremes are very undesirable 09:34:32 Moo had some ideas about a block chain which deletes ancient history as it goes along, which I think could benefit from some more study. Ultimately something like that will allow scalability with flexible block sizes 09:35:05 No idea how you would enforce such a thing on an established chain like Monero though 09:35:50 I have a branch on my fork that fixes #7624 but it looks like opening PRs is limited prior contributors and this'd be my first - anything I can do to get past that permissions issue? didn't see anything about it in CONTRIBUTING, at least 09:35:51 well, I think you wouldn't need to enforce it per-say 09:36:04 for example right now monero allows you to prune to 1/3rd the blockchain securely 09:36:28 so I assume just giving clients the option to purge old data would be ok... however it might introduce some off segmentation or risk history disappearing 09:36:34 definitely should be looked into I think 09:36:52 * so I assume just giving clients the option to purge old data would be ok... however it might introduce some odd segmentation or risk history disappearing 09:43:14 DangrOnTheRangr: give luigi1111w or binaryFate your github email address and they'll add you. 09:44:45 "https://github.com/DangerOnTheRanger/monero/tree/wallet_dir_password_file_either_or" this user likely 09:45:10 yeah, that's the one 09:45:25 moneromoooo: appreciate it, thanks 11:32:12 Rucknium[m], well, the externality in this case would be an economic collapse. I would assume a decrease in monero transaction numbers indicates that the meatworld economy is slowing. There are less people buying and selling things. Now, of course, this isn't necessarily a bad thing, i've just been brainwashed on a forever-consumption world. So if this externality is a collapse .... 12:08:36 well i guess in your framekwork the question would be whether the monero network needs more protecting in times like those 13:00:55 @wfaressuissia Hi, the changes in the Dockerfile didnt work! 13:02:20 @mj-xmr Hi, did you manage to build the docker image successfully with readline? 13:07:00 libtinfo-dev from apt isn't suitable since it should be recompiled with `-fPIC` too 13:11:08 yes, so i have to compile libtinfo-dev staticlly you think 13:11:59 just read contrib/depends and copy/paste dependencies build instructions into Dockerfile or use depends directly from Dockerfile 13:17:36 ha yeah in the contrib/depends didnt think of it thanks wfaressuissia 14:44:54 gingeropolous: Could you walk me through how Monero would be harmed if its transaction volume were to "organically" fall substantially? Is it that it would make a de-anonymizing FloodXMR attack easier because the allowed block size would still be high? 18:40:31 Anyone knows how to fix recent cmake changes, leading to: https://oss-fuzz-build-logs.storage.googleapis.com/log-7bd60497-1700-4d55-9025-6ac39ca52d25.txt ? 18:41:04 wfaressuissia[m]: I think anon is you ? 18:41:47 not clear why it doesn't work on oss-fuzz, we tried it on all OS 18:42:25 moneromoooo: https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L237 18:42:29 I guess I should take it out just for it then ? 18:42:29 can we add if not oss-fuzz there? 18:47:44 or maybe it's reproducible with clang12 on linux 19:00:05 yeah Rucknium[m] , i guess that is one way. i didn't really have anything - i was just posing the question. 19:09:14 ffs, every fucking time I touch docker, it pisses me off... 19:16:14 "/src/aflplusplus/afl-clang-fast" this compiler is likely the reason 19:17:10 "https://github.com/AFLplusplus/AFLplusplus" yes, reproduced with this compiler without anything else 19:22:33 I think I'll just PR the test blind, docker sucks. 19:24:38 binaryFate: would be nice if 7824 could be merged early so oss-fuzz (hopefully) revives. 19:25:59 .merge+ 7824 19:25:59 Added 19:26:33 (unless it gets fixed rather than bodged before then) 19:32:11 it optimizes unused function 19:37:10 hello 19:37:17 its this monero crypto 19:38:26 It's a channel for monero development. Crypto stuff probably best for #monero-research-lab, here more for code. 19:38:39 #monero for usage. 19:41:52 im trying to get into cryto also 19:41:59 but i wanna create my own 19:42:35 never roll your own crypto 19:42:46 okay 19:43:43 i have a question i just downloaded android sdk and i wanna create an app how do test an app im creating 19:44:03 also how do i run a project im working on on git 19:45:31 this aflplusplus is somehow invalid, since it doesn't call linker by default, but calls it with `--verbose` 19:46:31 OK, then 7824 is good enough for me. 19:49:05 `-Wl,--verbose,--no-undefined -Wl,-undefined,error` so it will fail as expected with added `verbose`, does it make sense to support this shit in test ? 19:49:10 probably not 19:51:49 Depends what you intended. I don't really care either way. 20:17:54 21:24 binaryFate: would be nice if 7824 could be merged early so oss-fuzz (hopefully) revives. <-- luigi1111w 20:59:17 Hey guys, when's the clubhouse metting tomorrow. I love what the Monero project is and I want to contribute as much as I can!! 23:40:28 Hello! I am an avid supporter of monero and all you guys do. I just recently made a post on the monerosupport subreddit and was redirected here to get a relevant response. Essentially, I am trying to build the newest version of the monero gui on Fedora 34 using the official readme on the github repo but am running into compiling errors. I am not very proficient in programming and definitely not in cmake or linux related issues. 23:40:28 However, I have pasted an error log at this link: https://paste.debian.net/1206193 Hopefully this can help diagnose any potential future issues, and if I am at fault here, any help is greatly appreciated! 23:55:52 You're likely missing -pthread on the compilation or link command line. 23:56:15 Oh wait. 23:56:27 I stopped at the first error, didn't realize it's a cmake test :) 23:56:50 Can you paste the build error, that seems to be the cmake test stuff.