I have uploaded the updated transaction weight files Discussion and links are here: seraphis-migration/monero #44

<rucknium> MRL meeting in this room in 1.5 hours.

<sgp_> @rucknium:monero.social: for the Helios-Selene topic, there's no need for discussion time on that during the meeting, though more discussion does need to happen there in general. I'll just post an update during the meeting and then you can continue with the other topics. Thanks!

<rucknium> Meeting time! monero-project/meta #1272

<rucknium> 1. Greetings

<articmine> Hi

Hello

<jeffro256> Howdy

hullo

<sgp_> Hello

<tomdooley:matrix.org> Here for moral support, have a great meeting!

Hi via IRC

<jberman> waves

Hi

<rucknium> 2. Updates. What is everyone working on?

<jberman> me: completed PR refactoring wallet2 refresh for FCMP++, opened draft PR to persist dest addrs when updating wallet from pre-FCMP++ to FCMP++, opened draft PR for documentation on the FCMP++ integration, some small cleanup PR's, reviewed some of jeffro's PR's

<vtnerd> hi: me: working on carrot/fcmp stuff mostly (and some bug fixes). Spent some time diving into curve-trees to figure out how lws was going to handle. likely going to “punt” and giveaway privacy details to monerod (at least for first cut)

<vtnerd> the problem is potential memory usage in tree_cache and otherwise having to duplicate the db from monerod into lws

<rucknium> me: Analysis of respend behavior of outputs in invalidated txs after 18-block reorg: monero-project/monero #10085#issuecomment-3313627068 . Rolling DNS checkpoints "formal" protocol as flowcharts (click arrows at bottom to see more flowcharts): cryptpad.disroot.org/diagram/#/2/diagram/view/yI43W1 [... too long, see mrelay.p2pool.observer/e/iYW6sbgKXzB4VEdJ ]

Me: Responding to the Veridise audit of Helios/Selene and working on a selfish mining mitigation proposal (work in progress).

<jeffro256> Me: Wrote a Rust library for CARROT (github.com/jeffro256/carrot-rs) and finished reviewing seraphis-migration/monero #81. Personally excited for alpha stressnet

supporting DNS checkpoints testing as needed, looking at ZMQ behavior during reorgs for p2pool mining specifically

<articmine> Completed a new weight formula for transactions to address the issues with transaction weights and the penalty

<vtnerd> DataHoarderdid you spot any other issues than the one in the pr?

believe it or not the PR one was not related, we found it by chance by testing subaddress payouts on P2Pool.

I have noticed that when switching to a shorter altchain (checkpointed one) ZMQ updates are not sent properly to P2Pool, or P2Pool ignores them

I cannot confirm yet if other block/chain ZMQ messages are sent when switching to a shorter chain, noticed it when mining with p2pool on testnet and the network reorg'd against my longer chain (monero switched chain, but p2pool was left behind, and I saw no logs of ZMQ message being received for miner data)

<vtnerd> hmm this could theoretical happen if the zmq buffer was full, but that is unlikely

<rucknium> @jeffro256:monero.social: Would you have time to review a draft of the tx invalidation blog post, just to check correctness? Probably have the draft ready for review in 6-24 hours.

it's not a blocker (p2pool could workaround this) but I'll post in lounge about it if I can confirm the issue again with more logging in place

<jeffro256> Yes! Send me a DM whenever

<rucknium> I mean correctness as "does Rucknium understand this technical point correctly?"

<rucknium> @jeffro256:monero.social: Thanks!

<rucknium> 3. Carrot follow-up audit (gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb).

<jeffro256> I'm sorry for the delay, I brought up some input pretty late into the discussion; we're going back over some finer points of their report

<jeffro256> Not much else to report

<rucknium> 4. Proof-of-Work-Enabled Relay ("PoWER") (monero-project/research-lab #133).

<jberman> I updated the proposal to account for the latest discussion: 1) Equi-X (instead of RandomX), and 2) PoW once per connection, rather than per tx

FYI, Equi-X is about to be upgraded to v2 due to some issues with v1.

It's being coordinated with Tor.

<jberman> (I received a dm for someone interested in taking on PoWER so I wanted to have the proposal reflect the latest state)

<jberman> are the issues public?

