Buffer Playback...

[22:11:43] most years don't see that much growth; intuitively, 5x seems reasonable to me

[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

[22:12:59] otoh, downsides of too much growth are pretty big

[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.

[22:13:53] And sucks even more wrt keeping a running median of shitloads of values in memory.

[22:14:31] But it'd allow the large 32x surge while not allowing it to compound.

[22:16:06] is it a try to predict throughput demand by users or to calculate practically feasible throughput by hardware / network / implementation ?

[22:22:48] it was originally unlimited before the big bang attack was identified

[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

[23:29:27] 32x seems extremely excessive.

[23:29:36] I think allowing 2x yearly longterm is already pushing it. Neither bandwidth, storage nor compute grows that fast.

[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.

[23:30:13] Scaling too fast ultimately pushes out legitimate users when they can no longer conveniently sync their clients.

[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.

[23:30:38] Private transactions are a niche use-case, it can cost something.

[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

[00:52:53] sgp_[m] added

[00:56:50] Thanks!

Playback Complete.

<tobtoht> "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

I think a conservative choice for growth initially is fine, if it creates issues, expanding it will be obvious and easy in that case

<tobtoht> 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

well, that requires a fully syncd daemon for sure.

gingeropolous: How ?

if you have a fully syncd daemon, you can do it just be selectively scanning the blockchain.

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.

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.

I construct the tx with the outputs i already know about without scanning the intermediate week.

i call it "fast forward"

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

some dude started working on something related, i think the PR actually made it in

Can work with remote nodes aswell ?

yep

Should be looked into, will improve wallet usability

but in general, yeah. i dunno what the magic numbers are for the various windows for capacity

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

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

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

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."

otherwise, assumptions are being made about the real world economy. Because if it contracts, it costs fees to increase it again.

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

blargh. this is economics. where the economists?

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.

so it encourages people to save (perhaps?)? But, should the wheels of money always be greasy as possible?

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

so many arrows! somebody, get a whiteboard!

<gingeropolous> "blargh. this is economics. where..." <- Economist here. Sounds like an interesting research project.

<gingeropolous> "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.

Draw your own conclusions.

<gingeropolous> "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

"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.

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.

* 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.

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

picking either extreme sucks for everyone

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

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.

<sgp_[m]> "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

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

No idea how you would enforce such a thing on an established chain like Monero though

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

well, I think you wouldn't need to enforce it per-say

for example right now monero allows you to prune to 1/3rd the blockchain securely

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

definitely should be looked into I think

* 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

DangrOnTheRangr: give luigi1111w or binaryFate your github email address and they'll add you.

"github.com/DangerOnTheRanger/monero…/wallet_dir_password_file_either_or" this user likely

yeah, that's the one

moneromoooo: appreciate it, thanks

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 ....

well i guess in your framekwork the question would be whether the monero network needs more protecting in times like those

@wfaressuissia Hi, the changes in the Dockerfile didnt work!

@mj-xmr Hi, did you manage to build the docker image successfully with readline?

libtinfo-dev from apt isn't suitable since it should be recompiled with `-fPIC` too

yes, so i have to compile libtinfo-dev staticlly you think

just read contrib/depends and copy/paste dependencies build instructions into Dockerfile or use depends directly from Dockerfile

ha yeah in the contrib/depends didnt think of it thanks wfaressuissia

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?

Anyone knows how to fix recent cmake changes, leading to: oss-fuzz-build-logs.storage.googlea…497-1700-4d55-9025-6ac39ca52d25.txt ?

wfaressuissia[m]: I think anon <anon [at] nowhere> is you ?

not clear why it doesn't work on oss-fuzz, we tried it on all OS

moneromoooo: github.com/monero-project/monero/blob/master/CMakeLists.txt#L237

I guess I should take it out just for it then ?

can we add if not oss-fuzz there?

or maybe it's reproducible with clang12 on linux

yeah Rucknium[m] , i guess that is one way. i didn't really have anything - i was just posing the question.

ffs, every fucking time I touch docker, it pisses me off...

"/src/aflplusplus/afl-clang-fast" this compiler is likely the reason

"github.com/AFLplusplus/AFLplusplus" yes, reproduced with this compiler without anything else

I think I'll just PR the test blind, docker sucks.

binaryFate: would be nice if 7824 could be merged early so oss-fuzz (hopefully) revives.

.merge+ 7824

Added

(unless it gets fixed rather than bodged before then)

it optimizes unused function

hello

its this monero crypto

It's a channel for monero development. Crypto stuff probably best for #monero-research-lab, here more for code.

#monero for usage.

im trying to get into cryto also

but i wanna create my own

never roll your own crypto

okay

i have a question i just downloaded android sdk and i wanna create an app how do test an app im creating

also how do i run a project im working on on git

this aflplusplus is somehow invalid, since it doesn't call linker by default, but calls it with `--verbose`

OK, then 7824 is good enough for me.

`-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 ?

probably not

Depends what you intended. I don't really care either way.

21:24 <moneromoooo> binaryFate: would be nice if 7824 could be merged early so oss-fuzz (hopefully) revives. <-- luigi1111w

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!!

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.

However, I have pasted an error log at this link: 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!

You're likely missing -pthread on the compilation or link command line.

Oh wait.

I stopped at the first error, didn't realize it's a cmake test :)

Can you paste the build error, that seems to be the cmake test stuff.