<j​effro256:monero.social> Would it be worth discussing some miscellaneous consensus rule changes for the v17 fork in tomorrow's meeting? monero-project/monero #9751

The third point is basically "make non rct outputs unspendable between now and whenever fcmp is live" ?

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

<d​oedl...:zano.org> @rucknium Are you aware of any estimates of the dollar cost for running 50% of RandomX nodes?

<o​frnxmr:monero.social> What?

<r​ucknium:monero.social> flip flop: You mean something like this by endor00 ? gist.github.com/endorxmr/a13dce62ae1ba4676a1ed0311d96bf07

<d​oedl...:zano.org> not exactly. of course its easy to culculate. just /may be/ someone cared to discuss this before. so, tx, if you are not aware of a academic discussion - nobody else will ;)

Assuming you mean 50% of the rx hash rate, it's basically half the block reward. So... 250 monero a day ish ?

Though if you are not mining now and want 50% of the hash rate by starting new miners, it'd be ~500.

<d​oedl...:zano.org> @rucknium Are you aware of any estimates of the dollar cost for running 50% of RandomX nodes hashrate?

miningrigrentals.com/rigs/randomx gives a good estimate

>= 1.7 BTC/day to match Monero hashrate at the moment, but they don't have enough rigs available to do that

<d​oedl...:zano.org> @rucknium : provocation aside, there is no FREE market. And you know that. Just look at the Ginni Index estimates. If it would be free, professionals would be more forthcoming. No need for a contest in the first place. Any professional will find this a mockery and the peanuts thrown around ridiculous. I bet you thought about joining Sarang and Moo more than one time.

<r​ucknium:monero.social> The optimization contest is on the MRL meeting agenda, starting on one hour. We can discuss then :)

<j​effro256:monero.social> Moneromoo: the third rule would reject v1 transactions at and after the height of the FCMP++ fork

<j​effro256:monero.social> Reject *new* v1 txs being added to the chain

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

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

<s​yntheticbird:monero.social> hi

Hello

<a​rticmine:monero.social> Hi

<c​haser:monero.social> hello

<j​effro256:monero.social> Howdy

<s​agewilder:unredacted.org> Hello

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

<r​ucknium:monero.social> me: Working on researching Autonomous System (AS) peer connection rules to reduce spy node risk. Also starting to learn Rust 🦀

<s​yntheticbird:monero.social> The last part is an incredibly great news

<j​effro256:monero.social> Me: Trying to integrate Carrot/FCMP++ transaction construction together

<j​berman:monero.social> me: continuing FCMP++ tx construction (filling out the pieces for FCMP++ in genRctSimple at the moment). Unfortunately I don't have tests to share for the FCMP++ optimization contest this week, got sucked into FCMP++ tx construction. Will prioritize test suites to advance the contest for next week's meeting

<r​ucknium:monero.social> 3) Prize contest to optimize some FCMP cryptography code.

<j​berman:monero.social> Nothing new to share from me this week on this front. Last week we discussed a few topics that perhaps we can bring up again today

<j​berman:monero.social> Setting up a repo to host the contest, bumping payouts, and proposing using the dev fund for payouts

<j​berman:monero.social> Any comments on those?

<c​haser:monero.social> flip flop had reservations regarding the size of the prizes I think

<r​ucknium:monero.social> Maybe sagewilder can comment, since they expressed interest in being a contestant IIRC

<s​agewilder:unredacted.org> No comments aside having the pleasure to hunt a bigger payout.

<r​ucknium:monero.social> xmrack: Are you very familiar with contests on Kaggle? Different domain, I know, but maybe you have some opinions about prize amounts and attracting talent.

Things like these? kaggle.com/competitions

<r​ucknium:monero.social> Yes

There seems to be a wide range of price sums ...

<s​yntheticbird:monero.social> maybe im too naive or optimistic but it really seems to me like the payout bump is already a good incentive

<s​yntheticbird:monero.social> is it still really that low to worry?

Say again, where does that price proposal stay?

<c​haser:monero.social> I think this was the latest proposal ^

<j​berman:monero.social> Initial proposal was 150 XMR for ec divisors 1st place, 50 XMR for helioselene 1st place. Last week I brought up raising to 500 XMR and 200 XMR respectively. I don't see comparable contests on Kaggle to form a constructive opinion on that

Thanks

<r​ucknium:monero.social> It's not just the prize, but also the number and quality of possible competitors that will affect a programmer's decision to enter the competition. If it's 500 XMR and I think I would have 1/5th probability of winning it, then my expected revenue is 100 XMR. Expected utility? That depends on risk preferences.