Not public yet.

<jberman> got it, thank you

<rucknium> By "taking on PoWER" do you mean someone who wanted to implement it (write the code)?

<jberman> yes

<jberman> I would think an Equi-X v2 would be a drop-in replacement for v1, and the vast majority of code implemented on the Monero side would be unchanged

Will we have to write a C++ implementation of Equi-X ourselves?

<jberman> I assume it would be used as an external submodule same way RandomX is used today

I mean the core algorithm. Guess somebody wrote that already

Yes, EquiX v2 will have the same interface as v1.

<jberman> tevador wrote it in C: github.com/tevador/equix

Ah yes, thanks.

<jberman> @jeffro256:monero.social: you raised some pushback against PoW per connection, in case you want to re-raise that point

<articmine> I will also raise pushback on this

<jberman> what is your argument?

<jeffro256> Yes, I think that A) PoW per connection is much more complicated, adding a lot of unnecessary technical debt to our connection code, and B) that PoW should be reusable per-tx

<articmine> User POW can be very harmful in hot climates, mobile devices etc

so generate pow once, then it can be re-broadcast with same pow? > B) that PoW should be reusable per-tx

<articmine> It is a myth that POW heat is irrelevant

<jeffro256> It should be reusable per tx to enable transaction propagation to be faster with new node connections

<jeffro256> DataHoarder: Yes

<boog900> @jeffro256: I don't see the argument that this slows propagation

<articmine> Still it can be a barrier

<boog900> you don't make new connections on tx broadcasts you use existing connections

<boog900> if anything needing to verify PoW on every hop would slow propagation

<jberman> To minimize technical debt, it could be expected on first tx w/>8-inputs, and then the connection is verified for future txs. Would be a simple boolean per connection to keep track of

<jeffro256> @boog900: For new connections. If PoW is reusable per-TX, then a node can flood the network with that TX instantly, whereas if PoW is done per-connection, then a node is "locked in" to its existing connections for TX propagation

<jeffro256> Also PoW per-connection opens the door to DoS against honest broadcasters

<boog900> @jeffro256: locked in in the sense that they need to do PoW to open more connections .... they still have their current connections tho

<boog900> new connections aren't broadcasted to anyway

<jeffro256> Yes

<boog900> we only broadcast to current connections

<articmine> I mean can the spam farm not be set up in some cold part of Canada or Russia?

<jberman> If it's per tx, you have to deal with txs sitting in the pool longer than 10 blocks, which is arguably a significant area of technical debt that is likely more significant than a per-connection PoW

<jeffro256> @boog900: New connections ask for mempool contents, which would also ostensibly be PoW enabled

<boog900> I also don't really see the technical debt argument they are both added complexity

<boog900> @jeffro256: only when finished syncing IIRC

<jeffro256> You still have the 10 block problem with PoW-per-connection though? How is it avoided?

<jeffro256> @boog900: Which is most nodes

<boog900> @jeffro256: you don't need a timeout on the PoW?

<boog900> @jeffro256: no I mean it only happens once a node syncs up not after

<boog900> like a synced node doesn't just a node which has finished syncing

<jberman> "User POW can be very harmful in hot climates, mobile devices etc" -> honest devices constructing the tx in the first place is expected to be more CPU/work intensive than the PoW calculation. the PoW calculation is to raise the cost for malicious users who craft invalid txs at no cost

<jeffro256> @boog900: You do still need a "timeout" or at least bind the PoW to some provably recent random data or a "challenge", so an attacker can't build up PoW for connections

<boog900> @jeffro256: yes but it is per connection .. you don't need to repeat it

<boog900> with per tx after 10 blocks you can no longer send the tx to anyone

<boog900> without doing the PoW yourself

<jberman> ^

<jeffro256> Why would the PoW timeout for per-TX necessarily be 10 blocks?

<jberman> That's how I had it in the original proposal

<jberman> If it's a lot longer, then the attacker can collect PoW hashes for a longer period of time

<boog900> @jeffro256: because you can compute loads in reserve and flood all at once

<articmine> > <@jberman> "User POW can be very harmful in hot climates, mobile devices etc" -> honest devices constructing the tx in the first place is expected to be more CPU/work intensive than the PoW calculation. the PoW calculation is to raise the cost for malicious users who craft invalid txs at no cost

