that was at height 3471523

<r​ucknium:monero.social> ofrnxmr: Done. Alt chains with more than one block might still omit too many blocks from display. Hard to know how it would look without an actual 2+ block alt chain to test, unless I try to inject some testing data.

<o​frnxmr:monero.social> Do we know if they are brosdcasting their second block at the same time as the first?

<o​frnxmr:monero.social> Looks like theyve always been the one to mine on top of their alt chain

<r​ucknium:monero.social> ofrnxmr: I think so. Here's what I see in my txpool archive data from a well-connected node:

<r​ucknium:monero.social> ```txt

<r​ucknium:monero.social> block_hash prev_block_hash block_height block_timestamp block_receive_time block_receive_time_UTC

<r​ucknium:monero.social> <char> <char> <num> <num> <int> <char>

<r​ucknium:monero.social> 1: e6d074e0 770242fe 3471456 1754429537 1754429547 2025-08-05 21:32:27

<r​ucknium:monero.social> 2: a3673a1d aa0ca193 3471457 1754429550 1754429558 2025-08-05 21:32:38

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> It polls `monerod` about once per second (longer than a second if the txpool is very full and parsing takes longer).

<r​ucknium:monero.social> If there were more than a second separation of broadcast of `aa0ca193` and `a37ald`, then the archiver should have recorded `aa0ca193` as a separate record instead of just as the `prev_block_hash` of `a3673a1d`. I think.

<r​ucknium:monero.social> I instructed the archiver to require uniqueness on `block_hash`, not `block_height` in its database: github.com/Rucknium/xmrpeers/blob/main/R/txpool.R#L46-L54

<r​ucknium:monero.social> Run your own txpool archiver: rucknium.github.io/xmrpeers/reference/index.html

<b​oog900:monero.social> did you get those blocks by syncing or did they get sent to you?

<b​oog900:monero.social> If you have the logs

<r​ucknium:monero.social> I have default log level on this node. What log level would be necessary to capture that info?

<b​oog900:monero.social> I think it should show on default, you should get the message about being so many blocks behind and that you are syncing

<b​oog900:monero.social> Otherwise it would just show as a reorg without that bit before I think

<r​ucknium:monero.social> ```txt

<r​ucknium:monero.social> 2025-08-05 21:32:37.636 I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 3471456

<r​ucknium:monero.social> 2025-08-05 21:32:37.636 I id: <aa0ca19328f66ab0f1bb7d3f5decf0e7ea07c6406b375e9928a5491e0bc5467d>

<r​ucknium:monero.social> 2025-08-05 21:32:37.636 I PoW: <69b4e16b0cd69c6b66411be6eba47c0b8d3fd84bfd78be33c7fb8b0000000000>

<r​ucknium:monero.social> 2025-08-05 21:32:37.636 I difficulty: 611843177366

<r​ucknium:monero.social> 2025-08-05 21:32:37.677 I ###### REORGANIZE on height: 3471456 of 3471456 with cum_difficulty 493270429806485498

<r​ucknium:monero.social> 2025-08-05 21:32:37.677 I alternative blockchain size: 2 with cum_difficulty 493271042868135659

<r​ucknium:monero.social> 2025-08-05 21:32:37.771 I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 3471456

<r​ucknium:monero.social> 2025-08-05 21:32:37.771 I id: <e6d074e07616a4b891e8ce855897e8be869e279b59515431ff5f173fd4784c93>

<r​ucknium:monero.social> 2025-08-05 21:32:37.771 I PoW: <42393ff85051782db458f15d1a893c2eb0e4eb4cb626d36dcf1e080000000000>

<r​ucknium:monero.social> 2025-08-05 21:32:37.771 I difficulty: 611843177366

<r​ucknium:monero.social> ^ This is what I have

<b​oog900:monero.social> Nothing before that about being behind?

<r​ucknium:monero.social> No.

<r​ucknium:monero.social> About 135 inbound and 12 outbound connections.

<b​oog900:monero.social> That last line shows you synced the blocks they were not sent to you in a broadcast: github.com/monero-project/monero/bl…yptonote_protocol_handler.inl#L1619

<r​ucknium:monero.social> I am definitely seeing more of the `Synced X/X` messages in the last 24 hours, in the log, than usual.

<b​oog900:monero.social> Shooting themselves in the foot with the slow block propagation method then

<a​rticmine:monero.social> I may be a few minutes late to the meeting today, since I have an appointment just before.

<r​ucknium:monero.social> MRL meeting in this room in two hours.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1250

<r​ucknium:monero.social> 1) Greetings

<a​rticmine:monero.social> Hi

<s​gp_:monero.social> Hello

<k​ayabanerve:matrix.org> 👋

Hello

<j​berman:monero.social> *waves*

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: Launched moneroconsensus.info , which visualizes orphaned blocks and alternative chains, which would tend to appear with greater frequency if a mining pool with a large hashpower share used a selfish mining strategy. Working on adding to the web app by implementing trustless hashpower estimation based on Ozisik, Bissias, & Levine (2017) "Estimation of Miner Hash Rates<clipped message

