03:59:42

In regards to this BS stuff, Is monero moving towards nodes only on data centers and high-end infrastructure? 04:06:33 @reject-all:matrix.org: If it’s heavily spammed yes 04:14:06

If users are unable to run a node (without access to data centers, high-end equipment) does this threaten the decentralization (and therefore the censorship resistance) of Monero? 04:27:43 @reject-all:matrix.org: Obviously 04:28:01 Or (less rude) by definition, yes. 04:49:25

So you would say it's a requirement for the 'common' user with consumer hardware and typical bandwidth limitations to be capable of running a full node, and if otherwise Monero won't be a decentralized/permissionless? 04:49:25

Is this sufficiently being taken into account with regards to BS/scaling? 04:52:01

@ofrnxmr:xmr.mx 04:54:07 i wouldnt say a requirement, but a preference 04:55:55 Currently monero is running quite well on stressnet with 10+ mb blocks, including a couple old, hdd, quad core systems and a single core 2gb ram vm 04:56:57 As far as bandwidth, no. I don't think monero aims to support limited bandwidth, though we are working to reduce bandwidth by upwards of 70% from current 05:04:51 New Monero research paper just dropped! "Inside Qubic’s Selfish Mining Campaign on 05:04:51 Monero: Evidence, Tactics, and Limits" 05:04:51 Link: https://arxiv.org/pdf/2512.01437 (https://arxiv.org/pdf/2512.01437) 05:04:51 Credit to @ack-j:matrix.org for pointing it out in the MRL channel. Didn't see it posted here so wanted to share. 05:16:51 ^ I commented about this paper in MRL channel. TL;DR, they had limited/not granular data, estimated similar numbers as we did empirically from granular data 05:17:44 @ofrnxmr:xmr.mx: How much storage does these “old” systems need to have ? To be future proof for 3-4yrs 05:18:06

@ofrnxmr:xmr.mx: Interesting, I'll try and get setup with stressnet on my PC. 05:18:06

But I do find something a bit unclear: 05:18:06