<articmine> So the malicious user sets up the spam farm in some cold part of Canada. The malicious use uses the attack POW heat for space heating. There is no cost

<boog900> @articmine: the cost is time

<jberman> that's definitely added cost over 0

<articmine> -40 = zero spam cost

<boog900> they can't just send bytes they have to find a PoW solution to send it

<boog900> better than no cost

<articmine> -49 C or F

articmine: Not zero cost. They could be mining Monero instead of spamming. Opportunity cost.

<rucknium> At least, there is an opportunity cost of not mining Monero blocks.

<boog900> github.com/monero-project/monero/bl…yptonote_protocol_handler.inl#L2442

<articmine> It is not the same because the amount is so sma

<articmine> Snall

<jberman> @jeffro256:monero.social: do you see the argument in favor of per connection PoW? if not, I think we should table the discussion, and at least come to agreement that it makes sense for wallet API to allow specifying a max input so the other dev can start on this task?

<boog900> @boog900: only once per run of monerod it seems

<jeffro256> @jberman: I see the argument, I don't know if I'm entirely convinced, but yeah I can definitely start on that wallet API point

<jberman> I think that may be a good task to pass over to the other dev, but your call, we can discuss later

<jeffro256> Perhaps you can let the aforementioned dev working on per-connection first, and both if he/she has the time, and then we can compare what the actualized complexity is

<jberman> that sgtm

Slightly related note: Have we considered having a special connection type for block relay only? Those would not need any PoW. Bitcoin has it. Low-end devices could then still connect to the network.

<rucknium> IIRC, by default bitcoin has 8 outbound connections for block + tx relay and 1-2 additional connections for block-only relay.

<articmine> Now that is an interesting idea

<jberman> The PoW per connection could be an optional thing done per connection, and if done, enables sending txs with >8 inputs over the connection

<jberman> via tx relay

<jeffro256> @jberman: This is how I imagined it, but there's still the issue of mempool fetching. Does that force the responder to upgrade the connection by doing PoW?

<articmine> It is certainly better if it is done by the node

<boog900> @jeffro256: seen as thats a response, no IMO

<boog900> you can't exactly spam txs with that

<jeffro256> But then that allows the responder to dump a load of invalid high-input txs to the requester

<jeffro256> Ostensibly, the requester would try validating at least 1

<boog900> @jeffro256: the node ignores the rest if any 1 is invalid

<boog900> shouldn't be a DoS

<jeffro256> Assuming you can't trigger a node to make that request with high frequency

<boog900> @jeffro256: current code wont, we just need to keep it in mind for future changes