<r​ucknium:monero.social> and Consensus on Blockchains" arxiv.org/abs/1707.00082

<v​tnerd:monero.social> Me: lwsf and monero_c are working, finally

<j​effro256:monero.social> Howdy

<v​tnerd:monero.social> Also looking at some other bugs

<s​gp_:monero.social> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) thanks for setting up that site

<j​berman:monero.social> me (repeating from the NWLB meeting Monday): ofrnxmr has been sharing solid bug reports on the FCMP++ integration, been working through them, submit a PR to get rid of initial block hash download on wallet restore from wallet2 + fix deep reorg handling + a slight refactor to wallet2 refresh + address issues ofrn/others have shared. Also got and shared current FCMP++ tx size and ve<clipped message>

<j​berman:monero.social> rification time figures here: seraphis-migration/monero #44#issuecomment-3150754862

<a​rticmine:monero.social> I did a preliminary review on the FCMP++ transaction sizes and verification times. Will be calculating actual fees.

<a​rticmine:monero.social> Have completed the sanity median change. It can work with minimal wallet impact.

<a​rticmine:monero.social> The verification time can be taken care of with the multiple minimum node relay level based on size alone

<a​rticmine:monero.social> There is no case for weights outside of the non consensus changes in the membership proofs

<a​rticmine:monero.social> Otherwise just use actual size

<r​ucknium:monero.social> 3) [Proposed Veridise reviews of Helioselene](gist.github.com/SamsungGalaxyPlayer/981e8281b91b49901f516eec54ee3c4d).

<g​ingeropolous:monero.social> still working on monerosim. focusing on distributed block production

<s​gp_:monero.social> Hey all, we received a quote to review the helioselene library that won the recent contest

<s​gp_:monero.social> and a similar quote to provide additional documentation to explain why the helios/selene curve selection is safe in this application

<s​gp_:monero.social> the details are in the gist, and I am here to answer any questions

<s​gp_:monero.social> I believe that Veridise is especially skilled for the library project. Instead of just a review (which they will also do), they will do formal verification

<s​gp_:monero.social> for the curve selection, I believe that they are skilled, though others are skilled for that as well. I checked with a few others and they don't have favorable availability

<k​ayabanerve:matrix.org> This is modified w.r.t. other low hanging fruit and with an optimized impl of the non-optimized binary GCD. It isn't scoped to include any impl of the optimized GCD nor Rafael's BY inversion at this time. IMO, ideally we'd do the second impl properly, fairly compare the second and third, then move forward, but that'd take me three work days and I do not have the bandwidth. That's <clipped message

<k​ayabanerve:matrix.org> why, despite a slower than optimal inversion discussion, we're still discussing moving forward now (as I synced with jberman and jeffro a week ago, though jeffro didn't directly give a reply).

<k​ayabanerve:matrix.org> For curve selection, I do like Veridise but not so much I would say no to other competent candidates. Expanding a bit,

<k​ayabanerve:matrix.org> tevador proposed Helios/Selene. I verified the choice back in the day.

<k​ayabanerve:matrix.org> We're here now, with this optimized impl.

<k​ayabanerve:matrix.org> More efficient curve choices are possible. We have a 127-bit Crandall constant, 128-bit when 256-bit aligned. I personally believe a 127-bit constant (when aligned) could be marginally more efficient, and a 104-bit constant would be *notably faster* on certain architectures.

<k​ayabanerve:matrix.org> The contest revealed some of this insight, for clarity on timelinem

<k​ayabanerve:matrix.org> But more efficient curves will take longer to find and Helios/Selene was the best choice prior. I don't find it necessary nor reasonable to start a new hunt at this time.

<k​ayabanerve:matrix.org> So we should get external review of the choice of curve, to tie everything up in a nice bow, and that's the second quote from Veridise.

<r​ucknium:monero.social> Those choices would be baked into consensus, right?

<k​ayabanerve:matrix.org> But also, Helios/Selene is embedded entirely in the FCMP and can be trivially replaced in a new HF.

<r​ucknium:monero.social> After the hard fork

<k​ayabanerve:matrix.org> Impl isn't in consensus. Curve choice is. You can skip validating FCMP proofs to avoid requiring Helios/Selene. It has no other contamination.

<s​gp_:monero.social> I think the ideal time to hunt for one would have been before the contest. Which is hard because the contest revealed some of these possibilities more clearly. I think helios/selene does the job, and swapping it out now would cause more hard (delay) than benefit

<k​ayabanerve:matrix.org> It's not like outputs will now be on Helios or so.

<k​ayabanerve:matrix.org> It really is just like if we HFd to a more efficient membership proof, to change the curve

<s​gp_:monero.social> *harm not hard

<k​ayabanerve:matrix.org> *caveats incurred by the fact we're baking the tree root into the header AFAIK, but eh, it's all fine