<j​berman:monero.social> fair. I think we can move on. I'll come back next week with stronger deliverables for the contest

My current gut feeling says that if we can indeed afford such sums we will be able to attract talent

<r​ucknium:monero.social> Sounds good. Thanks!

<r​ucknium:monero.social> 4) v17 hard fork consensus rules to reject nonzero unlock time, large tx_extra, and v1 unmixable sweep transactions. monero-project/monero #9751

<r​ucknium:monero.social> jeffro256: ^

<j​effro256:monero.social> Just wanted to ask if anyone would be opposed to these rules. The first two solidify relay rules we already have , and the third disallows v1 txs at the same time as FCMP++ txs

<r​ucknium:monero.social> I think they all sound good. Relay rules are leaky IMHO, so putting 1 and 2 as consensus is a good idea.

<r​ucknium:monero.social> There should be tests written to double check that those outputs in (3) can be spent by FCMP. Have they been written?

<c​haser:monero.social> I can't comment on #3, but #1 and #2 have been low hanging fruits, the advantage is obvious

I am not 100% sure about the 3rd rule. Just to confirm, nothing becomes unspendable with that after the FCMP++ hardfork, right?

There are just some limits *how* I can spend it.

In what kind of transactions

<j​effro256:monero.social> Yup, it just disallows *new* v1 transactions. The FCMP tree lets you spend all outputs, including pre-RingCT

<j​berman:monero.social> #1 and #3 sgtm. Since pre-RCT can be spent in FCMP++ proofs, no reason to allow unmixable rings anymore

Splendid. Nothing to say against all 3 rules from me

<j​berman:monero.social> #2 initially sgmt as well

<j​berman:monero.social> not yet, I don't have FCMP++ tx test yet. They'll be written

<j​effro256:monero.social> And what about enforcing sorted extra ?

<s​yntheticbird:monero.social> what is sorted extra ?

To get that extra micron towards tx uniformity despite having something in the tx_extra? :)

<j​effro256:monero.social> Tx_extra has values which are prefixes by a tag value. The core reference code sorts these values by tag value when constructing transactions. Koe proposed enforcing they are sorted by node rule

<j​effro256:monero.social> It wouldn't really help nonstandard tx_extra values, but it would help uniformity for bad wallet implementations that forget to sort

<r​ucknium:monero.social> That sounds good to me. Verification of the sort would be very quick, right?

<j​effro256:monero.social> A downside of this would be that it would take a hardfork to add new tag values

<j​berman:monero.social> An alternative to sorting would be to create dedicated types for the fields we currently use tx extra for, which imo seems a saner long-term path

<r​ucknium:monero.social> By "node rule" do you mean consensus or relay?

I dimmly remember to propose that as well, but jeffro256 was not immediately enthusiastic if I remember correctly

<j​effro256:monero.social> Either, it would be a hardfork for consensus , or a messy upgrade for relay

(Nothing that is standard for any transaction in tx_extra anymore. That's not really "extra")

<r​ucknium:monero.social> Why would a hard fork be necessary for a new field? Just have the new field byte be sorted properly, right?

<j​effro256:monero.social> Tx_extra fields are not self describing, which means adding a new tag means that the whole tx_extra is unparseable to old code

<r​ucknium:monero.social> Is this why we get "tx_extra not in standard format" warning in logs sometimes?

<c​haser:monero.social> if it's not self-describing, how can different implementations use different sorting?

<j​effro256:monero.social> Yes I believe so

<j​effro256:monero.social> The tag values are described in the format, but how each individual value is deserialized isn't described

<d​oedl...:zano.org> +1

<j​effro256:monero.social> The parsing code takes the first varint i n the buffer, and depending on that value , selects a different deserialization code

<j​effro256:monero.social> If the tag value isnt recognized, then it doesn't know when this value ends and the next begins, so the whole tx_extra is unparseable

Ah, that's the problem, there is no field length info?

<j​effro256:monero.social> Yeah basically

<a​ck-j:matrix.org> Rucknium: Re: kaggle

<a​ck-j:matrix.org> I’ve used it in the past but haven’t set up a competition. I can look into it as this sort of competition is a bit different like you mentioned. It would be ideal if we use Kaggle or something similar that handles the out sourcing of developers.

<j​effro256:monero.social> So code that enforces sorting wouldnt be able to happen new tag values, unless new tag values were length prefixed

<j​effro256:monero.social> s/happen/handle

<j​effro256:monero.social> I think we should hold off on it personally

<r​ucknium:monero.social> xmrack: Thanks. If you could get more info on best practices, that would be helpful :)