Users able to run full nodes without data centers/high-end equipment is by definition decentralization/censorship resistance.[... more lines follow, see https://mrelay.p2pool.observer/e/5fvFs88KeDRoR29V ] 05:22:17 Dependa what you define as "common user" and "consumer hardware" and "typical bandwidth" 05:23:50 @reject-all:matrix.org: there's a future with aggregated proofs that would allow a mixed version of pruned/full/archival. One where it downloads pruned txs, but each block has an aggregated proof that fully verifies the transactions. Archival nodes would keep the per-transaction full proofs, but they aren't needed for these lighter full verification nodes. 05:24:04 Storage and bandwidth requirements for these would be vastly lower 05:24:32 tevador's proposal seems to intend to keep up with "consumer hardware" advancements 05:25:33 For full/archival nodes 05:33:49 @elongated:matrix.org: future proof with 10mb blocks = 3tb for year 1 :) 05:34:30 @ofrnxmr:xmr.mx: Isn’t the consensus 100mb limit ? 05:35:44 Just assuming some agency has its life mission to spam xmr 😅 05:36:01 30tb/yr ? With 100mb limit 05:36:24 making it highly centralized due to storage/compute/bandwidth costs -> then strike the central locations :) 05:37:00 @elongated:matrix.org: 100mb is the packet size limit, wont be hit for 6yrs under tevador's or articmines proposals 05:37:56 Yeah, ppl yelling fud about 90mb limit dont realize that 90mb is 65gb per day 05:38:02 in chain data* the limit can strike due to other factors 05:38:37 @ofrnxmr:xmr.mx: Thx to artic fans 05:39:36 i dont even think artic fans, just ppl who are claiming that im "breaking a promise" "for no reason" 05:40:06 Pointing to getmonero's retarded faq as proof that monero blocks are currently "unlimited" 05:40:51 People don't realize we use size_t and not arbitrary precision integers for packed and block sizes 05:41:07 can't even go past uint64_t block sizes! 05:41:19 https://www.getmonero.org/get-started/faq/#anchor-block-limit 05:41:19 > No, Monero does not have a hard block size limit. Instead, the block size can increase or decrease over time based on demand. It is capped at a certain growth rate to prevent outrageous growth (scalability). 05:42:04 @ofrnxmr:xmr.mx: Needs to be fixed 05:42:10 technically there is a cap even if we send packets less bad 05:42:22 if block header itself reaches packet limit :) 05:42:38 100 MiB block headers would be ... interesting 05:43:02 just about 3 million tx hashes 05:45:17 WHY ARE YOU BREAKING MONERO'S PROMISE! DATAHOARDER IS A FED WHO IS TRYING TO HIJACK MONERO 05:45:35 1 exabyte (2^63) block size :) 05:46:36 has anyone looked to see if zano has the packet limit? 05:46:52 damn, you can no longer address the storage of the world in a single uint64 05:48:06 After reading this, and the Twitter thread it links to, I fear we could be near a total breakdown of any sensible discussion about block sizes. Out go technical arguments and sound logical reasoning, and emotions totally rule the day: https://old.reddit.com/r/Monero/comments/1pem7eq/soon_bch_will_be_the_only_contender_for_sound/ 05:49:19 (There is currently a very detailed response to my comment from ArticMine caught in some filter, waiting for release.) 05:50:34 > This is all really strange considering that the current average block size is 100 kB and it's not possible to up it up to anything really big in a fast manner. 05:50:40 stressnet disagrees 05:51:31 Say, how much would it cost to produce a valid 50 MB block, mine it, and bring the network down with it? Can't be more than a few thousand dollars, I would guess? If I was rich I would be tempted to do that as an attempt to bring people to their senses. 05:51:35 yeah the temporary part (like, not even has to make it to the hardfork if fixed before) has been totally lost to the wind 05:51:51 if it's a miner, rbrunner7, effectively "free" 05:51:56 even better if they do 51% 05:52:12 they can pad their own blocks with txs to grow the median for free 05:52:15 Ah, yes, of course, because you get your expenses back :) 05:53:25 without majority hashrate you still need to spam, but you can get some better efficiency if you are already a mining pool 05:53:35 pad what you can and spam the rest 05:54:45 Maybe we can win over M5M400? 05:54:58 @ofrnxmr:xmr.mx: They are safe with 0.01 zano tx fees 05:55:27 funnily qubic was padding their blocks with withheld txs 05:55:31 zano = 100mb (same code as monero) https://github.com/hyle-team/zano/blob/master/contrib%2Fepee%2Finclude%2Fnet%2Flevin_base.h#L90 05:55:31 And 50mb p2p https://github.com/hyle-team/zano/blob/master/src%2Fcurrency_core%2Fcurrency_config.h#L141 05:55:38 ... but the max number of txs they could mine was, 20. 05:55:46 No, seriously, I think there are people right now that can only return to their senses quickly by hitting them on the head with a hammer. 05:55:54 so literally qubic had set a hardcoded limit into how many transactions could be included 05:56:13 zano 50mb limit!!!! 05:56:36 actually, we also do have 50mb packet size 05:56:41 and 100mb for levin 05:56:43 Yeah, but anyway not a contender for "sound money", so ... 05:56:58 MAX_RPC_CONTENT_LENGTH = 1048576 // 1 MB 05:57:04 DEFAULT_RPC_SOFT_LIMIT_SIZE 25 * 1024 * 1024 // 25 MiB 05:57:28 https://github.com/monero-project/monero/blob/master/src%2Fcryptonote_config.h#L141 05:57:28 monero has that same 50mb line 05:57:41 so maybe we are worse than we thought :) 05:57:57 in a worse place than* 05:58:08 Don't think you can get away with "unlimited logical block size, with a limit of 100 MB for individual block parts". See the word "limit" in there? That will be enough for people to freak out :) 05:58:23 block parts = txs 05:58:34 which is already bounded 05:58:35 Rbrunner, you didnt read getmonero.org? Blocks are unlimited 05:58:52 #define CRYPTONOTE_MAX_TX_SIZE 1000000 05:58:54 oh also 05:58:56 #define CRYPTONOTE_MAX_TX_PER_BLOCK 0x10000000 05:58:59 ^ also size limit 05:59:20 oh thats racist 05:59:25 I am stealth "small blocker", what do you expect. 05:59:28 that is 2^28 05:59:34 you have to change that to infinity 06:00:23 1000000 * 2^28 bytes to TiB = 244 TiB blocks 06:00:32 yet another limit 06:01:46 Well, maybe we could live with that limit if we drop blocktime down to 1 second. 06:02:04 More transactions that way. 06:02:53 bring it down enough that speed of light and distance starts making 10+ blocks orphanable so all miners need to coexist the same server rack 06:28:35 If we had asynchronous consensus, blocks could be produced per throughput, not an arbitrary time interval. 06:39:23 Note to self: If people around me throw reason and logic overboard and act almost purely on emotion, it doesn't help if I do likewise as my reaction to this happening. 07:45:40 With the current monerod limitations, miners will start limiting block sizes way before 100 MB 07:45:48 I mean performance limitations 07:45:56 Qubic even mined empty blocks for a while to be "more efficient" 07:50:25 P2Pool has a packet size limit of 128 KB which limits it to max 4k transactions per block 12:10:54 we need to build a fab 16:31:00 lazy developers need to do their job https://www.reddit.com/r/Monero/comments/1peug7m/monero_developers_are_on_track_to_add_an/ 16:32:08 shame on you all for prioritizing fcmp++. We all know that will lead to way worse privacy than simply allowing big blocks. shame! 16:38:30 A sad day for Monero. I can hear Monero's enemies rejoice. 16:40:12 This scaling death cult was a sleeping issue all along unfortunately. These network vulnerabilities finally being challenged is a step in the right direction 16:42:08 I would like to see LMDB manage a multi-terabyte blockchain file. Would be an interesting exercise. 16:48:58 @rbrunner7: LMDB2: eletric boogaloo when 16:53:58 I am happy to see some push back on reddit, starting a propaganda war is stupid. 16:55:30 so.. wen serialization limit fixes? 7999 8867 9433 16:55:47 cuprate has already done it :p 16:55:52 Since those limit blocks to ~30mb 16:56:32 @boog900: Right, but were fussing about 100mb genesis when we have a 30mb limit added in 2020 16:56:48 Thats been fixed since like 2021 16:56:59 I am really surprised it has taken so long for 9433 16:57:42 like the others I kinda get taking a while to review and whatever, but that should be a simple change. 16:58:04 Considering 9433 is just a stop-gap/bandaid, im also surprised that it hasnt yet been reviewed/merged 16:58:34 untested, removed the never used txin/txout values https://irc.gammaspectra.live/b11e6d8f7bdf2162/0001-remove-deserialization-and-serialization-code-for-tx.patch 16:58:54 mainnet node just works :') 16:59:05 > 6 files changed, 5 insertions(+), 292 deletions(-) 17:07:54 Had anyone compared 7999 and 8867 to see which actually perforns better? 17:10:06 Proposed some different scaling parameters: https://github.com/seraphis-migration/monero/issues/44#issuecomment-3617687600 17:10:17 8867 has, aiui, started to be merged in pieces, but 7999 is the smaller pr and (again, aiui) has demonstrated much improved performance 17:40:28 so these things could address the 90MB block limit. And have been sitting in PR limbo since 2021 17:42:01 so it'll soon be 5 years that these fixes have sat there. 18:12:38 @gingeropolous: The 30mb limit 18:12:52 The 90/100mb limit is unaddressed 18:13:15 Theres also a 50mb p2p packet limit, also inherited 18:14:12 @ofrnxmr:xmr.mx: I am working on a proposal to change how blocks are synced. Hopefully fixing this and adding a couple nice features. 18:14:33 @ofrnxmr:xmr.mx: Also I checked and I can't see where this is enforced. 18:14:35 Fluffy blocks during ibd w/ split messages 18:14:59 @ofrnxmr:xmr.mx: ?* 18:17:23 I mean we could reuse the messages but that wouldn't be ideal IMO. But if you just mean just the gist of fluffy blocks then yes. 18:20:54 download all block headers first, then add the txs 🧠 18:31:33 If you are taking the mick, then I don't see why. I want to add more to it than just that, for example adding support for not always sending the miner tx in a broadcast and not disconnecting if the block has enough PoW but is invalid, plus some more. I would prefer us get all these changes in at once as its a good time to do it. 18:32:15 Having a spec we can discus before I just put some code in Cuprate is the better way to do this. 19:08:54 I will comment here as I don't have a github account, the comment "The spam attacks we have had in Monero were stopped by by the short term median." 19:09:03 1) so we can distinguish spam :) 19:09:13 2) I thought why this wasn't successful is that the blocks did not grow at the expected rate, that there was a bug that kept fees too low to expand the blocks 19:09:17 I am thinking of the most recent episode, am I remembering this correctly? 19:17:13 nioc: Mostly the spam was using minimum fee. If the real users had auto-adjusted their fee to the next level, their txs would not have been delayed. I don't think the auto-adjust would have increased block size much because the vast majority of txs were the low-fee spam. More info: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf 19:22:17 yeah I though the low-fee spam was low fee due to incorrect auto-adjust 19:22:45 vague memories 19:31:23 <321bob321> CRS 19:38:27 for nioc 2) https://github.com/monero-project/monero/pull/9219 20:23:37 I believe in the good will of the people in this community with the Blocksize limit. 20:23:37 Satoshi also introduced a Blocksize limit with good will for safety reasons. This turned out to be the nail in the coffin for Bitcoin as money. 20:23:37 This shouldn't be done, because temporary things usually stay the way they are. That's just life experience![... more lines follow, see https://mrelay.p2pool.observer/e/zuK5zc8KX19ob2VN ] 20:29:28 it's already in the code and introduced. we are trying to remove it. 20:29:43 it came with cryptonote. 20:31:19 Zcash has a Blocksize limit of 2 MB and thus will never be more than private gold. Monero can be more than that! 20:31:58 To be clear, the blocksize will still be dynamic. The limit is not arbitrary like 1MB or 2MB, it is literally under what would break the Monero network with the current code if it gets there 20:33:36 things start breaking at 32MB already 20:33:37 the cap is 3x that 20:36:03 It sounds reasonable, but isn't this a nice problem to have? 20:36:03 I mean, if Monero gets used that much, great! We can introduce an emergency fix for that. But does it have to be rushed beforehand? 20:44:59 @tigerix:matrix.org: It is not a nice problem to have if it renders the network unusable. What good is a unlimited block size if the nodes can't sync those blocks? 20:44:59 Plan is to set a temporary cap on growth which would not be reached within 6 years. During that time it should be enough to resolve the underlying technical debt and fix the serialization issues with with the C++ daemon that prevent us from safely scaling. After that, the cap can be forked away, because nobody wants it to be t [... too long, see https://mrelay.p2pool.observer/e/4KOIzs8KLXBfUV9k ] 20:44:59 On Bitcoin, the 1MB block size limit was set to avoid spam. The 90MB block growth cap here is to ensure Monero doesn't literally die by bigger blocks than the reference client can chew if it gets that much activity 20:48:36 The 90MB cap doesn't do anything that is not addressed in my proposal, unless the fix for the 100 MB bug is not fixed in six (6) years 20:50:05 Yes, it is imperative to fix the 100MB bug asap 20:50:06 If Monero gets used more and more, we see it way before the worst case Szenario happens. 20:50:06 To be fair, currently there is no Blockstream in Monero luckily, who wants to make money by offering custodial services. But we never know which state actor is trying to stear Monero in the wrong direction. 20:50:10 What in reality is going on here is that people are arguing for this cap in order to avoid dealing with this bug during the next 6 years 20:51:19 @tigerix:matrix.org: There does exist a conflict of interest with strong links to US Law enforcement 20:51:35 21:36:03 I mean, if Monero gets used that much, great! We can introduce an emergency fix for that. But does it have to be rushed beforehand? 20:51:35 that's what we are trying to. not have to rush it. then forked away (or even remove before next hardfork if we fix the issues) 20:51:40 Way worse than Blockstream 20:51:43 @articmine: Not setting the cap would be a "gun to your head" to get it fixed within 6 years, yes. Unironically can be a motivating factor 20:51:52 like. it can be exploited today even worse with existing scaling 20:52:46 the packet size cap is 50 MiB, levin deserialization 100 MiB ... and as listed last night there are other fixed caps existing already inherited from cryptonote 20:53:04 With existing scaling one needs about 5 months 20:54:36 In fairness to cryptonote. In 2013 they were looking at over 2000 TPS. That was less than VISA back then 20:55:14 The TX size was like ~500 bytes 20:55:50 It was still a bad idea back then 20:56:53 i mean call me crazy pants, but I think 6 million transactions of FCMP is better privacy than 900 gajillion transactions of ringsize 16. FCMP gets in, then its optimize and fix all the things, like the PRs that have been sitting since 2021 that are kinda related i think 20:57:10 Actually no 20:57:22 i really think we're missing the forest for the trees 20:57:29 Especially with quantum computerss 20:58:07 well thats a whole other kerfuffle 20:58:08 @gingeropolous: anon / perfect-daemon had made PRs that upgrade serialization/etc, right? Maybe we'll see something of that sort from him now again after his CCS got funded 20:58:46 21:57:29 Especially with quantum computerss 20:58:47 ^ especially. FCMP++/Carrot includes specific changes to improve PQ 20:58:56 current addressing scheme does not. 20:58:58 @gingeropolous: It t actually a valid research topic 20:59:05 @articmine: are you saying RingCT is better than FCMP for QCs? 21:00:02 ^ > <@datahoarder> The conflict of interest here is delaying FCMP++ due to scaling issues which would already cover the part of breaking surveillance for rings, so that must be prioritized. Adding sanity scaling parameters/adjustments so that can exist happily with current implementations can speed the process of deploying this in an agreeable way and stopping BS 21:00:07 I am saying that with QC forward privacy can be broken by combining BS with QC 21:00:47 goal shifting now, FCMP++ deals with BS, but suddenly, that's irrelevant 21:00:54 One needs to hide the public keys. This is in the Carrot specification 21:01:24 yes, currently you can break it without even the public keys. Its even worse. 21:01:25 the carrot specification was changed recently :) 21:01:28 I implemented it 21:01:50 DataHoarder: It is not irrelevant, but it is not a complete panecea 21:02:54 DataHoarder: Do you still need to hide the public keys to have forward secrecy? 21:02:56 given current BS and you placing that much importance in it, I'd say FCMP++ completely neuters them except in specific future cases, which we built protection/fallbacks for (PQ turnstile test being one) 21:03:41 @articmine: even if you did this is a step up. 21:04:59 It is a yes or no question? 21:05:24 internal sends (change) is protected, even if they know all your public keys ArticMine. non-internal sends are protected, given that all public keys are not shared. 21:05:48 if they know explicitly your target address (not any) they can do quantum stuff there to learn amounts 21:06:04 learning a different subaddress is not 21:06:34 also - https://github.com/jeffro256/carrot/pull/6 21:06:39 ... but some pubic are available to a BS adversary 21:06:59 Public keys 21:07:02 why are we taking about this at all? 21:07:11 talking* 21:07:16 goal shifting boog900 21:07:21 100% 21:07:22 articmine: you have 0,2, BS has 0,3, they learn nothing 21:07:34 they have 0,2, they learn amounts. 21:07:37 in quantum 21:08:40 What does the sender have? 21:09:01 if exchange sends, they have 0,2 21:09:16 that is what BS has 21:09:22 but then you receive with 0,3. they get nothing 21:09:45 So then BS has 0.2 for some of the public keys 21:09:55 0,2 IS the public key 21:10:01 it's not shared with 0,3 or 1,2 21:10:16 that's why they are derivated with proper methods 21:10:32 (I mean 0,2 as account/index) 21:11:19 basically. exchange sends you money at address A (0,2). 21:11:53 They can break it! (but they already have the info). They can later break using quantum outputs received with specifically A (0,2) 21:12:18 you receive using B (0,3). this is not broken, this is an entirely new set of public keys 21:16:32 Yes but all the current outputs were received with 0.2 21:17:03 what do you mean 21:17:19 so they already know the details of the outputs? 21:17:21 then why do they need to learn them 21:17:25 there isn't carrot deployed yet 21:17:34 that's why it's important to have it 21:17:49 The existing outputs if the public keys are known 21:17:59 The address 21:18:17 there aren't carrot existing outputs 21:19:22 Correct, but if they are not transferred after FCMP++ they are still vulnerable 21:19:39 they are vulnerable regardless. it's not carrot outputs 21:19:52 so yes, migrating to FCMP/Carrot is important 21:20:07 without carrot you don't even need pubkeys > 22:01:24 yes, currently you can break it without even the public keys. Its even worse. 21:20:41 DataHoarder: You have to 21:22:19 why are non-carrot outputs even considered. they are broken under a quantum adversary directly 21:22:35 when you bring it up. migrating would be a factor. I'm answering > 22:00:07 I am saying that with QC forward privacy can be broken by combining BS with QC 21:24:57 Because BS relies on correlations between outputs,. So broken some not broken 21:25:15 They are not isolated from each other 21:29:17 The worst part of all of this is it doesn't even have to work. All the government has to do is to convince a judge and not a professional mathematician that it works 21:31:41