<k​ayabanerve:matrix.org> Yeah. It's optimally a few percent faster, but an extra month of delay.

<k​ayabanerve:matrix.org> I'm presenting everything on the table, even when the reasons to delay are bade choices to follow up on.

<j​berman:monero.social> I'm a definite +1 on this proposal as is, looks great to me

<r​ucknium:monero.social> A few percentage points is not anything to go chasing after at this stage IMHO. Thanks for the info, though.

<j​berman:monero.social> Separately I've been thinking about opening bounties as incentive for research exploration for tasks like searching for a potentially more optimal curve, so it wouldn't need to hold back anything on timeline front, and if someone finds something that demonstrates a significant perf boost, then we can decide to potentially proceed with it then

Astonishing that they will *formal* verification of code

<s​gp_:monero.social> rbrunner, see their last project here where they did something similar magicgrants.org/2025/08/05/Veridise-Gadgets-Circuit

<j​berman:monero.social> Tasks like searching for a more optimal curve, optimizing prove(), and identifying and/or implementing further optimizations to helioselene

<k​ayabanerve:matrix.org> It's Veridise's field of expertise. They'll formally verify the algorithm, not the x86 assembly, though.

<k​ayabanerve:matrix.org> It's human review, and faith in compilers compiling, that will apply that result to our library.

<r​ucknium:monero.social> plowsof has disallowed research bounties on bounties.monero.social

<k​ayabanerve:matrix.org> I actually don't think we should look for a new curve and believe we should halt future ECC development, fite me :C

<k​ayabanerve:matrix.org> But I'm for people making CCSs for faster impls

sgp: Thanks, interesting

<k​ayabanerve:matrix.org> They actually FOSSd their translator tool. Now any circuit on the framework I built can be entered into their tool, Picus.

<s​gp_:monero.social> rbrunner definitely give their report for that a read; they go into a lot of detail about how the translated it

<r​ucknium:monero.social> This two-part Helioselene Review proposal by Veridise sounds good to me.

<k​ayabanerve:matrix.org> (I did not hand write the thousands of equations which is an FCMP. I wrote functions which call functions which expand to thousands of equations while automatically handling labeling and layout)

<j​berman:monero.social> The reason I thought of a bounty is because it could potentially attract devs who don't have the bandwidth to commit to a CCS, but with a large enough bounty, could try their hand at it in free time or whatever. I had one specific candidate in mind for this (Fabrizio)

<k​ayabanerve:matrix.org> Heard with request we circle back on this jberman

<s​gp_:monero.social> jeffro256: any feedback on these quotes?

For the little I can really judge, I am also ok with the proposal

<k​ayabanerve:matrix.org> Also, FWIW, tevador proposed multiple curves before the contest. Helios/Selene was the best.

<k​ayabanerve:matrix.org> The comments on a better curve is we can more specifically point to specific metrics and how it effects the current code.

<k​ayabanerve:matrix.org> That doesn't mean such a curve exists/is feasible to find.

<o​frnxmr:monero.social> I wouldn't say plowsof did, and i also thinks more about unsolicited (non mrl) bounties

<r​ucknium:monero.social> IMHO, the conversation about research bounties on bounties.monero.social could be re-opened. I should have said that many people agreed that research bounties should be disallowed, and plowsof implemented it.

<r​ucknium:monero.social> The problem with research bounties is verifying the quality of the work product and setting completion standards.

<s​gp_:monero.social> Maybe allow them only with consensus in this channel; they are difficult to judge and keep focused unfortunately

<s​gp_:monero.social> Anyway, that's all from me. I'll move forward with these quotes

<k​ayabanerve:matrix.org> Research -1s proof verification plz

<k​ayabanerve:matrix.org> +1 xmr

<k​ayabanerve:matrix.org> +2 xmr

<k​ayabanerve:matrix.org> +10 xmr

<k​ayabanerve:matrix.org> Hi, I have a chatgpt account, here's research. Money?

<r​ucknium:monero.social> sgp_: Do you want to get loose consensus from MRL today about this? I think it would be OK to do so.

<s​gp_:monero.social> If possible, yes I would like loose consensus

<k​ayabanerve:matrix.org> I thought we already had it

<r​ucknium:monero.social> Everyone who has expressed an opinion has expressed a favorable opinion.

<r​ucknium:monero.social> Anyone else?

<k​ayabanerve:matrix.org> Is it not loose consensus until Rucknium officially declares it loose consensus

Lol

<s​gp_:monero.social> well, you need to draw the line somewhere :)

<o​frnxmr:monero.social> Can it be a curve /s

<r​ucknium:monero.social> This is actually one of the few things that the chair should do. Unless we want to bootstrap this idea.

<k​ayabanerve:matrix.org> Hey, I don't mind, I just thought we had it and I think you thought we did too

