<r​brunner7:monero.social> Meeting in 1 hour

thanks rbrunner

<j​effro256:monero.social> I'm very sorry, but I am going to have to skip this meeting, but I will be open for comments / questions the rest of the day.

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1331

<s​needlewoods_xmr:matrix.org> Hey

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

<r​brunner7:monero.social> We won't have jeffro with us in the meeting today, but available for comments and questions during the rest of the day.

<r​brunner7:monero.social> (for people reading along and being interested in the "OVK controversy" that bloomed on Reddit for the last 3 days.)

<r​brunner7:monero.social> Alright, what is there to report from last week?

<j​berman:monero.social> me: followed up on jeffro's unbiased hash to point review (about to push implementing his latest round of comments), and continuing now with boog's comment on my tx relay v2 changes PR

<r​brunner7:monero.social> I started to look into Polyseed, but did not yet get very far

<s​needlewoods_xmr:matrix.org> worked on review comments from rbunner here: monero-project/monero #10233

<s​needlewoods_xmr:matrix.org> continued with the wallet-rpc, you can open a wallet now

<s​needlewoods_xmr:matrix.org> and apart from my CCS, just out of curiosity, I based #10233 onto `fcmp++-alpha-stressnet`, there weren't too many conflicts and even though I just band-aided them without investigating, the whole thing built successfully, but I haven't tested that `monero-wallet-cli` yet, because my stagenet node is still ~25500 blocks behind.

<r​brunner7:monero.social> How is progress with the wallet-rpc? I suppose quite good, if you can already open wallets?

<s​needlewoods_xmr:matrix.org> It's still quite early, but I expect it go faster than the wallet-cli once I get momentum

<j​berman:monero.social> I spent a solid amount of time on this presentation to try and help with that fwiw: youtube.com/watch?v=dw6GKFhKKBE

<r​brunner7:monero.social> I see. Almost a classic now, no? :)

<r​brunner7:monero.social> Anyway, Matrix does not show me more new people joining this Matrix room than usual, which I almost expected

<s​pirobel:kernal.eu> there is outgoing viewkeys already in monero-oxide

<s​pirobel:kernal.eu> just wild what people post on twitter

<r​brunner7:monero.social> Ah, it spilled over there?

<r​brunner7:monero.social> Have a link?

<s​pirobel:kernal.eu> i thought it came from there

<s​pirobel:kernal.eu> no i just saw it glancing at the time line

<s​pirobel:kernal.eu> dont go there often because its all nonsense lol

<r​brunner7:monero.social> Avoid the brain rot and contamination

<r​brunner7:monero.social> Ok, will do.

<r​brunner7:monero.social> I confess I don't know much yet about that "tx relay v2". When and how is that scheduled to get the necessary rigorous testing? And can tx relay v2 and tx relay v1 coexist, will daemons "speak" both?

<j​berman:monero.social> ofrn has been running it on some nodes for quite a bit of time. I'd like to see it on stressnet (definitely on beta at least)

<s​needlewoods_xmr:matrix.org> iirc datahoarder shared this response from fluffypony xcancel.com/fluffypony/status/2015684629479510514

<d​atahoarder:monero.social> it's a lost channel tbh :)

I shared it privately via DM, but yes. fluffypony also has received DMs and also helped combat this

<j​berman:monero.social> it's still in code finalization stages I'd say though, very close to the finish line on that front

<r​brunner7:monero.social> You mean "lost" as in "truly and utterly irrelevant" :)

<j​berman:monero.social> "And can tx relay v2 and tx relay v1 coexist, will daemons "speak" both?" -> yes, though I'd argue it could make sense to deprecate v1 after the hard fork

there's also another one - where FCMP++ context (no output tracking, no rings) also helps get the point across

<r​brunner7:monero.social> Somehow nice to see that Fluffypony still watches things Monero

also has received DMs -> also has received similar questions (in public)

<r​brunner7:monero.social> Mostly for nostalgia however, on my side

well they get directly messaged about it

<r​brunner7:monero.social> Like that meme where you get prodded with a stick "Do something"