One argument more, if you ask me, for *not* putting any more essential and necessary standard tx info in there anymore

<c​haser:monero.social> is there anything imaginable (rationally useful) that current tags can't service?

<d​oedl...:zano.org> what is all this flexibility (used) for?

<c​haser:monero.social> rbrunner: +100. although that will require redesigning the tx format, which is a longer term effort.

I just had a flashback to almost interminable discussions back and forth over weeks regarding tx_extra :)

<r​ucknium:monero.social> IIRC, Serai is going to put something in tx_extra.

<c​haser:monero.social> it will

Well, if the core software stops to use it people can freely put there whatever they want, in whatever order, nobody cares

<j​effro256:monero.social> I will sat, tx_extra_nonce, an existing field, should work for their use case

<j​effro256:monero.social> Maybe

<c​haser:monero.social> IMHO only arguments against this are disabling something important/useful, and the risk that we don't know when we'll be able to fork next to rectify potential lack of foresight

<r​ucknium:monero.social> IIRC, koe didn't like deprecating tx_extra because changes in tx format would require a hard fork, so why did he suggest requiring it be sorted by tag? Or did he not consider that issue?

To put it bluntly, for me is starting to sort there instead of moving standard tx stuff out of it like the proverbial "polishing of a turd"

<c​haser:monero.social> I think sorting is a much smaller risk

<c​haser:monero.social> vs deprecating tx_extra

<c​haser:monero.social> rbrunner, I'm with you on that

I guess the issue really was to go towards tx conformity out of principle, even if it's a small step. I am not sure, but I think there also was a format requirement, including lengths to properly skip unknown stuff

<c​haser:monero.social> I've recently looked at issues regarding tx_extra and they were colossal in length. I am afraid redesigning the tx format may not fit into the HF timeline, considering the urgency of deploying FCMP++ to reduce harms to privacy. I may be wrong though!

<j​effro256:monero.social> He wanted the values to be in "TLV" format which encodes a length, so that regardless of the type, the consensus code can skip over it

How much stuff do we put in there anyway? I am only aware about something related to subadresses, some key material. One more field in the standard tx structure, and done already? No?

<s​yntheticbird:monero.social> Not very constructive but any estimates on HF date so far ?

<s​yntheticbird:monero.social> since chaser talked about timeline

<j​effro256:monero.social> rbrunner: transaction pubkeys and encrypted payment IDs

Ok, ok, two fields then. Is this really a problem, or only sheer inertia against changes in tx format after so many years?

<j​effro256:monero.social> Adding one more field into the transaction would require we bump the version to 3, and deal with the consensus logic there, or put the information in `rctSigBase` after the rct type is deserialized

<j​effro256:monero.social> Putting it in `rctSigBase` is weird in terms of organization, but would be pretty easy to do

I can't judge - is this significantly more and riskier work than starting to sort tx_extra and add a rule there?

<j​effro256:monero.social> jberman: what do you think about the `rctSigBase` idea? We're already modifying it for FCMP++

<j​effro256:monero.social> It would save us a few bytes versus putting it in extra

"is weird in terms of organization" tx standard stuff in tx_extra is also weird. Just saying :)

<d​oedl...:zano.org> that would keep the wallets out, right?

Oh, things even get a little bit smaller. Wonderful :)

<r​ucknium:monero.social> We are beyond the hour. Should this topic be rolled over into next week? I have an update on autonomous system (AS) spy node research too, but it's pretty long, so I'll hold it until next week.

<j​effro256:monero.social> I think it would save four bytes: 1 for the additional_tx_pubkeys tag, 1 for the additional_tx_pubkeys vector length, 1 for the tx_extra_nonce tag, and 1 for the internal encrypted payment id tag

<j​effro256:monero.social> Maybe five actually since we also save the tx_extra_nonce length value

<j​berman:monero.social> personally I would prefer to focus on the core necessary changes for the upgrade first and not try to make many changes at once. We had prior discussed bumping tx version a while back but landed on maintaining rctSigBase as is for simplicity of the upgrade. I would prefer to streamline the upgrade

<d​oedl...:zano.org> that would keep the wallets out, right? ("node rule")

<j​effro256:monero.social> Fair enough

<d​oedl...:zano.org> #1,2,3 are already big leaps

<j​effro256:monero.social> I think we discussed it enough for now. I'd like to hear about the ASN stuff

<j​effro256:monero.social> If someone objects to it, it can be re-opened

<r​ucknium:monero.social> Ok sure