<k​ayabanerve:matrix.org> (Hence why you said you'd move forward)

<k​ayabanerve:matrix.org> Rucknium: sure :p

<r​ucknium:monero.social> I mean, the chair shouldn't do much in these types of meetings, but this is one of the few duties, arguably.

<r​ucknium:monero.social> I see loose consensus here in favor of "Helioselene Review" by Veridise for 36,250 USD equivalent or less gist.github.com/SamsungGalaxyPlayer/981e8281b91b49901f516eec54ee3c4d

<s​gp_:monero.social> ty ty, I'll get these started asap then

<r​ucknium:monero.social> kayabanerve: Don't tell them about that time I threatened to bring out Robert's Rules of Order in a MAGIC Monero Fund meeting :P

<r​ucknium:monero.social> Thanks everyone for your work and input on these reviews and audits.

<r​ucknium:monero.social> 4) [Transaction volume scaling parameters after FCMP hard fork](github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf).

<k​ayabanerve:matrix.org> sgp_: swears by those

<k​ayabanerve:matrix.org> Maybe we should employ them?

<k​ayabanerve:matrix.org> I think SGP misclicked the thumbs down by accident with how excited they were.

<k​ayabanerve:matrix.org> /s, onto scaling?

<a​rticmine:monero.social> Ok

<a​rticmine:monero.social> I went over the TX sizes and verification times

<k​ayabanerve:matrix.org> jberman @jberman:monero.social: Can you bring your link down, please?

<j​berman:monero.social> seraphis-migration/monero #44#issuecomment-3150754862

<k​ayabanerve:matrix.org> Thank you

<a​rticmine:monero.social> Two things are apparent

<a​rticmine:monero.social> 1) Changing the minimum node relay fee based upon transmission size does take care of the verification time issues

<a​rticmine:monero.social> 2) We should limit the use of transcription weights to the membership proofs and only to address non consensus changes in size

<a​rticmine:monero.social> Otherwise just use the actual size

<k​ayabanerve:matrix.org> I'm against actual size because of how actual size is dependent on VarInts.

<k​ayabanerve:matrix.org> Estimating the weight impacts the fee impacts the TX size requires re-estimating the weight impacts the fee...

<a​rticmine:monero.social> Doos this just apply to the membership proofs?

<k​ayabanerve:matrix.org> I'd prefer a simple formula based on inputs, outputs, TX extra, even if it is effectively the TX size for the number it outputs.

<k​ayabanerve:matrix.org> No, the fee is a VarInt.

<a​rticmine:monero.social> I made we can use fixed weights based upon a set of initial size calculations

<k​ayabanerve:matrix.org> It's a really stupid annoyance that *can* be replaced by a single-pass algorithm but that would cause a fingerprint

<a​rticmine:monero.social> Then apply it based upon inputs, outputs, tx extra

Stupid question: We can't just serialize a little bit differently and drop those VarInts?

<a​rticmine:monero.social> I see no problem with that

<a​rticmine:monero.social> What I am against is building a verification time surcharge on the tx weight

<v​tnerd:monero.social> I don't recall fee being a varint being that big of an issue, you estimate close to get actual size and the fee only has to be nudged by minimal amount

<v​tnerd:monero.social> It is gross because both lwsf and wallet2 do a multi pass for fee calculation, but it's not terrible

<a​rticmine:monero.social> The idea would be to use estimated fixed weights that are close enough instead of actual size to simply the wallet calculations

<a​rticmine:monero.social> I am fine with that

Simplifying is very welcome IMHO

<a​rticmine:monero.social> So is there a loose consensus on this weight approach?

<k​ayabanerve:matrix.org> vtnerd: The fact the calculation depends on the result of the calculation is gross. The practical issue is whoever doesn't perform a recursive calculation will have observably different results on the block chain, allowing identifying the wallet used.

<k​ayabanerve:matrix.org> I'm against removing the clawback if we allow 128 inputs.

<j​berman:monero.social> I'm fine with it. jeffro256 's code already does it fwiw and it's pretty clean

<o​frnxmr:monero.social> would this be, within a fre tier, a fixed fee per input? (+ extra for txextra)

<o​frnxmr:monero.social> Fee* tier

<k​ayabanerve:matrix.org> A 65 input TX will take as long to verify as a 128 input TX, and only benefits from batch verification if other 65+ input TXs are present.

<a​rticmine:monero.social> The fee will be at least 200x higher

<j​berman:monero.social> tbc, I'm fine with the approach to determine weight based on n inputs, no outputs, and extra len

<j​berman:monero.social> n outputs*

<k​ayabanerve:matrix.org> So unless we limit the inputs to 8/16...

<a​rticmine:monero.social> For 128 inputs

<k​ayabanerve:matrix.org> But compared to 65 inputs, which has the same verification time?

<a​rticmine:monero.social> I am actually in favour of limiting input to 16 or even 8

<o​frnxmr:monero.social> the 8 inputs is already a pita on my testnet