<j​berman:monero.social> (granted, this presentation was given with the context of Seraphis 128-input rings front of mind, although it does address the hypothetical of fcmp's as well)

<r​brunner7:monero.social> I see

<r​brunner7:monero.social> So the fact that daemons will support both relay protocols will of course make testing much easier.

<r​brunner7:monero.social> Alright, more reports, or more comments about OVKs?

<s​pirobel:kernal.eu> sounds a bit similar to fluffly blocks vs initial block sync path ... good to only have one code path

<r​brunner7:monero.social> In the mid-term, certainly. A hardfork is a good chance there.

<j​berman:monero.social> yep, it's being implemented in a very similar way too for initial rollout: compiled in support flags so updated daemons speak v2 with each other, but can speak v1 with daemons not yet running v2

<r​brunner7:monero.social> One more thing that the Cuprate people need to implement ...

<j​berman:monero.social> I should say, has been implemented* that way by 0xfffc

<j​berman:monero.social> boog900 has been very active in helping shape design from the start, so they're well aware

<s​pirobel:kernal.eu> what is the thought on potential for netsplits, blocks getting accepted on one, but not on the other

<j​berman:monero.social> I agree that it's better to deprecate sooner rather than later to avoid that potential

<j​berman:monero.social> but obviously, you can't deprecate on initial rollout because that would cause a netsplit

<j​berman:monero.social> hence, deprecating after the fork I think is a solid goal

<r​brunner7:monero.social> "blocks getting accepted on one, but not on the other" That could only happen if some daemons come to miss some transactions altogether?

<r​brunner7:monero.social> Ah, no, not even then, because the blocks **are** the way transactions get known of course

<r​brunner7:monero.social> The pool can be seen as a nice add-on, but not strictly necessary I guess

<s​pirobel:kernal.eu> if there are multiple code paths that do serialization / processing logic slightly different you can craft a block / transaction in a block that make one set of nodes accept the block, while the others dont.

<r​brunner7:monero.social> jberman: Just to be sure, with "deprecate" you mean "stop to support", not "marked for stopping support soon, be warned"?

<s​pirobel:kernal.eu> can someone link to the tx relay pr?

<s​needlewoods_xmr:matrix.org> seraphis-migration/monero #184

<j​berman:monero.social> I think there is a case for stopping supporting tx relay v1 after the fork

<j​berman:monero.social> and there is a followup PR to that one here: 0xFFFC0000/monero #63

<r​brunner7:monero.social> Hmm. Couldn't people running on pre-fork daemons build their own network without knowing it, so to say?

<j​berman:monero.social> and then eventually that will all get rolled up into the tx relay v2 PR to the main monero repo here: monero-project/monero #9933

<j​berman:monero.social> can you expand the scenario you're stating here?

<r​brunner7:monero.social> Maybe it does not make sense. Old daemons will still be able to exchange blocks with each other, and sync blocks from each other, right? They just won't see any transactions anymore. So they won't be cut off and will only find old daemons to peer with.

<r​brunner7:monero.social> *pool transactions

<r​brunner7:monero.social> I mean, I can sync with an old daemon up to the hardfork block.

<r​brunner7:monero.social> New tx relay protocol or not.

<j​berman:monero.social> Before the fork: old daemons will still receive new pool txs using the v1 protocol from both old and new daemons

<r​brunner7:monero.social> Yes, and after the fork, with v1 protocol off for almost all active daemons, the old ones are still not cut from the network, but just cut from the tx pool

<r​brunner7:monero.social> Alright. Anything else to discuss today?

<j​berman:monero.social> The goal is to release tx relay v2 either with the hard fork v19 daemon, or in an earlier release version than that so that it's definitely included no matter what in first v19 daemon release. The v19 daemon therefore would by default communcate tx relay v2 with other v19 daemons. After the fork, once v1 tx relay is deprecated, all the older nodes should already be cut off from th<clipped messag

<j​berman:monero.social> e network anyway beacuse they don't know the new v19 consensus protocol

<p​lowsof:matrix.org> just for visibility: koe says he aims to be back mid Jan early Feb repo.getmonero.org/monero-project/c…als/-/merge_requests/384#note_33802

<r​brunner7:monero.social> I think I can describe a more concrete scenario: After the hardfork, you find some old pre-hardfor daemon version for download and start to use that. Nothing really bad will happen, except that syncing stops at the hardfork block. What won't happen is that such daemons accidentally form their own, private Monero network without noticing it.

<s​pirobel:kernal.eu> slightly related: seraphis-migration/monero #159/changes how would this change improve block propagation speed? saw it mentioned here: seraphis-migration/monero #139

<r​brunner7:monero.social> Thanks for the reminder, plowsof. Might get interesting!

<j​berman:monero.social> the latter will happen regardless of the tx relay protocol

<j​berman:monero.social> missed that, I'll respond there

<s​pirobel:kernal.eu> this intersects in the sense that adding of the blocks / deciding to reorg happens based on fluffy blocks vs the initial block sync path. maybe the old nodes would just fall back to the initial block sync

<r​brunner7:monero.social> "the latter will happen regardless of the tx relay protocol" Not sure I understand, but it's probably not important, and my brain will click in due course anyway :)

<r​brunner7:monero.social> Ok, let me close the meeting proper. Room is open of course. Thanks everybody for attending, read you again next week!

<s​pirobel:kernal.eu> the hardfork introduces other changes too so if they dont update the tx relay is the least of their problems

<s​needlewoods_xmr:matrix.org> Thanks everyone, cu

<s​pirobel:kernal.eu> thanks

<j​berman:monero.social> after the v19 fork block has passed, v18 nodes that haven't updated will likely form their own network communicating with other v18 nodes, regardless of tx relay protocol