<rucknium> 5. Transaction volume scaling parameters after FCMP hard fork (github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight funcion (seraphis-migration/monero #44).

<rucknium> I will limit discussion of this item to 30 minutes maximum, unless there is an objection.

<articmine> The major change is the overall weight applied to the transaction to mitigate the impact of the penalty.

<articmine> The reasonable weights based number of inputs work very well

<articmine> So we can easily have fees that are close to proportional to number of inputs or verification time

<articmine> It is a major change in how WWE charge fees

<articmine> So now the fee depends on the square of the weight

<articmine> The next step is t get the size and verification times for all the peoofs

<articmine> Any qt?

<articmine> Questions?

<articmine> I have the data for the membership proof weight formula already

<articmine> So the proposed weights for this proof are in the latest proposal

<jeffro256> Sorry, but at the moment, I NACK making the fee a non-linear function of the weight. That has the same effect as making the weight a function of the square of the number of inputs, which we previously agreed that the weight of the tx should be a linear function of the number of inputs

<jberman> I included the SAL proofs as well in the latest update to that comment

<articmine> The penalty is non linear

<articmine> The end fee is linear with the number of inputs

<jeffro256> Agreed on the penalty being non-linear. But the penalty isn't quadratic in the weight of 1 transaction, it is quadratic in the total size of all transactions in a block

<jeffro256> The base fee-per-vbyte should be calculated as a square of the backlog IMO, not as a square of the 1 tx weight

<articmine> That way scaling works it is quadratic on each transaction. That is the point

<articmine> It amounts to the same thing

<jeffro256> It doesn't amount to the same thing, especially when the penalty free zone isn't saturated. A 2-in tx should not cost 4x as a 1-in tx when the marginal penalty difference for both is 0.

<articmine> The penalty for adding a transaction is quadratic with the TX weight

<articmine> It doesn't cost 4x. It is linear

<articmine> Because the weight goes as the square root

<articmine> The latter is the point

<jeffro256> The penalty is not quadratic in the single TX weight, its quadratic in the total TX weights for that block, which results in different calculations for individual txs based on on-chain activity

<jeffro256> You mentioned that fee is a function of the square of the weight in your latest proposal, yes?

<articmine> Iit is a simple formula for the additional penalty

<jeffro256> Oh so you're proposing weight be a function of the square root of the number of inputs?

<articmine> Correct

<articmine> That is the point

<jeffro256> Why that change?

<jeffro256> Versus keeping both linear

<articmine> So that after the quadratic penalty is applied you get linear with the number of inputs

<articmine> You mean changing the penalty to linear

<articmine> I looked at that

<articmine> This works better because it incentivizes effective block construction by the miner

<articmine> The penalty has never been linear

<jeffro256> I meant weight function and fee function by "both", not changing the penalty function

<articmine> It doesn't work

<articmine> The quadratic penalty is in-between the weight function and the fee function

<articmine> So apply square root weight, then quadratic penalty , then quadratic fee

<jeffro256> Okay I think I see the fundamental disagreement. You believe that the marginal loss of block emission due to the penalty is a quadratic function of each transaction weight. I believe that the marginal loss of block emission due to the penalty is a quadratic function of the total transaction weights in a block. Is this a correct assessment?

<articmine> Yes

<articmine> It is the difference in penalty

<articmine> That matters

<articmine> Apply the penalty right at the start of scaling

<jeffro256> What would it take to convince you that the marginal loss of block emission due to the penalty is a quadratic function of the total transaction weights in a block, and that the base fee-per-vbyte should be a quadratic function of that value, instead of being quadratic in the weight of one transaction?

<jeffro256> @articmine: I disagree, this doesn't make sense for 99% of cases

<jeffro256> It only works in the worst case

<articmine> You have to look at the game theory of the interaction between miners and users

<articmine> Assume enlightened best interest

<articmine> So yes the worst case controls

<jeffro256> So people should be paying fees 100% of the time as if they were pushing up the dynamic block size ?

<articmine> Correct

<jeffro256> This is a bad idea IMO. That means that there's no downwards price incentive for keeping the block small

<articmine> The lowest fee pays the marginal penalty

<jeffro256> People should be rewarded for not increasing the block size

<articmine> @jeffro256: You mean rewarded for not using Monero?

<jeffro256> For not making spam, yes. There is still a driving incentive for people to use Monero, which is its monetary and transactional utility over other currencies. But there needs to also be an incentive to not make unnecessary transactions

rucknium: It has been 30 minutes.

<rucknium> 6. FCMP alpha stressnet planning (seraphis-migration/monero #53#issuecomment-3053493262).

<jberman> The blocker PR 81 has been accepted (thank you jeffro!), ofrn is now doing final testing with the latest state of that PR

<jberman> Once I get a green light from ofrn, I'll make the PR setting alpha stressnet dates

<jberman> (by setting hf blocks on testnet)

<jberman> Thinking I'll write up a shareable post in that PR description, and we can share that post in the stressnet room, and reddit?

<jberman> once the PR is accepted

<jberman> And as per prior discussion, will target 7 days from the time of acceptance

That should do IMHO

<rucknium> Note: I think as of today, the default decision will be to release my tx spamming code as open source. That lowers the barrier a little for a malicious actor to spam mainnet, but all my CCS work is supposed to be published open source. If that default choice should change, it could be discussed.

<rucknium> 7. Mining pool centralization: Temporary rolling DNS checkpoints (monero-project/monero #10064), Publish or Perish (monero-project/research-lab #144), and Lucky transactions (monero-project/research-lab #145).

<rucknium> There is a bug that can occur in rare cases that will get a node stuck if it is enforcing DNS checkpoints. AFAIK, @0xfffc:monero.social and @ofrnxmr:monero.social are investigating it.

<rucknium> binaryFate has activated the checkpointer of testnet for the seven moneropulse domains: testpoints.moneropulse.xxx

<ofrnxmr> @0xfffc:monero.social is trying to fix the logic that caused reorged checkpointed nodes to get stuck. Will test one more time with the moneropulse domains, and if i break that checkpointer again, we'll switch back to ruckniums domains to speed up the testing

<ofrnxmr> s/one more time/until it breaks again/

<rucknium> I tested DNS resolver latency (important for agreement between the 7 records of the 7 domains). My preliminary results say that there is good performance when one of several specified DNS resolvers are used. There are mixed results when a machine's own default DNS resolver is used. It is easy to change resolvers for monerod with a terminal environmental variable.

<rucknium> Do we have info about mining pools' willingness to turn on checkpoints? At least anything that can be shared publicly?

<rucknium> I created a set of flow charts that provides a "formal" specification of the rolling DNS checkpoint protocol: cryptpad.disroot.org/diagram/#/2/di…DUJzvAB5vAc9X9ujFVAsxGAxgMMyE/embed

<rucknium> Click the arrows that appear at the bottom of the pages to go to the next page.

<rucknium> Once everything is finalized, there will be this flowchart and a narrative. And I hope some FAQs, too. The protocol helps users understand the proposal and how exactly it works.

<rucknium> Anything more on temporary rolling DNS checkpoints, specifically?

<venture> I already enabled dns checkpoints on my node, even though not active yet. Just to note, I got

<venture> [RPC0] ERROR cn src/cryptonote_core/cryptonote_core.cpp:1262 Transaction not found in pool

<venture> quite regularly afterwards.. I don't think this was the case before

<ofrnxmr> Thats unrelated

<venture> hm ok

On the next topic, I'm working on an upgrade to Publish or Perish called "Share or Perish" with workshares. There are still minor issues to be solved before I can publish it.

<rucknium> @venture:monero.social: AFAIK, that's unrelated to DNS checkpoints and would usually happen when Qubic is withholding txs. DataHoarder could confirm maybe

that is normal venture. do you have p2pool?

<rucknium> Thank you, tevador.

that means you are trying to submit_block with unknown txs to your node

it's fine, it happens in normal conditions

<venture> tevador: Nice :)

<venture> I have published some simulation results regarding PoP here

<venture> github.com/venture-life/mining-simu…d#publish-or-perish-with-k3-and-d50

<venture> DataHoarder: ah alright, thanks

<venture> @venture: turns out: deterministic selection doesn't change things.

<venture> otherwise, quite good results I think. With 40% hashrate and close to 1 gamma, without mitigation, the revenue is around 57%. with PoP it drops to 47

<rucknium> @kayabanerve:matrix.org: I think finality layer is fine to discuss during this agenda item, too. I should add it to the links for this item in future agendas.

<kayabanerve:matrix.org> Thank you. I have nothing to discuss there immediately and am here awaiting FCMP++ topics.

<rucknium> @venture:monero.social: How do those results compare to the results i the original PoP paper? Can they be compared?

<venture> I think they roughly match. will double check

AFAIK it should be around 65% with no defenses and α=0.4

<rucknium> @kayabanerve:matrix.org: This is the last agenda item besides "any other business", which could include more FCMP++, of course.

<kayabanerve:matrix.org> Oh, sorry. I thought @sgp:magicgrants.org: had one added. My mistake.

We can discuss that also. Maybe after the meeting?

<kayabanerve:matrix.org> Sorry for getting my wires crossed.

<venture> yes, 66 is theoretical limit. but then people assume attacker has almost 0 propagation delay and a huge number of honest miners..

<rucknium> @sgp_: It was added and then deleted ^

<sgp_> oh, sorry I meant for it to be an agenda item for the update

<kayabanerve:matrix.org> I just saw, yep

<rucknium> DataHoarder: Could you discuss your empirical findings about Qubic's selfish mining profitability?

<sgp_> I should have just said "it will be a agenda item, with more to discuss later"

I had to drop off, I can come with that later rucknium

<rucknium> Thanks, DataHoarder

venture: so PoP doesn't do much for a low-gamma attacker? Qubic seems to be a low-gamma attacker. However, PoP doesn't stop 10+ deep reorgs. That's what my next proposal is intended for.

<sgp_> May I proceed with the FCMP++ curves stuff if there's no other business? Sorry I didn't mean to remove it fully

^ Yes, we can continue with this item.

<rucknium> tevador: Good. In the case of Qubic's behavior, I don't think just reducing the selfish mining economic incentive would deter Qubic or similar actor. Need something with more teeth.

<venture> I think so yes. Really low-gamma attacker might even benefit from the propagation window to some extend. but it also caps high gamma profitability

<rucknium> It seems that Qubic is selfish mining for its propaganda value more than direct economic mining reward profits.

<bawdyanarchist:matrix.org> Preliminary results from my sim show that, a silent stubborn attacker can reorg 20 blocks with regularity. Under various selfish strategies and network loads, they dont appear any more profitable than an honest miner, until that 33% threshold (which is in line with a low gamma attacker).

Can somebody throw in a one-line quick definition of "low gamma"? Thanks!

<rucknium> @bawdyanarchist:matrix.org: Have you seen my theoretical/analytical analysis here? monero-project/research-lab #102#issuecomment-2402750881 My "Table: Duration of meta attack to achieve attack success probability of 50 percent" supports your findings.

<bawdyanarchist:matrix.org> @rucknium:monero.social: Yes, but I havent compared my sim results to the theoretical values yet.

<bawdyanarchist:matrix.org> rbrunner: The percent of honest hashpower that ends up mining on the attacker's branch, instead of the honest extension

<bawdyanarchist:matrix.org> Typically driven by ping, or in some cases, eclipsing attacks.

<venture> gamma is used in literature as an artifial metric between 0 and 1 how likely it is an honest miner will mine on the selfish-head given two branches of equal work... it's a metric for "connectivity" of the attacker

<rucknium> Sounds good. My attacker follows a specific z stopping rule strategy that may differ from your attacker's strategy. But the general conclusion is the same: a large-minority attacker can achieve deep reorgs if it tries again and again.

<bawdyanarchist:matrix.org> Their reorg lengths are significantly affected by their willingness to be "stubborn". Basically to tolerate the honest branch fully catching up, and then claiming the win after exiting the 0' state.

<rucknium> I think I had some simulation code to double-check my formula results, but I didn't post it. I will try to look for it.

So no rented hash rate to jump over 51% for an hour or two not strictly needed for large reorgs?

No, just luck.

<rucknium> rbrunner: Not necessary. But it is possible that Qubic is doing that, too.

<bawdyanarchist:matrix.org> I'm adding summary metrics at the end of each round, and then adding sweeps to the input parameters, so I should be able to search a pretty wide range of input conditions, and summarize those findings.

<rucknium> I computed the probability that Qubic acheived their 20-block reorg with 40% hashpower share (assuming difficulty = 100% hashpower share) and got 5% probability.

<rucknium> I mean, it was amn 18-block reorg but they produced 20 blocks in that period

<rucknium> an 18-block*

<rucknium> That was 5% for a single attempt. And they have been attempting a lot.

<rucknium> So, keep rolling the probability dice and you will succeed the the mining casino eventually.

<rucknium> Probability computation was based on 66 minutes elapsing during the attack, according to block timestamps. And this R line: malicious.hashpower <- 0.4; pgamma(66, shape = 20, rate = 1/2 * malicious.hashpower)

<rucknium> I'm pretty use that's the correct formula for this situation.

<rucknium> pretty sure*

<rucknium> Erlang distribution is a special case of the Gamma distribution.

<bawdyanarchist:matrix.org> That looks surprisingly close to what I'm seeing in the sim. A ~20 block reorg could be possible about once per day (at ~33% selfish HP)

<rucknium> Timing info based on github.com/WeebDataHoarder/Monero-Timeline-Sep14

<rucknium> @bawdyanarchist:matrix.org: Using the formula with 33% hashpower, I get a 20-block reorg with 50% every 1.53 days 😄

<rucknium> Anyway, to the discussion about Helios-Selene parameter rigidity?

<rucknium> I mean "with 50% probability every 1.53 days."

<rucknium> I think my table scared kayabaNerve when I produced it last year. Maybe started him thinking about finality layers

<sgp_> Thanks Rucknium. Yes, I have an update on Helios-Selene

<sgp_> First, thanks to the community here for supporting the review of the curve selection, and of course a huge thanks to tevador for proposing the initial parameters and reviewing the latest discussions

<kayabanerve:matrix.org> We can discuss it over email or here. Veridise noted our elliptic curves had am error in the selection script causing us to have to selected the third candidate, not the first, by accident. tevador corrected their script and issued a new gist above.

<kayabanerve:matrix.org> One note is Veridise was also unhappy with our lack of twist security, despite the several reasons it's irrelevant, for the theoretical attack surface _and_ for the lack of reason _not_ to have a secure twist (as a later choice is functionally equivalent, with sufficiently-secure twist).

<kayabanerve:matrix.org> I'd lean towards adding the requirement of a secure twist primarily to appease reviewers (as we already have to change the curve's definition) and secondarily out of an abundance of caution.

<sgp_> ref: gist.github.com/tevador/4524c209217…ment_id=5772654#gistcomment-5772654

<sgp_> So in summary, the old proposed curves are out, and a new one will need to replace it. So a discussion needs to happen in the near future which ones should be picked. And there are arguably 3 options, depending on how much we care about twist security

As I said in the email, adding twist security would only be for show. It would have exactly zero practical impact on the implementation or the security of FCMP.

The original search conditions call for D = -1571315, which is what my gist is currenly using.

<kayabanerve:matrix.org> I largely agree BUT it the importance of show here is that we have a clearcut review, if we disagree with the reviewers on importance.

<kayabanerve:matrix.org> Even if we think this is unnecessary, it satisfies the review process _which is of its own merit_, and I see no reason _not_ to pick the identified option which is functionally equivalent albeit with a secure twist.

<rucknium> Downside of searching for parameters with twist security? Will this affect stressnet performance in any meaningful way?

<kayabanerve:matrix.org> It does update our criteria, but we're already updating the chosen curve.

Downside: we'll probably need a new search script implementation. My sage script is too slow to reach the D values that provide twist security.

<kayabanerve:matrix.org> The only downside is that:

<kayabanerve:matrix.org> - We're adding a meaningless criteria due to peer pressure (pessimist view)

<kayabanerve:matrix.org> - We're changing our search criteria, but we're already changing the chosen result anyways

<kayabanerve:matrix.org> None of this is of meaningful consequence to the implementation nor of any consequence to the performance

<kayabanerve:matrix.org> tevador: They're only 5x bigger IIRC

<kayabanerve:matrix.org> We can just run it 5x as long /s but not /s

<jberman> One marginal benefit may be that others may have desire to use the curves for some other reason, and twist security may be relevant for them, which may lead to greater adoption / higher scrutiny on the libs

About 20x bigger.

<kayabanerve:matrix.org> One moment

Than the correct one.

-1.5M vs -30M

<kayabanerve:matrix.org> We prior chose

<kayabanerve:matrix.org> 7857907

<kayabanerve:matrix.org> We're now discussing

<kayabanerve:matrix.org> 31750123

<kayabanerve:matrix.org> That's 4x bigger that the prior choice.

or 92M was the other option.

<kayabanerve:matrix.org> The fact the new selection is 5x faster to find shouldn't be considered relevant at this the IMO.

<kayabanerve:matrix.org> Clarifying: finding curves only matters to reproduce our academia and justify our decision.

I think my original search ran for 1-2 days btw.

With 8 or 16 cores? Not sure.

Veridise seem to have a faster implementation.

<kayabanerve:matrix.org> So it'll take a week in the future. That's unfortunate but acceptable.

<sgp_> Nothing else from me on this, other than to say if this interests you, please let me know. I'll keep talking with these two after the meeting

<rucknium> Can this be run on the Monero Research Computing Cluster?

<rucknium> Or just a single machine on that cluster?

Also adding "useless" search conditions can be seen as weakening the rigidity.

It would also be possible to remove the Crandall condition (which AFAIK we are not using anyways), then the result would be D = -15203.

<rucknium> I will end the meeting here. Feel free to continue discussing. Thanks everyone.

<sgp_> Thanks rucknium

<kayabanerve:matrix.org> No, current reductive algorithms take advantage of how 2**256 is congruent to a 128-bit value.

<kayabanerve:matrix.org> I agree adding arbitrary conditions weakens rigidity. I don't believe this is reasonable to declare so arbitrary.

OK. So I think we can narrow it down to -1571315 or -31750123.

<kayabanerve:matrix.org> Agreed

<articmine> @jeffro256: ... and how do you propose to tell ham and spam apart?

<articmine> The answer is you can't.

<articmine> What has worked is the current fees.

<jeffro256> The same way we've done it before: with fee pricing. We assume that spam is not "worth it" after a certain monetary amount, even though we can't actually discern spam. Generally, I think that we should penalize miners who expand the blocks past the current average weight. The miners will pass those costs onto the transaction c [... too long, see mrelay.p2pool.observer/e/xueFt7gKLUZkOHhE ]

<articmine> Which is why I am not going to support a penalty free zone below 100x the reference transaction size. This is the current situation and it just works.

<jeffro256> Increasing the minimum penalty free zone is sort of orthogonal here, is it not? The actual limit doesn't really affect the argument AFAICT; we should either be pricing transactions as a quadratic function of their weight, or as a quadratic function of the total expected txs weights in a block.

<articmine> @jeffro256: Which is what my proposal does. If we kept the maximum number of inputs at 8 or less, as was originally proposed then we could have kept the old way.

<articmine> The only reason it has worked in the past is because we were way below the penalty free zone, so uneconomic large transactions got mined.

<articmine> If a node relays transactions that are not economical to mine, and we are close to the top of the penalty free zone, we are simply setting up the stage for DDDS attack with perfectly valid not economical transactions.[... more lines follow, see mrelay.p2pool.observer/e/5-3Gt7gKcG5iZGs2 ]

<articmine> Of course the miners get penalized for growing the block weight. This does not change. Of course users are incentivized to consolidate transactions. This now works because those consolidated transactions will get mined

<articmine> The fee per input for my proposal once the membership proof weights are factored in is now lower for a larger number of inputs. This was not the case before if we were close to or above the penalty free zone

<articmine> I am for keeping fees to the minimum requirement for scaling.

<articmine> What my proposal does is reduce the penalty for the large transactions not increase the fee

<hinto> @boog900:monero.social @jeffro256:monero.social: sorry, missed the meeting, I am the one interested in PoWER

20:54:02 <br-m> <rucknium> DataHoarder: Could you discuss your empirical findings about Qubic's selfish mining profitability?

<hinto> for per connection PoW, can't an attacker build up connections then start spamming high input transactions practically for free?

<boog900> @hinto: we disconnect on the first invalid tx

the TL;DR: they were 82% efficient when selfish mining, but they improved and got 90% efficient. Efficiency was calculation of how good selfish mining they were doing

<hinto> the transactions being spammed are all valid

basically, they lost more overall than if they'd be mining straightforward. they have been doing that recently and their earnings have increased

<hinto> won't nodes with high connection counts have a disproportionate amount of new load?

monero had a 5% edge on pure earnings compared if qubic was mining directly

<boog900> @hinto: PoW is only protection against invalid txs

<boog900> otherwise fee/cost to build the tx is the protection

now that they are not doing selfish and they fixed some of their block delays, their efficiency is close to 100% and get very few orphans

before even when not doing selfish they got orphaned a lot

<boog900> @hinto: PoW in only done for outbound connections, inbound you only have to verify which is very cheap

last two days they only had one orphan, comparable to normal Monero network rates

<hinto> what is the challenge? if it is time bounded and invalid PoW causes a ban, won't time gaps between nonces have to be accounted for?

<boog900> @hinto: I think the handshake response message should include some random challenge bytes and then the peer should optionally respond with a PoW message if they want to send txs with more than 8 inputs

<boog900> the PoW message being a new P2P message

<hinto> and for RPC?

<hinto> @boog900: what about nodes that relay frequently e.g. exchanges?

<boog900> @hinto: I guess something similar, maybe 2 new endpoints for the challenge and the response?

<boog900> @hinto: as long as the txs are valid it should be fine

<boog900> PoW is only done per connection not per tx