<k​ayabanerve:matrix.org> Yes, but unfortunately it seems at large, the plan is to not YET limit the inputs so.

<k​ayabanerve:matrix.org> I think we need the clawback because of that decision.

<k​ayabanerve:matrix.org> TBC, I'd love to limit the inputs and simplify out the clawback, later moving to indistinguishability.

<a​rticmine:monero.social> I will be calculating fees for the table up to 128 inputs. This may give us a better idea

<k​ayabanerve:matrix.org> But the vibe I have now is that we will only limit the amount of inputs when we mandate the amount of inputs.

<k​ayabanerve:matrix.org> I believe that to be a poor decision, but it is a decision.

<k​ayabanerve:matrix.org> Like, we can at least limit to 32 now so people do have to be more mindful w.r.t. aggregation

<a​rticmine:monero.social> It takes into account the actual size and the additional fee level on node relay to make the larger size scale

<k​ayabanerve:matrix.org> That way, we don't immediately jump from 128 to 8.

<j​berman:monero.social> 65 input tx is taking 2.17s to verify, and is 80k bytes. 128 input tx is taking 3.44s to verify, and is 152k bytes

<k​ayabanerve:matrix.org> Hm. That's not as immediately expected. They should share an MSM size....

<a​rticmine:monero.social> Both would attract the maximum fee for scaling

<k​ayabanerve:matrix.org> Oh. Right. The batch FCMP isn't perfectly aligned to powers of 2 anymore.

<a​rticmine:monero.social> 200x minim

<k​ayabanerve:matrix.org> Sorry, jberman, how's 50 and 140?

<a​rticmine:monero.social> Then there is the size difference on top

<j​berman:monero.social> actually correction: 65in-2out is taking 2.17s to verify, and is 80k bytes. 128in-2out is taking 3.42s, 150k bytes

<a​rticmine:monero.social> I will have a fee table

<j​berman:monero.social> 50in-2out: 1.33s, 62k bytes

<a​rticmine:monero.social> For the next meeting

<j​berman:monero.social> max tested was 128 inputs

<o​frnxmr:monero.social> why would higher number of inputs result in a higher multiplier? as a hot dog vendor, its not _my_ fault that i have 100 customers spending 0.01xmr per day

<a​rticmine:monero.social> because of scaling attacks by spamming the high input transactions with minimal cost because they never get to the miner

<r​ucknium:monero.social> Some merchants charge a surcharge for paying in BTC because of its fees and the need to consolidate outputs. IIRC, BTCPay Server has a built-in option for this.

<o​frnxmr:monero.social> Either i'm forced to create 13 transactions (paying for 8 in 2 out, potentially creating more dusty outputs) or burn my $ on fees by sending all at once

<a​rticmine:monero.social> It is a way to DDOS the nodes with transactions that are very unlikely to be miined

<a​rticmine:monero.social> The attack works very well in Bitcoin when their blockchain is congested

<a​rticmine:monero.social> If there is a high verification cost , then it can be cost effective for the spammer

<r​ucknium:monero.social> Let's keep moving:

<o​frnxmr:monero.social> the fee doesnt matter if the tx isnt mined though

