17:01:42 r​brunner7:monero.social: Meeting in 1 hour
17:02:39 plowsof: thanks rbrunner
17:06:48 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.
18:00:01 r​brunner7:monero.social: Meeting time. Hello! https://github.com/monero-project/meta/issues/1331
18:00:09 s​needlewoods_xmr:matrix.org: Hey
18:00:39 j​berman:monero.social: *waves*
18:01:19 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.
18:02:22 r​brunner7:monero.social: (for people reading along and being interested in the "OVK controversy" that bloomed on Reddit for the last 3 days.)
18:02:53 r​brunner7:monero.social: Alright, what is there to report from last week?
18:02:55 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
18:03:07 r​brunner7:monero.social: I started to look into Polyseed, but did not yet get very far
18:03:11 s​needlewoods_xmr:matrix.org: worked on review comments from rbunner here: https://github.com/monero-project/monero/pull/10233
18:03:15 s​needlewoods_xmr:matrix.org: continued with the wallet-rpc, you can open a wallet now
18:03:46 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.
18:04:16 r​brunner7:monero.social: How is progress with the wallet-rpc? I suppose quite good, if you can already open wallets?
18:06:00 s​needlewoods_xmr:matrix.org: It's still quite early, but I expect it go faster than the wallet-cli once I get momentum
18:07:29 j​berman:monero.social: I spent a solid amount of time on this presentation to try and help with that fwiw: https://www.youtube.com/watch?v=dw6GKFhKKBE
18:08:22 r​brunner7:monero.social: I see. Almost a classic now, no? :)
18:09:17 r​brunner7:monero.social: Anyway, Matrix does not show me more new people joining this Matrix room than usual, which I almost expected
18:09:22 s​pirobel:kernal.eu: there is outgoing viewkeys already in monero-oxide
18:09:56 s​pirobel:kernal.eu: just wild what people post on twitter
18:10:09 r​brunner7:monero.social: Ah, it spilled over there?
18:10:15 r​brunner7:monero.social: Have a link?
18:10:23 s​pirobel:kernal.eu: i thought it came from there
18:10:32 s​pirobel:kernal.eu: no i just saw it glancing at the time line
18:10:45 s​pirobel:kernal.eu: dont go there often because its all nonsense lol
18:10:57 r​brunner7:monero.social: Avoid the brain rot and contamination
18:11:12 r​brunner7:monero.social: Ok, will do.
18:11:16 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?
18:11:53 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)
18:11:59 s​needlewoods_xmr:matrix.org: iirc datahoarder shared this response from fluffypony https://xcancel.com/fluffypony/status/2015684629479510514
18:12:07 d​atahoarder:monero.social: it's a lost channel tbh :)
18:12:39 DataHoarder: I shared it privately via DM, but yes. fluffypony also has received DMs and also helped combat this
18:12:47 j​berman:monero.social: it's still in code finalization stages I'd say though, very close to the finish line on that front
18:12:49 r​brunner7:monero.social: You mean "lost" as in "truly and utterly irrelevant" :)
18:13:01 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
18:13:04 DataHoarder: there's also another one - where FCMP++ context (no output tracking, no rings) also helps get the point across
18:14:02 r​brunner7:monero.social: Somehow nice to see that Fluffypony still watches things Monero
18:14:04 DataHoarder: also has received DMs -> also has received similar questions (in public)
18:14:12 r​brunner7:monero.social: Mostly for nostalgia however, on my side
18:14:15 DataHoarder: well they get directly messaged about it
18:15:38 r​brunner7:monero.social: Like that meme where you get prodded with a stick "Do something"
18:16:34 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)
18:17:15 r​brunner7:monero.social: I see
18:18:20 r​brunner7:monero.social: So the fact that daemons will support both relay protocols will of course make testing much easier.
18:19:14 r​brunner7:monero.social: Alright, more reports, or more comments about OVKs?
18:19:56 s​pirobel:kernal.eu: sounds a bit similar to fluffly blocks vs initial block sync path ... good to only have one code path
18:20:31 r​brunner7:monero.social: In the mid-term, certainly. A hardfork is a good chance there.
18:20:54 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
18:21:37 r​brunner7:monero.social: One more thing that the Cuprate people need to implement ...
18:21:39 j​berman:monero.social: I should say, has been implemented* that way by 0xfffc
18:22:22 j​berman:monero.social: boog900 has been very active in helping shape design from the start, so they're well aware
18:24:06 s​pirobel:kernal.eu: what is the thought on potential for netsplits, blocks getting accepted on one, but not on the other
18:25:07 j​berman:monero.social: I agree that it's better to deprecate sooner rather than later to avoid that potential
18:25:35 j​berman:monero.social: but obviously, you can't deprecate on initial rollout because that would cause a netsplit
18:26:00 j​berman:monero.social: hence, deprecating after the fork I think is a solid goal
18:26:52 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?
18:27:23 r​brunner7:monero.social: Ah, no, not even then, because the blocks **are** the way transactions get known of course
18:28:22 r​brunner7:monero.social: The pool can be seen as a nice add-on, but not strictly necessary I guess
18:30:10 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.
18:30:26 r​brunner7:monero.social: jberman: Just to be sure, with "deprecate" you mean "stop to support", not "marked for stopping support soon, be warned"?
18:31:07 s​pirobel:kernal.eu: can someone link to the tx relay pr?
18:31:35 s​needlewoods_xmr:matrix.org: https://github.com/seraphis-migration/monero/pull/184
18:32:47 j​berman:monero.social: I think there is a case for stopping supporting tx relay v1 after the fork
18:33:47 j​berman:monero.social: and there is a followup PR to that one here: https://github.com/0xFFFC0000/monero/pull/63
18:34:59 r​brunner7:monero.social: Hmm. Couldn't people running on pre-fork daemons build their own network without knowing it, so to say?
18:35:06 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: https://github.com/monero-project/monero/pull/9933
18:36:09 j​berman:monero.social: can you expand the scenario you're stating here?
18:37:29 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.
18:37:50 r​brunner7:monero.social: *pool transactions
18:38:39 r​brunner7:monero.social: I mean, I can sync with an old daemon up to the hardfork block.
18:38:53 r​brunner7:monero.social: New tx relay protocol or not.
18:39:53 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
18:41:53 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
18:43:16 r​brunner7:monero.social: Alright. Anything else to discuss today?
18:45:37 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
18:45:39 j​berman:monero.social: e network anyway beacuse they don't know the new v19 consensus protocol
18:46:46 p​lowsof:matrix.org: just for visibility: koe says he aims to be back mid Jan early Feb https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/384#note_33802
18:47:30 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.
18:47:52 s​pirobel:kernal.eu: slightly related: https://github.com/seraphis-migration/monero/pull/159/changes how would this change improve block propagation speed? saw it mentioned here: https://github.com/seraphis-migration/monero/issues/139
18:48:37 r​brunner7:monero.social: Thanks for the reminder, plowsof. Might get interesting!
18:48:57 j​berman:monero.social: the latter will happen regardless of the tx relay protocol
18:49:43 j​berman:monero.social: missed that, I'll respond there
18:50:00 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
18:51:14 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 :)
18:52:44 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!
18:53:10 s​pirobel:kernal.eu: the hardfork introduces other changes too so if they dont update the tx relay is the least of their problems
18:53:28 s​needlewoods_xmr:matrix.org: Thanks everyone, cu
18:53:32 s​pirobel:kernal.eu: thanks
18:55:48 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