meeting ~3hr (due to daylight savings time it is 1hr forward now): monero-project/meta #674

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

lol.

Triptych is coming right

What about seraphis? How is its development or no plan of integration yet?

Heh. I almost commented that UTC should be used to do away with the "1 hr change" bullshit :D

That's outdated and waiting for a kind soul that updates it. Tryptich is out, and Seraphis is probably coming.

fundiswithsifu[m: you can check the status of seraphis here repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290

What does “tryptich is out” mean? Finish? Canceled for seraphis?(I don’t get the phrase, as English is not my first language)

UkoeHB: Thank

triptych won't be implemented

Won't be included in monero - it was actually implemented.

I think... wownero is actually using it ?

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.

Ah, thanks.

not on mainnet. we ran triptych with 1024 ringsize in a private testnet

meeting time: monero-project/meta #674

1. greetings

hello

Hi

Hello

Hello

Howdy

yo

Cheers

2. let's do updates, what is everyone working on?

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:

me: still on seraphis multisig; I discovered a multisig protocol flaw that I will quick-fix PR maybe today or tomorrow

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.

idk if anyone is interested, but I finally got aggregation-style multisig signing working, two years after first writing about it in ZtM2: github.com/UkoeHB/monero/blob/c9e91…it_tests/seraphis_multisig.cpp#L183

Without getting too specific, I can use already-established theoretical results on Minimum Divergence Estimators for some benefits.

Means somewhat less work?

Or faster progress, if you like :)

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.

rbrunner: Yes, a bit less work; more ideas about things to try; and more confidence in the end results.

Nice.

"I discovered a multisig protocol flaw". Was that introduced with your broad rewrite of multisig code?

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

making them unable to sign things).

Hmm, yes. And something can get improved here?

The quick fix is to add a round where you get confirmation from all players that they have completed their accounts.

Well, maybe from the minimum of signers that is necessary? E.g. 2 in 2/3?

The fix that is friendly to UX of escrowed markets (i.e. doesn't add a round)... is kinda hairy.

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

if you just check one other player in 2-of-3, that might be the dishonest guy who can block you

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

but can't play my finger on it yet

*place

it sucks for UX, but can be enforced as an invariant in the multisig account implementation

UkoeHB: Do you think this will be required as a blockchain consensus rule, or be a wallet-level requirement?

it is wallet-side

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

Funds locked forever

yes I think it's a hole that would make a lot of the other work pointless

N-of-N is not affected, since you can't reduce the 'dishonest participant' assumption below 1 player

it affects M-of-N, where your security assumption falls from `min(M, N - M + 1)` to 1

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.

Will this technically "look" like 1 more key exchange round? So that handling does not change too much?

Just getting more tedious still

yes

Alright, does not sound too bad then

for 2-of-3 escrowed markets, there are some workarounds that avoid the extra round

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

But tomorrow I claim the opposite :)

the workarounds just adds a footgun to the interface, which isn't ideal

anyway, we can move on

3. discussion - any other topics to discuss?

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 :)

do you mean algorithms that have been used?

I can't even figure out how MyMonero does it :/

UkoeHB: Yes. Basically, ones that have been used in the last two years

I think they use `wallet2.cpp` compiled / transpiled either to JavaScript or WASM, thus standard

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

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.

It is important to assemble a catalogue of all decoy selection algorithms that is as complete as possible.

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

rbrunner: Thank you :)

Ok I made an issue to start organizing the info:

any more last-minute topics to discuss? otherwise we can call it here

shameless plug: my seraphis wallet poc ccs has moved to funding ccs.getmonero.org/funding-required

thanks for the meeting

ok guess we are done, thanks for attending everyone

Posted your CCS in Reddit ukoeHB

garth: thanks :)

Donated

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): eprint.iacr.org/2021/1478

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?

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

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: monero-project/research-lab #61 here github.com/UkoeHB/monero/blob/41447…src/seraphis/tx_validators.cpp#L216

hello :)

i know this is not the place for this question, but i am going to ask it anyway :

does zcash still use a trusted setup ?

Yep, halo 2 is still a WIP.