<r​ucknium:monero.social> 5) [FCMP alpha stressnet planning](seraphis-migration/monero #53#issuecomment-3053493262).

<r​ucknium:monero.social> Last meeting, jberman said:

<r​ucknium:monero.social> > w.r.t. stressnet, I'd say let's get 1 more week to address above (refresh refactor, 9473, 8 input PR, and dynamic block sync size)

<k​ayabanerve:matrix.org> And jberman @jberman:monero.social: Yeah, that's more what I was looking for. ~25% smaller but still most of the verification cost.

<o​frnxmr:monero.social> My bc is up at 1.8mb blocks atm.

<o​frnxmr:monero.social> Rucknium might have a better method of spamming, but i can produce transactions onky every 10-30 seconds or so

<r​ucknium:monero.social> Last stressnet, I handled "slow" tx construction times and unstable wallet-to-node connections by having multiple nodes, each with one wallet connected. Just scaled horizontally.

<j​berman:monero.social> Re: stressnet. The good news imo is it looks like the refresh refactor PR has effectively gotten rid of blocking bugs ofrn has reported. Perhaps ofrn can speak to that

<o​frnxmr:monero.social> I assume the optimizations help with this? Also hard to spam continuosly due to the 8 inputs limit. Most of my txs have 4 destinations but use 8 inputs, and eventually fail because i dont have enough $ in 8 inputs

<o​frnxmr:monero.social> Yeah, most/all of my major issues are resolved

<j​berman:monero.social> less good news is seems we still need more time for review

<r​ucknium:monero.social> My script controls tx construction so that the spam txs have only one input, unless I specifically request consolidation txs.

<o​frnxmr:monero.social> I have multiple wallets and nodes, each wallet produces a tx every 10-40 seconds (bottlenecked at cpu) while it has available outputs

<o​frnxmr:monero.social> i did this for a while, but ended up with dust that i cant spend :Dlol

<r​ucknium:monero.social> Last time I was using the MRL research computing cluster for the spamming, which has plentiful CPU threads.

<o​frnxmr:monero.social> Not enough $ in top 8 inputs to pay the fee

<r​ucknium:monero.social> Abandon the dust.

<j​berman:monero.social> fwiw, because prove() currently does not scale linearly (kayabaNerve/fcmp-plus-plus #34), constructing >16 input txs will actually be slower than constructing multiple 8-inputs. though with >8 inputs allowed, you will have fewer outputs to make txs from in total

<r​ucknium:monero.social> It's actually best to abandon wallets entirely after a while because the database that has to be searched becomes too large, IMHO.

<o​frnxmr:monero.social> Yeah, i have. Txs are 8in2out (self spend) 8in3out (send to other 2 wallets) and 8in5out (self spend + send to other 2 wallets)

<r​ucknium:monero.social> What more needs to be discussed on alpha stressnet this meeting?

<k​ayabanerve:matrix.org> jeffro256: We get 8+ bytes of steg in the change output with CARROT, right?

<o​frnxmr:monero.social> Rebasing to master

<o​frnxmr:monero.social> Explorer

<k​ayabanerve:matrix.org> What if we encrypted the block height of the OLDEST UNSPENT OUTPUT there?

<a​ck-j:matrix.org> I can adapt my spammer from a while back to work on stressnet if interested

<a​ck-j:matrix.org> github.com/ACK-J/Monero-Dataset-Pipeline/blob/main/run.sh

<k​ayabanerve:matrix.org> Then scanning is scanning from the chain tip for a change output to learn where to scan from, if one doesn't care about the wallet history?

<s​packle:monero.social> Not to harp on this point, but I believe the code sent to stress testing should be required to handle the 32MB blocks allowed in the near term by the new scaling.

<a​rticmine:monero.social> Yes

<o​frnxmr:monero.social> I'll share mine too. I think mine is probably more straight fwd

<r​ucknium:monero.social> xmrack: Interesting suggestion. What would be the advantages? IIRC, your latest version had realistic delays in spending.

<o​frnxmr:monero.social> Cant

<j​berman:monero.social> I can work on this for next week

<k​ayabanerve:matrix.org> Ugh, we lost jeffro an hour ago. Sorry, I just thought of that idea due to Rucknium: 's comment about abandoning wallets. This would allow using the same wallet, only abandoning its history, without issue.

<j​berman:monero.social> I'd estimate work involved on the explorer to take 1-2 weeks. so unfortunately would punt this

<o​frnxmr:monero.social> Serialization limits hold us back on max block size, but we can always bypass them hm

<k​ayabanerve:matrix.org> (And obviously, history would still be retrievable, just with more work).

<o​frnxmr:monero.social> Maybe [@duggavo:matrix.org](https://matrix.to/#/@duggavo:matrix.org) can update his explorer to add txpool and other info

<s​packle:monero.social> Why would you want to bypass the code you are stress testing in order for it to handle the scaling design? If there is a disconnect between performance and scaling design it should be addressed.

<r​ucknium:monero.social> AFAIK, this data visualizer "should" at least allow a view of block size: github.com/Rucknium/monerod-monitor

<r​ucknium:monero.social> I agree with spackle

<o​frnxmr:monero.social> Bypass the serialization limits, i mean

<o​frnxmr:monero.social> There are multiple prs open for changing them or addressing how we use them

<a​ck-j:matrix.org> Rucknium: just another option, I’m not sure it has any advantages or even works anymore lol. The spending delays can be easily changed though like you said

<a​rticmine:monero.social> One needs to generate the testnet spam using multiple devices in parallel to simulate the actual Monero network

<j​berman:monero.social> If we wanted to block stressnet and wait until scaling design is settled, then I would advocate for a public testnet sooner

<o​frnxmr:monero.social> Duggavo's moneroblock explorer lets yoy view block sized etc. Just uses rpc

<o​frnxmr:monero.social> I'm using 3 devices, buut still not near mainnet speed

<o​frnxmr:monero.social> Jberman, do the optimizations make tx construction faster?

<r​ucknium:monero.social> IMHO, no need to wait until scaling design is settled before alpha stressnet. Alpha stressnet is for making sure all the code works with reasonable tx volume.

<s​packle:monero.social> Agreed, no need to stop alpha testing. Just want to push that in the fullness of time this must be addressed.

<j​berman:monero.social> AFAIK there are no immediate significant optimizations to tx construction on top of the code you're currently testing. Just allowance of >8 input txs, which again may even end up making tx construction slower than you're experiencing

<o​frnxmr:monero.social> Yeah, so i think [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) maybe you should join my testnet and see how well your fare with creating txs using better cpus

<j​berman:monero.social> kayabanerve: would daelk ed25519 field arithmetic or faster inverse have a significant impact on tx construction? I don't recall of the top of my head

<j​berman:monero.social> dalek* off*

<r​ucknium:monero.social> ofrnxmr: Sounds good. Do you want to post in #monero-stressnet:monero.social ? I may be able to test things late this week.

<k​ayabanerve:matrix.org> However much faster HelioseleneField is now to where it was, Ed25519 Field Arithmetic would be Field25519.

<k​ayabanerve:matrix.org> Faster inverse speeds up... Point compression most notably.

<a​ck-j:matrix.org> In a similar vein as stressnet. Is it realistic to add fuzzing harnesses to the new fcmp cryptographic functions before mainnet? This way they can be fuzzed at scale before we go live

<k​ayabanerve:matrix.org> Fuzzing for?

<j​berman:monero.social> I would pencil it in as: not expected significant, so would welcome a surprise outcome of significant

<r​ucknium:monero.social> 6) [Spy nodes](monero-project/research-lab #126).

<a​ck-j:matrix.org> kayabanerve: similar to github.com/monero-project/monero/bl…b/master/tests/fuzz/bulletproof.cpp

<r​ucknium:monero.social> I need to jump into the conversation jeffro256 and rbrunner are having about the details of subnet deduplication: monero-project/monero #9939

<r​ucknium:monero.social> 7) PoW mining pool centralization. [Monero Consensus Status](moneroconsensus.info). [TEE-assisted Censorship-Resistant Block Template Production](monero-project/research-lab #134). [Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions](soc1024.ece.illinois.edu/nonoutsourceable_full.pdf).

<r​ucknium:monero.social> On that last paper, there is this reply: Chepurnoy & Saxena (2020) "Bypassing Non-Outsourceable Proof-of-Work Schemes Using Collateralized Smart Contracts" eprint.iacr.org/2020/044

<r​ucknium:monero.social> Which I learned about from fluffypony.

<r​ucknium:monero.social> > Using this, we show how to bypass previously proposed non-outsourceable Proof-of-Work schemes (with the notable exception for strong non-outsourceable schemes) and show how to build mining pools for such schemes.

<r​ucknium:monero.social> I don't know what makes a "strong" non-outsourceable scheme and frankly I have not read either paper.

<r​ucknium:monero.social> Like I said in my update, I made moneroconsensus.info to visualize potential malicious mining behavior. I am trying to implement a statistically rigorous and trustless estimator for network hashpower and hashpower of individual mining pools, based on Ozisik, Bissias, & Levine (2017) "Estimation of Miner Hash Rates and Consensus on Blockchains" arxiv.org/abs/1707.00082

<a​ntilt:we2.ee> "strong" means that the identity of the claimer ("thief") remains anonymous

Sounds a bit like magic that such estimates should be possible ...

<r​ucknium:monero.social> Mining pools would need to claim their blocks. The concept is not very difficult: just look at how much PoW each miner is adding to the blockchain.

<r​ucknium:monero.social> There will be large confidence intervals when the time window is short.

<a​ntilt:we2.ee> a hybrid method has been contemplated by sech1

<a​ntilt:we2.ee> also: the paper requires a math phd, but wownero has implemented the basic idea afaik

<r​ucknium:monero.social> Ozisik, Bissias, & Levine (2017) also suggest that mining pools report their best hashes frequently, which gives you a verifiable way to estimate hashpower at greater frequency. Basically, p2pool already does that as a side affect, as I understand it.

<a​rticmine:monero.social> One concern I see here is to what extent are we encouraging cloud mining

<o​frnxmr:monero.social> P2pool only knows its hashrate based on found pool shares. I think centralized pools are more granular because they lffer much lower difficulty shares / target job success at like 10-30 seconds

<r​ucknium:monero.social> I don't think any centralized pools post their PoW hashes that don't clear the blockchain difficulty hurdle. They just report what they want on their API, which is not really verifiable AFAIK.

<o​frnxmr:monero.social> agreed

<s​packle:monero.social> To paraphrase sech1's writing: Demand the first coinbase output to be some % of the block reward (10% for example) and be signed with the private key, and the rest of the block reward can go to as many outputs as you need. Regular pools can still exist controlling 90% of the block reward, solo miners and P2Pool can exist too (P2Pool miners will receive 90% of the block reward regu<clipped message>

<s​packle:monero.social> larly in small portions, and 10% in solo-like mode).

<r​ucknium:monero.social> I think that moneroconsensus.info was "a hit". It's not very optimized yet, so users could have experienced performance issues. Anyone have issues so far?

<r​ucknium:monero.social> Special thanks to DataHoarder who wrote the initial version of the pool data gatherer and quickly added a nice feature to capture orphaned blocks data when it was needed for this web app.

<a​ntilt:we2.ee> plus such a change costs Qubic resources

<s​packle:monero.social> Yes, it could apply to current events as well as the foreseeable future.

<a​rticmine:monero.social> Qubic is turning on and off their Monero mining at a faster rate than is reported by the Monero blockchain.

<r​ucknium:monero.social> I do like the direction of the conversation toward some balanced or hybrid approach in the block reward.

<a​ntilt:we2.ee> here is a easy summary of the paper by socrates1024(amiller); bitcointalk.org/index.php?topic=309073.0

<s​packle:monero.social> The relative simplicity makes the hybrid block reward interesting to me, and I do not see any misalignment with the broader goals of Monero.

<a​ntilt:we2.ee> quote: >you would prove in zero-knowledge that you know a valid solution

<a​ntilt:we2.ee> its a hard fork, but ultimately a valid defence

<r​ucknium:monero.social> More conversation about mining centralization?

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<k​ayabanerve:matrix.org> There's an existing FCMP test which proves a proof, then malleates each and every byte in it, asserting it fails.

<k​ayabanerve:matrix.org> since the FFI with Rust is premised on a simple byte buffer, it should be trivial to fuzz from C

<k​ayabanerve:matrix.org> spackle: If it's of no distinction to all existing infra, why would it be of distinction to any infra?

<s​packle:monero.social> kayabanerve: Can you be more specific/rephrase, I am not sure I follow.

<s​packle:monero.social> If you are referring to the hybrid block reward approach, it makes a difference to all miners except solo.

<c​ountbleck:matrix.org> I think it's broken right now

<r​ucknium:monero.social> There was an alt chain longer than one block. It crashed the app. I am fixing now. I did warn that it was untested

<k​ayabanerve:matrix.org> spackle: You say here regular pools can still exist, and so can P2Pool.

<k​ayabanerve:matrix.org> If all existing infra continues, where does the distinction lie? What's the purpose?

<s​packle:monero.social> kayabanerve: The purpose is to give an edge to solo miners and p2pool.

<k​ayabanerve:matrix.org> How does P2pool *benefit*?

<k​ayabanerve:matrix.org> Agreed on somewhat of an edge to solo miners

<k​ayabanerve:matrix.org> (The edge is only maintained if there aren't ways to dodge this intent)

<s​packle:monero.social> I believe there are ways to dodge the intent, but it enforces that pools have the option. Who would you rather mine with?

<s​packle:monero.social> I see my paraphrasing hasn't done things justice, I'd ask you to reference the top of the discussion we had in this channel yesterday: libera.monerologs.net/monero-research-lab/20250805

<r​ucknium:monero.social> CountBleck: Fixed.

<c​ountbleck:matrix.org> oh cool, now I can continue lurking here to learn more about the Qubic situation

<c​ountbleck:matrix.org> thanks :3

<s​packle:monero.social> If only a single pool did not make people go through a workaround (which I imagine to be inconvenient), it would immediately be a massively better choice than the competition. As a happy coincidence, p2pool would do this by default.

<a​rticmine:monero.social> One possible idea with signing the block is that at least one output with a minimum of 0.006 XMR be sent to the signing key. This effectively gives a bonus of 1% to the finder of the block. This is not an unreasonable burden on a pool.

<a​rticmine:monero.social> This can also break botnets.

<a​rticmine:monero.social> Still I would also like to see AGPL V3+ in the mining and pool code to mitigate cloud mining risks.

<a​rticmine:monero.social> I know that such a stiff copyleft is controversial, but at least I see a discussion on the subject of using copyleft to deter centralized attacks was warranted given the Qubic situation.

Qubic lost block a59aa46587b8bbdb76714001e087124f87ff7ad5e44050b5205f7ea0e8147ac0 at height 3472150, but it's not visible on moneroconsensus.info

<b​oog900:monero.social> Did qubic mine 3472148 and 3472149?

yes

they kept selfish mining, but failed (got unlucky) with 3472150

<b​oog900:monero.social> Hmm interesting .... Their selfish mining strategy is weird.

It was there for a second then gone, or maybe it had not gotten data from API yet

<r​ucknium:monero.social> I would guess that they are varying the number of blocks they withhold based on time elapsed since last block instead of setting it to a static chain length goal.

yes, it looks like they withhold an altchain for a fixed time (2 minutes?)

DataHoarder no, a59aa46587b8bbdb76714001e087124f87ff7ad5e44050b5205f7ea0e8147ac0 was never broadcasted to the network. So the API couldn't have seen it at all. That's the limitation of this tool

<c​ountbleck:matrix.org> How are you determining whether a block is Qubic's?

And one more orphaned Qubic block, 6667672881a08b4fe9158c47770e2b6e70d80cef38c8415e279a39a90b58200a at height 3472167

<c​ountbleck:matrix.org> What's going on right now

<c​ountbleck:matrix.org> nvm "Known bug that fails to assign some blocks to mining pools" is messing with me

<o​frnxmr:monero.social> Thats regarding the explorer

<o​frnxmr:monero.social> [#monero-research-lounge:monero.social](https://matrix.to/#/%23monero-research-lounge:monero.social) for more casual talk / questions. Plz and thx