<r​ucknium:monero.social> I read four papers on autonomous system (AS) selection for Tor.

<r​ucknium:monero.social> Tor's network threat modeling is more complicated than Monero's. Tor has three hops that make up a circuit, but Monero nodes are only aware of immediate peers on the network. A Tor client's routing decisions are affected by the bandwidth of relays, which are measured and reported. And the bandwidth is an explicit cost of a Tor adversary (not just IP address leasing), unlike a Monero adversary.

<r​ucknium:monero.social> Wan et al. (2019) "Guard Placement Attacks on Path Selection Algorithms for Tor"

<r​ucknium:monero.social> Oh, oops, let me put the agenda item

<r​ucknium:monero.social> 5) Research on Autonomous System (AS) peer connection rules to reduce spy node risk. monero-project/monero #7935

<r​ucknium:monero.social> This paper criticizes earlier papers that had designed Tor circuit selection algorithms that were supposed to reduce Tor's vulnerability to spying. The paper's point is that adversaries are free to change behavior, so your algorithm need to be resistant to the status quo in the network, but also defend against an adversary deliberately placing spy Tor relays in "vulnerable" parts <clipped message

<r​ucknium:monero.social> of the network. They suggest a "meta-algorithm" that tries to anticipate possible attacks on the circuit selection algorithm, given the network state and the economic costs that an adversary would incur when deploying any given strategy. To me, it looks like sort of a brute force algorithm.

<r​ucknium:monero.social> Rochet et al. (2020) "CLAPS: Client-Location-Aware Path Selection in Tor"

<r​ucknium:monero.social> Similar to Wan et al. (2019), but they use a more formal linear programming optimization algorithm and try to reduce client-to-destination latency.

<r​ucknium:monero.social> Jansen & Goldberg (2021) "Once is Never Enough: Foundations for Sound Statistical Inference in Tor Network Experimentation"

<r​ucknium:monero.social> This paper uses Shadow, a network simulator that has been under development for 15 years. Shadow executes actual application code instead of just being an abstraction. We could possibly use it to simulate the Monero network with `monerod` and/or `cuprate`, especially now that we have a machine with 1TB of RAM. The paper shows that you need to sample network behavior many times to <clipped message

<r​ucknium:monero.social> get a statistically valid measurement for your Tor network tests. It looks like a 1%-scale Tor is unreliable, but a 10%-scale is OK.

<r​ucknium:monero.social> Gegenhuber et al. (2023) "An extended view on measuring Tor AS-level adversaries"

<r​ucknium:monero.social> This paper tries to figure out which, if any, ASes could be a threat to Tor user privacy. They find that Hetzner theoretically poses the greatest threat. From some data I've seen, that's probably true for Monero, too. Many "honest" Monero nodes are hosted on Hetzner.

<r​ucknium:monero.social> I got a reply from Giulia Fanti, the lead author of the Dandelion++ paper ( ece.cmu.edu/directory/bios/fanti-giulia.html ). She said she hadn't read the Clover paper yet, but would take a look. Clover is an alternative to D++ that is supposed to have better privacy for nodes with closed inbound ports.

<r​ucknium:monero.social> She said that she doesn't have a good solution for the proxy node problem, but pointed me to her paper here that penalized peers that relay fewer transactions than honest peers: arxiv.org/abs/2205.06837

<r​ucknium:monero.social> I re-analyzed the transaction relay log data from last year, and there is no big difference between the volume of txs relayed by suspected spy node IP addresses and honest peers.

<r​ucknium:monero.social> She said she would think about it more. Best case scenario, she gets interested in it enough to write a paper and solve the problem for us :)

<r​ucknium:monero.social> At this point in time I am skeptical of the value of an AS diversity rule. I plan to sketch a basic economic model to see what bulk discount adversaries would have to get from leasing many IPs from the same AS, but in different subnets. Adversaries get a discount for leasing whole subnets, but Monero nodes already have a rule against connecting to nodes within the same /16 subnet <clipped message

<r​ucknium:monero.social> (same with Tor circuit building).

