15:09:13
rucknium:
MRL meeting in this room in two hours.
17:00:37
rucknium:
Meeting time! https://github.com/monero-project/meta/issues/1303
17:00:41
rucknium:
1. Greetings
17:01:07
emsczkp:matrix.org:
Hi
17:01:25
gingeropolous:
hi
17:01:39
jberman:
waves
17:02:00
ack-j:matrix.org:
Hi
17:02:09
preland:
Hi
17:03:00
vtnerd:
Hi
17:04:06
rucknium:
2. Updates. What is everyone working on?
17:05:42
rucknium:
me: Investigating medium- and long-term selfish mining countermeasures again. Looking at FCMP hard fork scaling parameters.
17:07:03
gingeropolous:
me: spinning up my scrap heap for fcmp stressnet testing. Hit a wall with monerosim re: mining shim, going to revert back to less perfect block controller
17:07:23
emsczkp:matrix.org:
wrote the ccs proposal "Bulletstar", renamed in Bulletproofs*
17:07:37
jberman:
me: FCMP++ alpha stressnet I shared a custom build that includes changes slated for v1.5 alpha stressnet to address OOM's, received a couple reports from people using that build I want to continue investigating (new sync issues), planning to put out a new CCS proposal soon
17:08:07
preland:
Continuing i2p bounty work, and personal research into more radical/general scalability paths.
17:08:20
vtnerd:
me: squashing a few things (bugs) in lws, adding a get_info (get_version) endpoint to lws, and working on lwsf lookahead (still a slight mess)
17:09:25
glory47:matrix.org:
Best quality strains 🍁, vapes, carts, shrooms🍄, edibles, Gummies, Distillates, ice caps🥢, chocolate bars🍫, syrups, xtc, heroine, xanax, oxy,pills, lsd, coke, meth, vapes, dmt, mdma, clone cards, fake notes, experts for cashapp and PayPal flip/transfers. Discreet delivery and shipping depending on your location worldwide
17:09:25
glory47:matrix.org:
-Harm Reduction Comes First💯
17:09:25
glory47:matrix.org:
-No Sales to underage 🔞😔
17:09:25
glory47:matrix.org:
-Only Tested Stuffs for Sale ✅🛡
17:09:26
glory47:matrix.org:
-Own a Drug Test kits 🙏[... more lines follow, see https://mrelay.p2pool.observer/e/wsyN1cwKdkhmcmhn ]
17:10:38
plowsof:
redacted
17:10:43
rucknium:
(minimum power level to send messages here temporarily raised to 10)
17:11:50
rucknium:
(Ping me in #monero-research-lounge:monero.social if you need your power level raised.)
17:11:59
rucknium:
3. BulletStar (more efficient membership and range proofs) (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626).
17:13:24
emsczkp:matrix.org:
Here I am, I'm the author of this CCS, thank you for this space
17:13:42
rucknium:
@emsczkp:matrix.org: Thanks for joining the meeting.
17:14:00
articmine:
Hi
17:15:03
rucknium:
@emsczkp:matrix.org: Would the proposed changes to the FCMP cryptography require a hard fork?
17:15:46
ack-j:matrix.org:
@emsczkp:matrix.org: How does bulketproof* compare to your previous work on constant time range proofs?
17:15:47
ack-j:matrix.org:
https://moneroresearch.info/178
17:15:54
rucknium:
Do most of the efficiency gains occur with multi-input txs? How much benefit would single-input txs see?
17:21:13
emsczkp:matrix.org:
@rucknium: No, the proposal is an improvement to the zkp proofs mechanisms behind FCMP
17:21:40
emsczkp:matrix.org:
@ack-j:matrix.org: this is related to the question of if the Halo's modified IPA is compatible with that of BP in order to do accumulation, and the answer is no ... this research was trying to explore that direction
17:22:08
ack-j:matrix.org:
s/time/size/
17:22:12
rucknium:
So the planned FCMP hard fork could occur, then BulletStar added afterward without a hard fork?
17:24:15
sgp_:
Thank you for making the proposal
17:24:53
jberman:
i.e. no modifications to the membership proof and range proofs used in FCMP++ txs would be needed, and the folding scheme would simply fold the existing proofs?
17:27:52
emsczkp:matrix.org:
@rucknium: there is an asymptotic gain with folding as long as your computations grow, in single-input txs you should not see that
17:29:51
emsczkp:matrix.org:
@jberman: We have to operate inside the underlying GBP proof and I would expect some modifications
17:30:39
rucknium:
According to my calculations (2019-2024), 54 percent of txs are single-input: https://gist.github.com/Rucknium/d2c02f51a2d9f103a28caa8f51be7dbf/
17:31:56
preland:
Interesting to see than only around 7% have more than 2
17:34:19
jberman:
as I understand it, a folding scheme would enable accumulating many single-input txs into a single proof. So it's not as though there would be no benefits for single-input txs in aggregate IIUC
17:35:08
jberman:
I think @emsczkp:matrix.org was saying that standalone multi-input txs could benefit from a folding scheme too (if you're verifying a single 128-input proof e.g.)
17:35:20
jberman:
is that accurate?
17:41:51
jberman:
@emsczkp:matrix.org: although slightly different in that we may not be able to accumualte the existing proofs
17:42:03
rucknium:
How would this work in practice? Users send txs to miners and the miners create an aggregated proof, then post the aggregated proof to the blockchain and throw away the individual proofs?
17:43:31
jberman:
not being able to accumulate the existing FCMP++ proofs is ok imo, this research direction is imo a critical avenue for a more scalable protocol nonetheless
17:45:29
rucknium:
Will this be quantum-resistant?
17:46:12
jberman:
@rucknium: IIUC sounds like something like that would be possible. I imagine there would still likely be some archive nodes saving all individual proofs like @kayabanerve:matrix.org mentioned in that issue
17:46:47
jeffro256:
@rucknium: You couldn't discard individual proofs w/o a hard fork, but perhaps a new node could skip downloading those individual proofs and just download/verify the aggregate proof
17:46:58
datahoarder:
@jberman: pruned txs by default :), full node vs archival node time?
17:47:16
rucknium:
New nodes could do full chain verification without the individual proofs, right? Otherwise, it's not much better than simple pruning like we already have.
17:48:24
emsczkp:matrix.org:
@rucknium: no, the folding security will rely on the underlying standard assumptions of GBP. But there are interesting research proposal moving towards PQ safe folding
17:49:42
rucknium:
@kayabanerve:matrix.org suggested a moratorium on Monero cryptography research that is not quantum resistant. I don't necessarily share that view, but he did suggest that.
17:51:55
sgp_:
I tend to prioritize PQ safe as well
17:52:22
jberman:
I think it would be a nice added bonus to consider PQ in this proposal
17:53:01
jberman:
But considering this is an independent researcher aiming to take ownership of this specific research direction in parallel, I don't think it would make a lot of sense to block it
17:53:20
preland:
What would be the implications of shifting to PQ in terms of difficulty/clarity of implementation? I wouldn't want PQ to derail the whole thing
17:54:30
sgp_:
Yeah I definitely don't want to block it. It is a reasonable enough direction as-is. But practically, PQ safe is more important than efficiency with the existing assumptions, imho
17:55:10
emsczkp:matrix.org:
@preland: First you need a PQ safe GBP, then if you want folding is another question. From my knowledge there is only one proposal doing recursive proofs in PQ settings
17:57:28
rucknium:
We need to move on to the next agenda item. Any more quick comments or questions for now? It will come back as an agenda item next week.
17:58:24
jberman:
I'm a strong +1, grateful for the submission @emsczkp:matrix.org !
17:58:33
rucknium:
@emsczkp:matrix.org: IMHO, it would be good to add to the proposal a description in even simpler language of the likely benefits for Monero.
17:59:36
emsczkp:matrix.org:
ok, thank you
17:59:47
rucknium:
Thank you very much for your work on this, @emsczkp:matrix.org
18:00:23
rucknium:
I had to raise your power level, @hooftly:matrix.org .
18:00:29
rucknium:
We had spam earlier.
18:00:31
emsczkp:matrix.org:
thank you again, see you next week
18:00:59
rucknium:
4. P2Pool consolidation fees after FCMP hard fork. Coinbase Consolidation Tx Type (https://github.com/monero-project/research-lab/issues/108).
18:01:18
hooftly:matrix.org:
Ah I figured something happend
18:01:37
rucknium:
Any more discussion on P2Pool coinbase output consolidation for now?
18:01:41
DataHoarder:
No updates from last week. I need to start making a flow diagram to present here.
18:02:07
rucknium:
Thanks.
18:02:23
rucknium:
5. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-11.pdf). Revisit FCMP++ transaction weight function (https://github.com/seraphis-migration/monero/issues/44).
18:02:25
DataHoarder:
However, it'd depend on 1-in zero fee txs (in-pool) with fallback normal txs (with fees) for no multisig agreement. I think this topic can sit on the sidelines until above flow is ready.
18:03:56
rucknium:
Let me ask if "delayed" fast scaling would be acceptable. Slow scaling parameters in effect for let's say 2 years after the hard fork, then the fast-scaling parameters in effect after that.
18:04:12
articmine:
I am going to cut to the chase here
18:04:34
rucknium:
This would provoide time to make the node code more efficient and some more technological progress in storage and CPUs
18:05:21
articmine:
What I see is that stressnet has uncovered serious vulnerabilities that requires time and resources to fix
18:06:01
articmine:
Many of the devs feel overwhelmed by the task at hand.
18:06:14
datahoarder:
@rucknium: akin to ethereum's difficulty bomb, other way around? and worst case - the fast scaling can be soft forked if the code is not ready
18:06:48
articmine:
Fast scaling cannot be soft forked
18:06:50
jberman:
I see where you're headed with this @articmine:monero.social , false statements so far
18:07:16
articmine:
What false statements
18:07:44
jeffro256:
@articmine: I think @datahoarder:monero.social is saying that with the "delayed" scaling, you can soft fork away the fast scaling before it takes effect
18:07:50
jberman:
@articmine: No one feels overwhelmed for starters. We are making progress
18:07:51
datahoarder:
@articmine: I mean "limited", not added in. If fast scaling is seen as still bad then, it can be "patched"
18:08:27
articmine:
@jberman: I know you are
18:08:52
articmine:
But are the timelines reasonable?
18:09:16
jberman:
What timelines? The prior timeline estimates?
18:09:37
preland:
@articmine: To make sure we are all on the same page, what is the current timeline, as I've heard it thrown around a ton, but nothing from core or anyone in the know
18:10:22
rucknium:
IMHO, the poor performance of the node was already revealed during last year's mainnet spam and the first stressnet last year. It is only now that more dev effort has been applied to the problems.
18:10:59
articmine:
My point is that when is being proposed is to throttle scaling in an attempt to mitigate code vulnerabilities
18:11:01
jeffro256:
It's been a while since (IMO since the divisors kink) we've had a real aligning about timelines
18:12:42
preland:
I think the last estimate I heard was Q1 '26, which seems too early
18:12:49
jberman:
@articmine: Ack, heard on this point
18:12:51
rucknium:
How important is it to discuss timelines now?
18:13:40
jeffro256:
I want to get a code audit for the carrot_core lib ASAP. FCMP++ Rust code already has most of the reviews it needs AFAIK. Then I think the FCMP++ integration code on the daemon side would be worth auditing. That can be done in parallel of carrot_core. We could modify hard fork table then?
18:14:02
jeffro256:
Then HF activation is 6 months after that release
18:14:30
sgp_:
@jeffro256:monero.social let me know if you want help for the carrot_core audit(s)
18:14:39
ofrnxmr:
dont we hard fork testnet first, potentially stagenet as well to give some time for ecosystem to update
18:15:13
ofrnxmr:
arbitrary, but i dont think it has to be 6 months in advance
18:15:25
jeffro256:
Yeah, that's fair. Testnet and stagenet don't need a 6month lead time tho
18:15:41
articmine:
I mean if my proposal with a 500000 byte minimum penalty free zone is not enough to address the vulnerability concerns then we have some very serious issues that have nothing to with scaling
18:16:17
jberman:
personally I'd like to complete the alpha stressnet (reach a point where alpha stressnet is running smooth under reasonable conditions), ideally within the next 4 weeks. and then reopen a conversation on target dates
18:17:19
jeffro256:
That's fair, and can also be done in parallel to integration / crypto audits
18:17:29
rucknium:
Even with node code with zero inefficient "overhead", the proposed FCMP allowed block sizes would stress hardware. With 16MB blocks, which are allowed with quick scaling in @articmine:monero.social 's proposal AFAIK, you can get 2466 1in/2out txs into a block, which would require 93 seconds on a single thread to verify. Accord [... too long, see https://mrelay.p2pool.observer/e/v7eH18wKbFd4dkxM ]
18:17:44
jeffro256:
AFAICT, the remaining changes to be made to the stressnet wouldn't involve much FCMP++/Carrot crypto-specific changes
18:18:01
rucknium:
If an adversary tries to pack blocks, they can slow down verification further by selecting slow tx types.
18:18:10
ofrnxmr:
aside from the dropping connections, i think its running pretty well. Would like to see how mobile wallets fare with the tx volume. Dont want a zcash situation where wallets cant keep up
18:18:21
jberman:
@rucknium: that proposal doesn't limit to 16mb blocks
18:18:27
sgp_:
I'm more concerned with the max block sizes (and permitted growth) than the initial penalty free zone
18:19:07
jeffro256:
@ofrnxmr: Wallets really shouldn't be affected much if you assume daemons are working okay since they deal in pruned transactions, not full transactions
18:19:50
DataHoarder:
also saw last week, that a 128-in FCMP++ input is already larger than the block weight at minimum, which prevents these from being included unless block is grown (I guess if they pay more fees it could be worth it?)
18:20:09
ofrnxmr:
DataHoarder: I think this is due to incorrrecrly reported weight
18:20:20
articmine:
Then use the current scaling parameters with a 500000 byte penalty free zone and see what you get.
18:20:20
articmine:
It is far easier to test the stressnet with the current parameters than with my proposal that delays the scaling by over 2 months
18:20:21
ofrnxmr:
tx reports 132kb, but weight 700kb
18:20:52
DataHoarder:
yeah, then we have "Revisit FCMP++ transaction weight function" as part of this topic :) (which afaik agreement was byte size = weight?)
18:20:56
jberman:
feel free to correct this math @articmine:monero.social, but if I'm calculating correctly the latest proposal allows blocks to grow to 611mb within 1 year 1000*(2^(365/100,000/720/2)
18:20:58
articmine:
@sgp_: The lot term has va very negative impact on blockchain surveillance
18:21:13
articmine:
Long term
18:21:22
articmine:
I understand that.
18:21:47
articmine:
This is a totally different and very serious issue
18:22:26
jeffro256:
@ofrnxmr: block size is limited by tx weight, not tx byte size. So it would be limited under the current stressnet weight rules, but that is being changed for the next iteration of the stressnet
18:22:31
articmine:
My proposal can destroy blockchain surveillance
18:22:50
jeffro256:
https://github.com/seraphis-migration/monero/pull/232
18:23:11
jeffro256:
Under this PR, its weight is approximately equal to its byte size
18:23:26
ofrnxmr:
@jeffro256: Right, when i say incorrectly reported weight, i mean that the "weight roughly = to byte size" isnt in yet
18:23:27
rucknium:
@jberman: @jberman:monero.social: Is it 16MB blocks in the short term (100,000 blocks median)?
18:23:28
jberman:
@articmine: 611mb blocks would destroy Monero
18:23:51
ofrnxmr:
@jberman: 100.01mb blocks would destroy monero :P
18:23:53
articmine:
How?
18:24:01
jberman:
@ofrnxmr: lol
18:24:42
jberman:
@articmine: you would need a data center to run a full node
18:24:51
jeffro256:
@articmine: Nodes would not be able to sync / propagate faster than blocks are created. Storage requirements may become infeasible for particpants
18:25:36
preland:
@jeffro256: "storage is free"
18:25:36
preland:
yeah, 611mb blocks would be an issue imo
18:25:47
ofrnxmr:
even storage r/w speeds would be crippled by receiving a 600mb block
18:25:52
sgp_:
I think we should join together and submit a counterproposal. It's fine my initial idea isn't getting traction, but we should have another actual option that's considered good by multiple people instead of talking in circles on this one imho
18:26:23
articmine:
@sgp_: I will be blunt. Conflict of interest
18:26:57
jeffro256:
What is the conflict of interest of discussing new scaling ideas?
18:27:29
rucknium:
@sgp_:monero.social: I don't know why you decided to start a blockchain surveillance firm. Baffling decision that will follow you forever.
18:28:00
ArticMine:
https://www.naxo.com/faqs
18:28:23
preland:
@rucknium: have to second this lol; fireice_uk keeps giving me grief in the buttcoin discord server because of it xD
18:28:39
ArticMine:
Blockchain survelliance simple does ntot scale
18:29:12
jberman:
I think there is some general agreement short-term / medium-term larger blocks is ok, and general agreement besides @articmine:monero.social that consensus allowing blocks in the hundreds of mb's within 1 year is not (ignoring the 100mb serialization limit)
18:29:28
jberman:
packet size limit*
18:29:29
ArticMine:
It is at least apparent conflict of interest as defined by the government of canada
18:30:07
jberman:
unless other people think blocks in the hundreds of mb's is ok?
18:30:11
boog900:
ArticMine: We cant attract users by promising privacy if we get enough users.
18:30:22
ArticMine:
This is totaly separate from the issue of whethre Monero can handel certain trasnaction rates
18:30:47
boog900:
Why not just used one of the many other coins and just try get their coin more users
18:30:49
preland:
@jberman: I'd say this is a fair summary, though if anyone disagrees they should state it, because as it stands it'll be hard for anyone in the future to look back at this and come to a better conclusion
18:31:23
ofrnxmr:
I havr a 1tb data limit on my vps and my home network
18:33:22
articmine:
We need t make the necessary changes to allow Monero to be used
18:33:41
rucknium:
Is there a workable compromise to have hard fork scaling rules to allow fast scaling, but soft-fork rules has slow scaling? So the soft fork can be lifted or relaxed when it makes sense to do so?
18:34:13
articmine:
If a 100x increase in usage breaks Monero we have some very serious problems
18:34:25
boog900:
Removing soft fork rules is a HF AFAIK
18:34:50
articmine:
@boog900: I have to agree with this
18:34:55
datahoarder:
@rucknium: it can be a continuous function (up to some sanity limits) that can be slowed/stopped via soft fork, but that way it's always "improving" faster at a defined rate, not specifically linear
18:35:04
rucknium:
Why would that be true? Miners just agree "after this block, the rules are relaxed"?
18:35:24
ofrnxmr:
@rucknium: some miners will reject the blocks
18:35:24
datahoarder:
@rucknium: someone could have not upgraded. suddenly, chain split
18:35:31
ofrnxmr:
Some nodes*
18:35:33
articmine:
In Bitcoin they tried this and it failed in 2013
18:35:34
preland:
@rucknium: I like this idea on a basic level; the hardfork adds the switch, and soft forks are used to turn it from one to the other, though I agree that it isn't without critique
18:35:36
boog900:
A soft fork is making rules tighter hard fork is making them looser
18:35:41
datahoarder:
you can always make things stricter, not broader, with softforks.
18:36:12
articmine:
@boog900: It can work. We have to be very careful
18:37:39
articmine:
I must say that I am glad my hard line on scaling is exposing some serious problems
18:38:13
rucknium:
IIRC, Bitcoin Unlimited has this idea to let the bitcoin block size be unlimited, but allow miners to agree on a (short-term) limit. And miners would want that since propagation delays would increase their blocks' risk of being orphaned.
18:38:31
jeffro256:
If we assume that we must hard fork in the future for either A) PQ crypto, or B) recursive ZK proofs, C) out-of-band proving (e.g. sheilded CSV), D) plain old FCMP efficiency improvements, or E) something else, we will have another opportunity in the future to adjust scaling parameters in the scaling-maximization direction kno [... too long, see https://mrelay.p2pool.observer/e/xrfU18wKaVY2X3ZL ]
18:40:02
jeffro256:
I'm not convinved that increasing scaling parameters is do or not right now when there are popular proposals for much more radical changes in the future
18:40:03
datahoarder:
@jeffro256: that ossification/untenable part is maybe why having a future date where it becomes enabled by default (unless something is done) might work to get things moving
18:40:56
jeffro256:
Yeah, I don't dislike that idea
18:41:17
boog900:
the difficulty bomb 2
18:41:56
datahoarder:
@boog900: "past us build a bomb so we don't procrastinate now"
18:42:25
jberman:
I'm not a proponent of disparate scaling algos / a future bomb
18:42:49
rucknium:
Here is info on the Bitcoin Unlimited Excessive Block Size config parameter: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4
18:42:55
articmine:
I mean a soft fork cap on the block size cout be overridden by a 51% of the hashrate
18:43:11
datahoarder:
yeah, maybe difficulty bomb is a bad example, but something reasonable that all agree on ~2 years or whatever is set (and is not catastrophic)
18:43:25
ofrnxmr:
@rucknium: I think the fluffy block fix, fixes the broadcast delay
18:43:31
jeffro256:
@articmine: Not really, unless you want 49% of the Monero ecosystem to split
18:43:46
sgp_:
The problem is that the proposal allows catastrophic things. That's the core problem
18:43:50
boog900:
yeah I would be ok with a future block size bomb, although I see most likely outcome that it is just delayed and we stick with the more security focused scaling algo
18:44:00
datahoarder:
@ofrnxmr: with large tx pools that are segregated (not everyone has all txs) you still end up with large transfer of txs to get blocks accepted
18:44:17
jberman:
(I have to step away in 7 mins unfortunately)
18:44:24
jeffro256:
In reality, even with a soft fork, you need a supermajority to not cause catastrophic damage to the economy built around your network. You want opposing the soft fork to be so disastrous that no one does it
18:44:56
ofrnxmr:
But what if you're qubic and want to do it for fun?
18:45:05
articmine:
With all due respect the danger of ossification is real
18:45:08
preland:
@ofrnxmr: beat me to it lol
18:45:30
datahoarder:
@jeffro256: reverse block size scaling? where blocks become smaller until it's catastrophic even without 100x growth
18:45:32
articmine:
Remember what Satoshi said in 2010
18:46:15
articmine:
I mean we can leave the parameters as they are
18:46:41
boog900:
I think you are the only one that thinks current scaling is anywhere close to safe
18:47:30
rucknium:
@boog900: Is this true? Anyone want to say that current scaling is anywhere close to safe?
18:47:46
preland:
@rucknium: Define safe in this context
18:47:54
datahoarder:
@ofrnxmr: the only reason qubic didn't do it with their tx spamming on the side was they had their own dumb technical limitation to 896 byte block header size, so they could only attach like ~20 txs per block tops
18:48:05
jeffro256:
I like the current scaling TBF
18:48:19
boog900:
@preland: allows us to react fast enough to someone producing max size blocks to prevent nodes falling out of consensus
18:48:23
rucknium:
@preland:monero.social: You can define it as you like. Qualify your statement.
18:48:34
ofrnxmr:
@jeffro256: Getting to 40mb in under 48hrs? Without max fees?
18:49:11
ofrnxmr:
I think the current scaling shouldnt allow such growth speeds with just lvl 3 fees. Its almost free
18:49:16
datahoarder:
is it capped to max size blocks? or is it unbounded? if it can reach 100 MB net. limit within one or two weeks, that's catastrophic. Just one or two MRL meetings to talk!
18:49:24
jeffro256:
@boog900: I think that it does do a decent job at it. Yes, you can spam, but you have to stay very very consistent and continually burn XMR to increase block size
18:49:44
jberman:
I intend to make a more detailed comment responding to @articmine:monero.social 's latest comment, but here are some things to think about in the mean time:
18:49:48
boog900:
@jeffro256: You just need mining power
18:49:58
jberman:
* The most significant parameter in the proposal/algo is the long term median max growth rate of 2x
18:50:09
jberman:
* This value is what determines how large blocks can grow to over the long term
18:50:10
ofrnxmr:
@jeffro256: you dont have to spend very much, and if you control a mining pool, you can earn your losses back by forcing othera to outbid you
18:50:28
jberman:
* Reducing that back to 1.7x and keeping everything else the same, max block size w/in 1 year = 260mb
18:50:29
rucknium:
IMHO, it doesn't make sense to have scaling that would require "manual" intervention. Just set the scaling parameters correctly from the start.
18:50:32
jberman:
* Reducing back to 1.4x and keeping everything else the same, 94mb
18:50:35
jeffro256:
@boog900: Okay fair, but you're still paying an XMR opportunity cost
18:50:37
boog900:
you can pad blocks with useless data to make them huge, and or you can set txs to 0 fee
18:50:39
jberman:
The current scaling algo in consensus today allows for blocks to grow to 244mb
18:50:51
datahoarder:
@ofrnxmr: and IF selfish, can attempt to remove light blocks
18:51:07
ofrnxmr:
I have 200xmr on stressnet and can get blocks to 14mb in 720 blocks and atill have ~200xmr
18:51:13
articmine:
We must not rely on a future hard fork
18:51:16
boog900:
@jeffro256: we have seen an entity recently reduce their XMR reward just for some advertising
18:51:26
boog900:
what about an entity who wants us dead?
18:51:44
jeffro256:
@jberman: what causes the 244mb cap?
18:51:51
ofrnxmr:
opportunity cost like $1500
18:52:52
jberman:
@jeffro256: check this spreadsheet for the calculations: https://github.com/monero-project/research-lab/issues/70#issuecomment-1027806393
18:53:07
jberman:
that shows which params affect the calculation
18:53:13
preland:
@ofrnxmr: what if we publically offered like $30 in xmr to an individual who could increase the stressnet blocksize the most
18:55:15
boog900:
@jeffro256: 2 days of mining is 864 XMR
18:55:18
spackle:
Another thing that would have serious impact would be extending the long term median window.
18:55:33
jeffro256:
@boog900: An entity who wanted to cripple Monero would probably go for a 0-tx block strategy IMHO. It's more resource-efficient
18:55:43
datahoarder:
@preland: this was being talked about in #monero-research-lounge:monero.social :)
18:55:46
jberman:
@spackle: that's true
18:56:05
boog900:
@jeffro256: that would only pause us, nodes falling out of consensus allows double spends
18:56:38
ofrnxmr:
@jeffro256: 0tx 51% attack is harder than havinf 51/100 blocks at max size til you pass setialization or packet limits
18:56:43
jberman:
extending the long term median window actually has a very significant impact
18:56:45
ofrnxmr:
At which point the chain is cooked
18:57:23
jeffro256:
@boog900: Fair
18:57:30
preland:
@jberman: Probably a dumb question, but how long would it take roundabouts for the size to drop back down to a sane level after reaching the 244 peak
18:57:37
ofrnxmr:
@ofrnxmr: And this only takes like 2, maybe 3 days?
18:58:16
ofrnxmr:
@preland: Short term = 51 blocks
18:58:18
boog900:
current mainent would last way less than 2 days
18:58:27
datahoarder:
@jberman: Existing miners can pad blocks right now up to that size for "free", fill the rest with legit txs, without getting into penalty zone (point being to always be at the limit of penalty zone), and extend the median free
18:58:31
preland:
@ofrnxmr: oh right
18:59:26
jberman:
have to step away, sorry :/
19:00:35
rucknium:
We are almost at 2 hours. IMHO, discussion participants need to see if a compromise is possible and what that compromise would look like. Be creative. If a compromise can't be reached, then that's unfortunate, but sometimes it's like that.
19:01:03
articmine:
I was also called out
19:02:16
gingeropolous:
i think extending the long term median window should be investigated
19:02:55
gingeropolous:
this forces the market, or the attacker, to really justify the blocksize increase
19:02:58
articmine:
A couple of things
19:02:58
articmine:
1) If the spam is not maintained the short term median resets at 50 blocks.
19:03:27
ofrnxmr:
@gingeropolous: How does this do anything to stop the short term 50mb blocks?
19:03:31
articmine:
2) The rate of growth and decline of the long term median is the same
19:04:52
articmine:
The whole idea behind the long term t was to kill the spam. This is why a ZCash like spam attack I Monero does not work
19:06:35
articmine:
So we limit the growth of the short term median to 16x and the block size also to 16x of the long term median
19:07:20
articmine:
This t what my proposal does
19:08:46
gingeropolous:
and what do those numbers give us in worse case scenario. 100MB blocks in 2 days? 100MB blocks in 1 year?
19:08:47
articmine:
Now that the conflict of interest has been exposed, maybe calmer heads will prevail and we can work on consensus
19:08:55
rucknium:
6. FCMP alpha stressnet (https://monero.town/post/6763165).
19:09:23
ofrnxmr:
1.5 hitting some small delays due to nodes dropping all connections
19:10:03
ofrnxmr:
If note, there were also 2 or 3 reports from people on 1.4 also dropping connections, and some "invalid block" logs. So maybe coincidence?
19:10:09
jeffro256:
Are you running v1.5?
19:10:16
ofrnxmr:
I am
19:10:21
ofrnxmr:
No issues on my end
19:10:41
DataHoarder:
ofrnxmr: if "invalid block" logs are around that specific invalid miner tx, that's an old issue
19:10:56
ofrnxmr:
I dont think it was that one
19:11:03
gingeropolous:
yeah i got a node fully syncd on 1.5
19:11:04
jeffro256:
Yes, there's still the issues of connections dropping
19:11:57
jeffro256:
Probably a better long term approach for debugging would be to have the nodes send a reason for dropping beforehand
19:13:52
rucknium:
Opt-in and/or stressnet/testnet only? Could a mainnet adversary find that info useful?
19:14:01
ofrnxmr:
Otherwise, things seem to be pretty smooth. I have some 0 value amounts in wallet (probably result of sweeps) that i think might be slowing down wallet sync.
19:14:46
ofrnxmr:
@rucknium: The reasons for dropping connections are usually logged on lvl 2 aiui
19:14:50
DataHoarder:
rucknium: it could be used to detect versions, if behavior changes, or find details about the "internal" state to find propagation
19:15:00
DataHoarder:
if you mean giving the reason to other peers
19:15:14
jeffro256:
@rucknium: Yeah def opt-in only. Since we use TCP connections, sending a message and then verifying it reached the destination requires communication from the other end which is a DoS vector.
19:15:26
DataHoarder:
+1 for it being opt-in, though. that way operators can choose
19:16:26
ofrnxmr:
https://matrix.to/#/!sgiUzbrYPvMAvwQKTG:monero.social/$D1N9WP_TIfgtrYVGN---YXQeobf_ZcFP7asXRiZ9cYA?via=monero.social&via=matrix.org&via=nope.chat datahoarder - different block
19:16:42
DataHoarder:
(also, it should be not be freeform, or it may be abused to display messages on other nodes with high loglevel.)
19:17:21
DataHoarder:
not as bad as this, but similar https://github.com/spesmilo/electrum/issues/4968
19:17:52
rucknium:
Anything more on stressnet?
19:18:39
rucknium:
7. Post-FCMP scaling concepts.
19:19:18
preland:
(copy paste inbound)
19:19:24
preland:
Thank you. There are two ideas that I have been looking into in terms of scalability. The first is a more ambitious “federation”-style approach to scalability.
19:19:24
preland:
This would have the blockchain and network autonomously split into smaller sub-networks once a certain threshold has been met. The result would be an effectively infinitely scalable network. The main challenges I’ve found would be ensuring that two sub-networks can trivially prove that each other have been following proper p [... too long, see https://mrelay.p2pool.observer/e/yJrq2MwKYlUtNm5R ]
19:19:24
preland:
I’ll continue looking into that, but for now I’m mainly focused on the other idea I’ve been looking into, which is adopting a quorum consensus model similar to how Qubic’s operates (with significant modifications made to its implementation). This would allow for transaction scaling to be increased to an incredib[... more lines follow, see https://mrelay.p2pool.observer/e/yJrq2MwKYlUtNm5R ]
19:20:13
rucknium:
Is the first one similar to sharding?
19:20:20
preland:
Yes
19:21:11
datahoarder:
@preland: Note Qubic's model depend on a centralized arbitrator to kick computors out, which they have done a few times and one last week. No specific reason is needed, but they claim to have found collusion
19:21:37
datahoarder:
The comparison with their model is maybe not desired, as it's, mainly centralized across several layers
19:21:39
preland:
@datahoarder: Correct; this is one (of many) things that have been switched out
19:22:13
preland:
@datahoarder: It's what inspired my initial look into it, which is why I mention it, even if it isn't entirely deserved tbh
19:23:04
datahoarder:
@preland: They'll use any mention for marketing :)
19:23:04
datahoarder:
On that topic, they recently changed how all of that works regarding txs, and changed how fast they tick, and changed it back again, and later changed how txs work again.
19:23:33
ofrnxmr:
Isnt the former similar to how pruning currently works
19:24:09
ofrnxmr:
Except, instead of infinite, there are 8 different shards (stripes)
19:24:43
rucknium:
A pruned 1in/2out FCMP tx is about the size of a 1in/2out bitcoin tx, FWIW. Learn to love pruning.
19:25:01
preland:
@ofrnxmr: not exactly; each subnetwork would be a distinct network in and of itself, and the networks would be able to interact with each other through some sort of transfering
19:25:24
preland:
the main upside to it wouldn't be in storage per se, but in tps scaling
19:25:31
rucknium:
Or don't. You don't have to love pruning if you don't want to. But it's very useful (and the default when you launch a Monero node from the GUI wallet now).
19:25:58
datahoarder:
if I understand, to "prune" a subnetwork you'd have to aggregate its state in a proof -> to then join the others and "close" aka prune it?
19:26:35
preland:
@datahoarder: From what I've seen so far that seems to be the case
19:26:42
datahoarder:
all that would be left of that subnetwork would be that proof, which participants can create new transactions against
19:27:34
datahoarder:
in (again Qubic) case their "pruning" is due to being a balance based system. So they just aggregate current state, delete everything else, and also, delete some inactive (but with active dust) and zero-balance accounts
19:27:45
rucknium:
https://mrelay.p2pool.observer/m/monero.social/FpALSKRIlOlUVUhFgNWuHkRi.ods (carrot_fcmp_pruned_tx_size.ods)
19:28:31
rucknium:
^ Pruned FCMP tx size table, created by @jeffro256:monero.social 🧡
19:28:57
datahoarder:
this is how they claim to be "more private than Monero", too bad anyone can just archive the network :). How does this work for an UTXO based system, without clear spend tied to each UTXO? Using an accumulator (a-la UTREEXO?)
19:29:18
preland:
@datahoarder: The equivalent pruning would be using zk rollups
19:29:50
rucknium:
It was posted in the #no-wallet-left-behind:monero.social room: https://matrix.to/#/!PAAeACCTzofUENRcqJ:monero.social/$1QQzyPyFKw0XrNZH3p0t-a4Wgxi4EhstRKq3ir6tJqw?via=monero.social&via=matrix.org&via=tchncs.de
19:30:48
preland:
As you pointed out, the comparison to Qubic is not exactly an apt one admittedly; there are a number of attributes and "quirks" in Qubic that cannot be tolerated whatsoever in Monero, and a number of features that just don't make sense (like UPoW)
19:33:08
articmine:
I have to leave bow
19:33:13
datahoarder:
the lack of decoy indices adds up, it's just a list of key images -> outputs! > <@rucknium> A pruned 1in/2out FCMP tx is about the size of a 1in/2out bitcoin tx, FWIW. Learn to love pruning.
19:33:14
datahoarder:
on that topic, would it make sense to have a V3 tx format, that removes the need to serialize inputs with empty vectors of offsets / input type / amount?
19:33:16
rucknium:
If you are curious about how many pruned nodes you have to have to make sure you have all 8 slices/stripes, I have the numbers and formula in Appendix B here: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-optimal-fee-ring-size.pdf
19:33:23
rucknium:
Code: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/code/pruning-slices-collectors-problem.R
19:33:28
jberman:
I think it's possibly unrelated to anything in v1.5. I have complete logs of the issue on my end and a first look looks like an issue that triggers when the pool actually does exceed the max weight > <@ofrnxmr> If note, there were also 2 or 3 reports from people on 1.4 also dropping connections, and some "invalid block" logs. So maybe coincidence?
19:33:43
jberman:
I haven't had the chance to dig yet
19:35:42
datahoarder:
the overhead for FCMP++ of "unused" data per input is 1 byte for type, 1 byte for amount, 1 byte for len of offsets. so 19 total, 15% overhead per input. ofc, pruned.
19:35:45
ofrnxmr:
@jberman: I pinned a log from 1.4 release with similar issue
19:36:39
ofrnxmr:
@jberman: Yeah. The pool was > 600mb , filled with 128 input txs that couldnt be mined
19:39:18
preland:
I am going to continue looking into this further, as I think that this would be an interesting path for Monero to take once FCMP++ has been implemented and related issues have been addresssed. I'll plan on continuing my work and progress in the https://github.com/preland/xmr-republic-docs repository; if there are any issues of [... too long, see https://mrelay.p2pool.observer/e/j4qz2cwKbmU4N01N ]
19:40:21
rucknium:
Thanks everyone. We can end the meeting here.
19:40:33
ofrnxmr:
ofrn questions:
19:40:34
ofrnxmr:
1. Randomx v2 <- are we hoping to ship this with fcmp hf?
19:40:34
ofrnxmr:
2. Should we increase the default txpool limit by 4x? Also, are we sure eviction works properly? Are txs added back when the txs are re-received from peers?
19:40:34
ofrnxmr:
3. Is 72hrs a sane expiry for valid txs?
19:40:35
preland:
Thank you
19:43:14
datahoarder:
@ofrnxmr: 1. AFAIK the commitment part is done, but not a change in parameters to tweak towards modern hardware
19:45:03
ofrnxmr:
But is this on the todo for fcmp hf? Or not planned? Should it be?
19:49:09
datahoarder:
proposal for v17 https://github.com/monero-project/monero/pull/10038 and https://github.com/monero-project/monero/issues/8827 which is listed under https://github.com/seraphis-migration/monero/issues/53 "RandomX commitments w/double hashing" under "Daemon features"
19:49:40
datahoarder:
that might be nice to see on beta stressnet :)
19:50:14
plowsof:
thanks, i forgot to ask if https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626 would be funded with the FCMP++ research fund? kayabanerve jberman
19:54:15
kayabanerve:matrix.org:
I find the work emsczkp: is proposing interesting, and the rate reasonable.
19:54:15
kayabanerve:matrix.org:
It is not in scope to the existing fcmp++ research fund, thought that is handed over to the mrl upon resolution iirc.
20:10:33
ofrnxmr:
@datahoarder: Thats not v2 thougg
20:11:35
ofrnxmr:
https://github.com/tevador/RandomX/pull/274 datahoarder
20:12:46
DataHoarder:
that's what I mean, "commitment part is done, not change in parameters"
20:13:36
DataHoarder:
about actual v2 parameters, poke sech1 for context :)
20:14:35
jeffro256:
Personally, I think that the commitment portion is the most important
20:14:54
jeffro256:
I am neutral to the other virtual machine changes
21:46:37
spackle:
You set the default median and surge factor to limit the size of the short term blocks, and you set the long term median window to keep that limit in place for a known duration. > <@ofrnxmr> How does this do anything to stop the short term 50mb blocks?
21:47:24
spackle:
In combination, this establishes that no blocks larger than X MB shall be created in the next Y blocks.
21:48:43
spackle:
Which is the clearest and simplest path to giving the scaling design a safety specification, at least as I see it.
21:52:24
spackle:
Rather, that IS the safety specification that exists which should now be brought into alignment with the realities of the software.
21:58:49
articmine:
@spackle: My proposal
21:59:31
articmine:
If you want to stop 50 MB short term blocks
22:00:22
articmine:
How much are t willing to pay for a 50 MB block on mainnet?
22:03:25
spackle:
A steady stream of 50 MB blocks will cripple the network, and should not be produced in the short term at any price IMO.
22:04:35
articmine:
How much do you think it would cost to spam a 50 MB block on mainnet under my proposal at current XMR / USD rates
22:05:51
articmine:
Just one block
22:07:01
articmine:
... and how long will it take?
22:07:46
spackle:
I am not interested in making the price prohibitive, I am interested in prohibiting the condition entirely.
22:07:47
articmine:
Price in USD or XMR
22:08:30
articmine:
@spackle: Then this is the wrong chain for you
22:09:13
articmine:
One needs a chain with a fixed blocksize. That is not the Monero social covenant
22:11:09
spackle:
You misunderstand me, nobody is discussing a long term hard limit on block size. I am discussing short term behavior and safety specification.
22:11:16
spackle:
The difference we are discussing is between putting a price tag on breaking the network, and preventing the network from breaking entirely.
22:11:38
articmine:
Then answer my how long question
22:11:58
spackle:
That is for people to come to consensus on, not for me (or you) to dictate.
22:12:07
articmine:
Define short term because
22:12:51
spackle:
I see short term as the length of time it takes to adjust the long term median, currently 50000 blocks.
22:14:11
articmine:
With my proposal the maximum allowable block starting at 1 MB is 16 MB
22:14:28
articmine:
So problem solved
22:15:21
spackle:
If there is agreement that 16 MB is the correct value. I have not yet seen that happen, and I believe we are waiting for further input from the stressnet at this time.
22:15:42
articmine:
Please read my latest proposal
22:16:18
articmine:
There is a lot of FUD and yes even conflict of interest
22:23:15
spackle:
I have read and understand you proposal. Allow me to restate and clarify my position: The safety specification for the scaling design is that 'no blocks larger than X MB shall be created in the next Y blocks.'
22:23:19
spackle:
Get agreement on the maximum size X, get agreement on the length of time Y, and the job is done.
22:24:13
spackle:
*your proposal
22:24:31
articmine:
X = 16 MB Y = 50000
22:25:16
articmine:
Start ing blocks before the 50000 under 1 MB
22:29:38
spackle:
Yes, those are the numbers you have independently chosen by yourself. My understanding is that we are waiting for further stressnet results before agreeing on these values.
22:32:03
articmine:
I originally had 32 for X and later modified it to 16
22:32:32
spackle:
Again, values you chose yourself without input from testing.
22:32:40
spackle:
Last I heard jberman said he needed to review the 16x cap in totality with the proposal
22:32:52
spackle:
I will wait for others to speak up, I am sure conversation will continue.
22:33:15
articmine:
16 had input from testing
22:35:28
articmine:
As for the 1.7 growth rate for ML it was chosen at the last fork by an individual who has a conflict of interest
22:35:29
spackle:
I don't think so, it was thrown out by one person as a more reasonable option than 32. I did not see hard empirical reasons or consensus backing it.
22:35:30
articmine:
My original proposal at the time was 2
22:35:31
spackle:
I am happy to be proven wrong, and if you would like to list the reasoning or people who had consensus on that value I think that would be helpful.
22:35:42
spackle:
If that is the case, then I would like to see that discussed thoroughly at the next meeting.
22:37:25
articmine:
At the time I worked on issue 70 with Koe. We came to consensus. The fee structure was based upon 2. It was at the last moment that the change was made
22:37:52
articmine:
One can read all of this on issue 70
22:38:22
articmine:
The fee structure is still based upon 2
22:40:00
spackle:
Was any practical testing of the daemon considered in your discussions with Koe?
22:40:36
articmine:
I am talking like 5 years ago
22:40:41
spackle:
What I have seen from the stressnet would indicate that was not the case.
22:40:56
articmine:
@spackle: I agree
22:40:59
spackle:
Indeed, so the scaling was set without empirical feedback. Now is the time for that to happen.
22:41:23
spackle:
Right now we are waiting on feedback, as I understand things.
22:41:43
articmine:
I am actually shocked as to has been revealed in the Stressnet
22:42:51
articmine:
I also don't know when the fatal bugs were introduced
22:43:34
articmine:
What I do know is that the scaling was way more aggressive in 2014
22:43:59
articmine:
No Long term median
22:44:03
articmine:
Just the short term median
22:44:21
spackle:
Also way more disconnected from reality.
22:44:23
articmine:
The long term median was introduced in 2919
22:44:30
articmine:
2019
22:45:38
articmine:
Like I said I am glad we exposed the conflict of interest so we can work on this in a sensible way
22:46:47
articmine:
We got a lot acct in the last meeting
22:46:58
articmine:
accomplished
22:51:22
articmine:
We have to get to the bottom of the bugs, the risk associated with them, how long they will take to fix, what resources are needed etc.
22:51:22
articmine:
Sorry I hate phones and their useless AI
22:52:37
articmine:
Then we can connect with reality
22:55:34
articmine:
We also given the seriousness of the situation need to make sure that the feedback is not influenced by conflicts of interest
22:57:26
spackle:
My opinion is that consensus is reached when informed persons can affirmatively state:
22:57:26
spackle:
1.) YES, the network can handle a steady stream of blocks that are size X.
22:57:26
spackle:
2.) YES, we can respond, and adapt the network, to handle what may arise in the future over time Y.
22:58:09
spackle:
Others have discussed longer term values, such as what the block size may become in a year. I leave it to them to make their case.
22:58:31
articmine:
@spackle: I agree
22:59:16
articmine:
@spackle: This is where the cost of spam becomes paramount
23:02:51
spackle:
Then indeed we are in agreement, including that X=16MB and Y=50000 blocks are not yet settled values. I have yet to see anyone affirm those statements with those values.
23:03:43
articmine:
One important aspect of testnet is that the current. short term aggressive scaling should be used with the FCMP++ sizes and verification times.
23:03:43
articmine:
Otherwise it will take months if not years to spam up the testnet, with my proposal
23:04:56
articmine:
This is by design. I deliberately designed it to frustrate and increase the cost of spam