13:54:21 <UkoeHB> meeting ~3hr (due to daylight savings time it is 1hr forward now): https://github.com/monero-project/meta/issues/674
16:11:39 <rbrunner> Well, as we meet at a UTC time, meeting time today is different only for the US; Europe switches a bit later to DST, to make stupidity complete
16:16:53 <coxring> lol.
16:23:19 * fundiswithsifu[m uploaded an image: (191KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/RHlShyZKEpqioUyclEbzZyqM/ima_8da74c0.png >
16:24:54 <fundiswithsifu[m> Triptych is coming right
16:24:54 <fundiswithsifu[m> What about seraphis? How is its development or no plan of integration yet?
16:25:58 <moneromooo> Heh. I almost commented that UTC should be used to do away with the "1 hr change" bullshit :D
16:26:08 <rbrunner> That's outdated and waiting for a kind soul that updates it. Tryptich is out, and Seraphis is probably coming.
16:30:16 <UkoeHB> fundiswithsifu[m: you can check the status of seraphis here https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290
16:33:11 <fundiswithsifu[m> What does “tryptich is out” mean? Finish? Canceled for seraphis?(I don’t get the phrase, as English is not my first language)
16:33:19 <fundiswithsifu[m> UkoeHB: Thank
16:33:37 <UkoeHB> triptych won't be implemented
16:35:23 <moneromooo> Won't be included in monero - it was actually implemented.
16:36:12 <moneromooo> I think... wownero is actually using it ?
16:38:48 <coxring> moneromooo: no, wownero is not usying triptych, at least not on mainnet. wowario did just a few testing txs. on testnet with different ring sizes.
16:39:11 <moneromooo> Ah, thanks.
16:59:26 <wowario[m]> not on mainnet. we ran triptych with 1024 ringsize in a private testnet
17:01:04 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/674
17:01:04 <UkoeHB> 1. greetings
17:01:04 <UkoeHB> hello
17:01:28 <Rucknium[m]> Hi
17:01:33 <rbrunner> Hello
17:02:15 <wernervasquez[m]> Hello
17:02:46 <chesterfield[m]> Howdy
17:02:50 <reeemuru[m]> yo
17:04:10 <dangerousfreedom> Cheers
17:04:42 <UkoeHB> 2. let's do updates, what is everyone working on?
17:05:59 <Rucknium[m]> I am in the "If you see a good move, look for a better one" phase of OSPEAD research that isthmus suggested. I have learned a few things:
17:06:23 <UkoeHB> me: still on seraphis multisig; I discovered a multisig protocol flaw that I will quick-fix PR maybe today or tomorrow
17:07:11 <Rucknium[m]> 1) To date I have framed my proposed estimations in broad Loss Function terms. It is admittedly a bit ad hoc. However, turns out that it can fit in a much more specific and well-studied Minimum Divergence Estimator framework.
17:08:18 <UkoeHB> idk if anyone is interested, but I finally got aggregation-style multisig signing working, two years after first writing about it in ZtM2: https://github.com/UkoeHB/monero/blob/c9e916c60014321144b2522e5aa77608f973bc48/tests/unit_tests/seraphis_multisig.cpp#L183
17:08:21 <Rucknium[m]> Without getting too specific, I can use already-established theoretical results on Minimum Divergence Estimators for some benefits.
17:09:29 <rbrunner> Means somewhat less work?
17:10:00 <rbrunner> Or faster progress, if you like :)
17:10:25 <Rucknium[m]> 2) Maybe others are already aware of this framework, but I think overall Monero can be placed into the Local Differential Privacy (LDP) framework. What I find interesting about LDP is that it claims that you can prove that your privacy scheme is immune to both known and as-yet-undeveloped statistical/machine learning attacks.
17:11:04 <Rucknium[m]> rbrunner: Yes, a bit less work; more ideas about things to try; and more confidence in the end results.
17:11:33 <rbrunner> Nice.
17:12:10 <rbrunner> "I discovered a multisig protocol flaw". Was that introduced with your broad rewrite of multisig code?
17:15:50 <UkoeHB> No, it is a flaw in all cryptocurrency multisig that I know of. Basically it isn't safe to send funds to a multisig address unless you are confident that all participants have completed their multisig accounts (or can complete them). One player can complete their account but then a malicious player 'forgets' to send their last kex message to other participants... preventing them from completing their accounts (and hence 
17:15:50 <UkoeHB> making them unable to sign things).
17:17:03 <rbrunner> Hmm, yes. And something can get improved here?
17:17:06 <UkoeHB> The quick fix is to add a round where you get confirmation from all players that they have completed their accounts.
17:17:57 <rbrunner> Well, maybe from the minimum of signers that is necessary? E.g. 2 in 2/3?
17:17:58 <UkoeHB> The fix that is friendly to UX of escrowed markets (i.e. doesn't add a round)... is kinda hairy.
17:19:17 <UkoeHB> rbrunner: no, you need all participants since the 'security guarantee' of multisig is you can have up to `min(M, N - M + 1)` dishonest participants
17:20:17 <UkoeHB> if you just check one other player in 2-of-3, that might be the dishonest guy who can block you
17:21:07 <rbrunner> Looks like it. I have to think about it. I am little afraid that such a "confirmation" round can have other, unintended and unfortunate consequences
17:21:18 <rbrunner> but can't play my finger on it yet
17:21:35 <rbrunner> *place
17:21:43 <UkoeHB> it sucks for UX, but can be enforced as an invariant in the multisig account implementation
17:23:12 <Rucknium[m]> UkoeHB: Do you think this will be required as a blockchain consensus rule, or be a wallet-level requirement?
17:23:27 <UkoeHB> it is wallet-side
17:24:03 <rbrunner> I wonder whether this risk is really worth mitigating. We have other such fundamental risks, e.g. you paying into a 2/2 multisig and your partner walking away
17:24:54 <rbrunner> Funds locked forever
17:25:09 <UkoeHB> yes I think it's a hole that would make a lot of the other work pointless
17:26:04 <UkoeHB> N-of-N is not affected, since you can't reduce the 'dishonest participant' assumption below 1 player
17:26:36 <UkoeHB> it affects M-of-N, where your security assumption falls from `min(M, N - M + 1)` to 1
17:27:37 <UkoeHB> to be clear, there are two security assumptions: 1) dishonest can spend funds (need `M`), 2) dishonest can block all signatures (need `N - M + 1`). It's the second one that is reduced to `1` by this flaw.
17:29:53 <rbrunner> Will this technically "look" like 1 more key exchange round? So that handling does not change too much?
17:29:59 <rbrunner> Just getting more tedious still
17:30:07 <UkoeHB> yes
17:30:45 <rbrunner> Alright, does not sound too bad then
17:30:49 <UkoeHB> for 2-of-3 escrowed markets, there are some workarounds that avoid the extra round
17:31:41 <rbrunner> Well, you have to fully automate anyway for a viable and end-user friendly solution. Think Haveno. Thus I would not worry too much, I would say right now
17:32:02 <rbrunner> But tomorrow I claim the opposite :)
17:32:16 <UkoeHB> the workarounds just adds a footgun to the interface, which isn't ideal
17:33:28 <UkoeHB> anyway, we can move on
17:33:37 <UkoeHB> 3. discussion - any other topics to discuss?
17:35:02 <Rucknium[m]> I would like to collect information on nonstandard Monero decoy selection algorithms. I am not good at finding and interpreting code in various languages, though, so maybe there are people here that could volunteer to help :)
17:35:27 <UkoeHB> do you mean algorithms that have been used?
17:35:30 <Rucknium[m]> I can't even figure out how MyMonero does it :/
17:35:54 <Rucknium[m]> UkoeHB: Yes. Basically, ones that have been used in the last two years
17:36:13 <rbrunner> I think they use `wallet2.cpp` compiled / transpiled either to JavaScript or WASM, thus standard
17:36:34 <Rucknium[m]> I suppose I also want to have the very old standard ones, like triangular, since some wallet software out there may be using really only "standard" code
17:37:45 <Rucknium[m]> There are also some wallets that are closed source as a whole, like Exodus, but have the Monero part open source, I think. I also couldn't figure out what Exodus was doing.
17:38:39 <Rucknium[m]> It is important to assemble a catalogue of all decoy selection algorithms that is as complete as possible.
17:39:44 <rbrunner> I try to get an overview for all wallets right now, for my "No wallet left behind" push. I can report if I find something non-standard. 0 zero far, however
17:40:42 <Rucknium[m]> rbrunner: Thank you :)
17:43:32 <Rucknium[m]> Ok I made an issue to start organizing the info:
17:43:32 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/99
17:48:43 <UkoeHB> any more last-minute topics to discuss? otherwise we can call it here
17:49:23 <UkoeHB> shameless plug: my seraphis wallet poc ccs has moved to funding https://ccs.getmonero.org/funding-required/
17:53:43 <SerHack> thanks for the meeting
17:58:19 <UkoeHB> ok guess we are done, thanks for attending everyone
18:05:51 <garth> Posted your CCS in Reddit ukoeHB
18:06:43 <UkoeHB> garth: thanks :)
19:20:09 <xmr-ack[m]> Donated
20:02:50 <UkoeHB> zarcanum paper updated to include a bulletproof scheme that supports range proofs on double-blinded amount commitments (commitments with 2 blinding factors on two separate generators): https://eprint.iacr.org/2021/1478
21:07:10 <garth> Can we use the switch to the Seraphis implementation as a moment to depreciate tx_extra and further increase fungibility? Or did the community decide to keep it?
21:11:03 <rbrunner> I remember at least 1 serious push to get rid of it, with much and long discussion, which however did not result in the necessary consensus to eliminate it
21:11:51 <UkoeHB> We could, but I have argued against it before "It's important that the extra field remain open ended to maintain flexibility in the face of an unknown future.". I have already implemented this: https://github.com/monero-project/research-lab/issues/61 here https://github.com/UkoeHB/monero/blob/41447f02a5fb40cd7b576264f2bb7643b3f9a1a0/src/seraphis/tx_validators.cpp#L216
21:53:48 <slave_blocker> hello :)
21:54:29 <slave_blocker> i know this is not the place for this question, but i am going to ask it anyway :
21:54:58 <slave_blocker> does zcash still use a trusted setup ?
23:15:04 <BusyBoredom[m]> Yep, halo 2 is still a WIP.