<r​ucknium:monero.social> Right now, I can think of a possible improvement to the /16 subnet diversity rule. (Maybe it already works like this, but I don't know where in the code the peer selection happens.) Instead of taking the candidate peer list and drawing a peer from it, then rejecting the peer if we have already connected to a /16 subnet sibling, do this: First randomly eliminate all peers but one t<clipped message

<r​ucknium:monero.social> hat are in the same /16 subnets from the candidate list. Then pick a peer from that reduced list (also discarding the peer if it violates the subnet sibling rule). That would reduce the probability that you select your next peer from the adversary's saturated subnet(s) in the first place.

<r​ucknium:monero.social> This revised algorithm would also reduce the probability of selecting honest nodes within the same subnet, e.g. nodes on VPSes.

<r​ucknium:monero.social> That's my update. Any comments or questions?

<j​effro256:monero.social> The threat from Hetzner being that they spy on network traffic, or take down the honest nodes?

<r​ucknium:monero.social> Either. My research focus is on spy node risk, but network partitioning, eclipse, and censorship are concerns, too

<d​oedl...:zano.org> "discarding the peer if it violates the subnet sibling rule" <- overdue

<j​effro256:monero.social> At first glance, that seems like a pretty sane rule: don't trust peers to not shill their subnet siblings. Could be an issue for many honest nodes on a single provider, but again, if we can trivially distinguish them as being centralized, then we shouldn't be over-picking them anyways

<r​ucknium:monero.social> It would help me if any C++ readers can confirm exactly how the /16 subnet rule works. Or point me to where in the code it does that and I could try to figure it out.

<d​oedl...:zano.org> "discarding the peer if it violates the subnet sibling rule" <- overdue

<d​oedl...:zano.org> "To me, it looks like sort of a brute force algorithm." <- it is. In the long run a Web Of Trust based approach is inevitable. That is already viable now, only requires community orga

<j​effro256:monero.social> Thanks for reaching out to Fanti btw

^ rucknium

<r​ucknium:monero.social> I also told her about the Chainalysis presentation's comments praising (in a way) Dandelion++. She hadn't heard about it and thanked me for sharing.

<r​ucknium:monero.social> Thanks, malinero

<j​effro256:monero.social> Does Dandelion++ factor in the length of outgoing connection time to the privacy model?

<r​ucknium:monero.social> AFAIK, no. IIRC, there isn't a big spread in how long connections last anyway. Let me see if I have the plot

<r​ucknium:monero.social> See Figure 14 on page 21: github.com/Rucknium/misc-research/b…d/pdf/monero-black-marble-flood.pdf

<r​ucknium:monero.social> Pretty concentrated around 25 minutes connection duration, but there are a few long-lived outliers.

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

<j​effro256:monero.social> Thanks everyone!

<s​yntheticbird:monero.social> thanks

<c​haser:monero.social> thank you all!

<a​rticmine:monero.social> Thanks

<a​ck-j:matrix.org> Is there a github issue describing the competition? I thought there was but cant find it jberman

<s​needlewoods:monero.social> there is this draft by kayaba github.com/kayabaNerve/fcmp-plus-plus-optimization-competition

<k​ayabanerve:matrix.org> Why? Checking the prior tag had lesser value than the next tag doesn't sound like it'd need a hard fork? Is it because you now require being able to fully decode the TX extra, and don't just yield the fraction recognizable?

<k​ayabanerve:matrix.org> Except the whole TX extra isn't unparseable. Only the remainder.

<k​ayabanerve:matrix.org> That leads into the question the value of sorting for this partial case. I don't care and would wait for the time we strongly type all wallet data (my advocacy) leaving TX extra arbitrary.

IIRC tx_extra have length field, with just one or two exceptions

so it's possible to parse them and skip over the unknown ones

<k​ayabanerve:matrix.org> sech1: The entire TX extra does. The individual tags aren't required to be Type Length Value. Some tags used by Monero are solely Type Value as length is fixed to type.

yes, some tags are known and have known length, but other tags are supposed to have length field

IIRC the sorting code assumes this

and if it can't find length, it says that sort failed

or maybe it fails when it sees an unknown tag - I don't remember

<k​ayabanerve:matrix.org> Except if it's an unknown tag, Monero would have to assume if it's supposed to have a length or not.

Pretty sure the sorting code does not assume this, and that is why it fails on unknown tags.

<k​ayabanerve:matrix.org> Right now, it fails on unknown tag.

<k​ayabanerve:matrix.org> (They aren't assumed to be length-prefixed)

<k​ayabanerve:matrix.org> Though failure is partial? Monero will yield whatever it does manage to read

well, new consensus rules can enforce the length field for all tags except the ones that have fixed length

<k​ayabanerve:matrix.org> jeffro256: FYI, monero-wallet uses Nonce(127). It's the highest Nonce type which won't be interpretable as a multi-byte varint.

<k​ayabanerve:matrix.org> As long as wallet2 doesn't introduce Nonce(2 ..= 126), and then finally its own Nonce(127), we're fine.