When will multisig wallet loose it’s ‘experimental feature’ status? Are there still many known bugs or is it secure already?

#monero:monero.social

ofrnxmr[m]: Do you mean it’s better to ask the question there?

Yes

Thanks

Not to leave a question unabswered: It will be removed after multisig has gone through a full security analysis

ofrnxmr[m]: Is there a ongoing audit ?

Nope

I cant make it to today's meeting but from my side I started working in a transaction history component (drafted some basic ideas and started implementing it) and opened a [CCS](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/377). The plan is to build this component and integrate the knowledge proofs into the wallet using half of the time of the proposed CCS. The other half I would be working on

building necessary functions that needs to be done after discussing it in the #no-wallet-left-behind channel. I thank you for your comments.

Meeting .75hr

Shoot, I’m getting pulled into another meeting at the top of the hour. I may be able to drop into the MRL meeting later. Only two quick notes from my end:

(1) Geometry Labs produced a small workflow demo codebase showing how to connect R to C++, as part of gearing up to potentially contribute to OSPEAD computations. I will be chatting with Ruck about iterating the workflow and planned roadmap. We can skip talking about CCS today, as these discussions are ongoing and I’ll be updating the proposal.

(2) If tx_extra comes up, just want to reiterate my stance concisely: In the long run I will support any solution where the consensus rules / protocol / format results in a single anonymity pool of uniformly indistinguishable transaction. This includes, but is not limited to:

- removing tx_extra (in which case Monero’s scope is narrowed to store and transfer of value, i.e.making xmr just be a currency with no bells and whistles)

- a fixed-length encrypted field with consensus enforcement

(of course when I say “tx_extra” what I mean is not the literal field, but rather having a field designed for arbitrary data blobs)

Also, I am OK with relay rules as short-term measures, but never as a long-term replacement for consensus rules.

meeting time monero-project/meta #803

1. greetings

hello

Hi

Hello

Hello.

Hi

2. updates, what's everyone working on?

I posted a few updates about the new curve cycles, there are a few options available: monero-project/research-lab #100

Hi

Sent C++ test for R wrappers to isthmus. The returned code passed the tests. Exceeded expectations, in fact. Writing R code to gather ring data by RPC. Spent my allocated 8 hours on researching possible statistical tests of encrypted tx_extra contents. Made some progress on that, but not as much as I would have liked.

me: I merged dangerousfreedom's draft of seraphis knowledge proofs to seraphis_lib and updated it to production quality. Now I'm working on refactoring enote scanning into a state machine that will be more flexible/reusable in the long run. After this and further refactoring to use block checkpoints, I will work on the seraphis paper.

3. discussion, we are slated to discuss tx_extra some more today

Did any discussions happen between last meeting and this one? I didn't see any

Can we narrow down tx extra to A or B3?

Well, discussions went on right after the meeting

as a reminder, here is the choice matrix:

A) [remove tx extra]: tx utility flexibility tied to hardfork (or steganography)

B) [keep tx extra in some optimized form]: uniformity and scaling trade-offs depending on the solution

1) leave as unlimited-size TLV field

2) mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes) (option: encrypted by default)

3) mandate optional fixed-length tx extra size + encrypt by default

4) mandate fixed-length tx extra for all txs + encrypt by default

5) other

Can we just go ahead and vote. I vote for A. Get rid of it.

I prefer a vote to narrow down to A or B3 first

B3 sounds like a good compromise

With the few people here? That's a bit optimistic. We could vote, but the vote would probably get ignored ...

A means removing it for regular transactions, not for coinbase?

I see this problem as being a conflict between three of Monero's core design goals: privacy, scalability, and longevity.

sech1: yes, coinbase would keep it

A in the long term, B3 short term

B3 gives only 2 anonymity puddles

What is "long term" for you, sech1?

Seraphis fork

This decision is for the Seraphis fork.

then A

but if A, we need to gather all current uses of tx_extra

from all parties

Pre-Seraphis, we have this: monero-project/monero #8733

B3 would also probably need to gather all uses of tx_extra as some may exceed the fixed-length that B3 would install

UkoeHB: Isn't it Security, Privacy, and Decentralization? getmonero.org/resources/about

B3 256 bytes

We had 256 bytes on the table. Is something important known that would not fit?

Because I would, so far, gladly agree to narrow down to A versus B3 256 bytes for a vote

A means a permanent increase in the chance of future hardforks - increased power of the core team.

Rucknium[m]: decentralization isn't really a property

it's just a fancy word that sounds good

the goal of 'decentralization' is longevity

We can vote for A or B3 256 Now Then announce the final vote between A and B3 256

B3 would also remove the ability for public data fwiw, which ew have now. Like "add this hash of some timestamped data".

Well, any such "public" service could publish their fixed key?

Does it affect atomic swaps in any way? Or Seraphis will fix it in another way?

No. You can have longevity with a totally centralized system. They're orthogonal.

AFAIK none of the atomic swap protocols for Monero need tx_extra.

good

rbrunner: may be hard to say, but for example this is a tx coming out of a CEX, where tx_extra has 323 bytes: localmonero.co/blocks/search/06b483…463d0f6715337f01fef9b4833bf12bedca2

By the way, I was brainstorming about a vote not in a particular meeting, but in a GitHub issue during one week, say

hbs[m]: this is due to the tx public keys, there are no extra data in that tx.

Because meetings tend to have attendance problems

We have to narrow this down first

Of course

"where tx_extra has 323 bytes" <- I think it's because of additional pubkeys (one per output)

they can be moved to a dedicated tx field

They are, in Seraphis, no?

tevador: Ok then, thanks for clarifying, I had not checkd the actual content, just checked the size.

Yes, Seraphis already separates tx pubkeys. tx_extra would be only for "extra" data then.

So we can maybe vote today what exactly we put up for a vote?

#define TX_EXTRA_MYSTERIOUS_MINERGATE_TAG 0xDE

the only thing I found about actual usage :D

coming from scam pool minergate

rbrunner: Yes

Something like a first derivative :)

Maybe we can agree that the options are A or B3. If we advertise the next meeting on reddit, hopefully more people will come.

I like B3 because it is an incremental improvement in privacy and longevity, and only a minor regression for scalability. The other options are more significant regressions in at least one property (other than 'do nothing').

I propose A or B3 256

Good lord, reddit...

Do we have a clear plan for implementation of B3 256? Has monerod ever changed the criteria for relaying transactions outside of a hard fork?

Im solidly in group A

Perhaps should be noted that wownero HF's to 1kb limit soon

You can only vote today what we put up for a vote, seems to me

Well, we haven't yet voted whether there should be a vote.

I second ArticMine's A or B3 256 as the only two options to vote on

I do too.

B3 is my choice as well

For the update, I'm trying to make more tests to reveal more bugs in my code. I think it is ok. Will commit and push in the coming days for another round of reviews from koe

Rucknium[m]: we have PR #8733

I would expect that we would have a leaky sieve: many old version nodes would allow those tx. If the tx gets to a miner who is running an old version node, then the relay rules are ineffective

Voting whether having a vote is a bit circular ...

Rucknium[m]: there is not a concrete design for B3 yet, it would require some discussion.

A or B3 will be implemented with Seraphis, which is a mnadatory hard fork.

rbrunner: Being like the US system lol

It narrows down the debate

If we have, by any chance, an earlier hardfork still, we could introduce even earlier, if somebody goes the extra mile to modify the old tx format

It would be nice to see less discussion about voting and more focus on design goals/philosophy.

+1 koe

I am pretty sure that an analysis would show we have pretty much the same goals, but weight them differently, hence the long standstill

Because goals conflict in this case as I understand them

can't analyze comments that don't exist

I just do not see consensus possible for any other options

So we can narrow the field

A/B3 , can we agree that these are the goals? And progress from there

I'd rather have a consensus on the reasons for making a choice, than force a decision to be made.

Does anyone favor any other B apart from B3?

the people in favor of other options are not in this meeting

Hmm, looks like it

Rene appears to be the only one who did not have a vote for a or b3

I see 3 people there who did not specify either A or B3.

Yes, back then. I can easily compromise on B3 256, and would agree to vote on that.

+ "unwanted" and "blank"

Out of how many?

At least 20

tevador: thanks, I missed those 👍

So really like American politics? First round of voting with *all* options, open for 1 week, second round with the two top voted from the first round?

If we declare this meeting as not complete enough to decide what to vote on ...

I think the support for anything other than A or B3 is not there. We can narrow it down to A or B=B3.

tevador: That is my point

Now, the resident Core Team member could throw in his authority and announce a vote A versus B3 ... ?

In some way to discuss further

We can open a MRL issue with these two choices and schedule the final decision for the next meeting.

I think this whole thing is good evidence that being unable to operate without core is not healthy for the project in the long run.

This is not a core team issue

Maybe, but I think we still compare quite favorably with other projects. We don't routinely bumb into such difficult decisions like this one

*bump

We should be able as a group to narrow this down

Well, we don't miss much right now. Still nobody explicitely spoke out against putting up that vote.

being able to operate without centralized decision making * there

We could roll a d20.

The last digit of the hash of the next XMR block decides.

Come on, give yourself a jolt, if enough people agree on that vote, we have at least something :)

I remain more interested in design philosophy than voting.

I agree that A and B3 seem to be the best ones to choose from. Whether a vote is the best idea though, not sure.

The least bad idea? To break out of a 2 year checkmate situation?

UkoeHB: I see that question as flexibility without a hard fork

ArticMine[m]: yes

So let's open an issue for it, narrowed down to A or B(3). Some arguments for each choice will be gathered for the next meeting.

I support tevador 's plan

I understand UkoeHB interest in design philosophy, but frankly, I am afraid such discussion would be even more difficult

Btw, we can still have a soft fork with option A. It has been discussed before.

that just sounds lazy, we should not make decisions out of laziness

How does narrowing down the vote preclude the philosophy question

it's mostly a distraction, since philosophy logically precedes choice

notice how we wasted 40 minutes 'narrowing it down'

I guess UkoeHB thinks that the "right" philosophy would naturally decide the tx_extra question

We are at the end of the hour, so I'll call it here. We can tentatively narrow the choices to A/B3 pending further direction changes.

Well, I think this meeting was more than just a waste of time. If we really put up that issue, that is.

next meeting let's try to have more concrete arguments

thanks everyone

The fact that this has been open for 3 years proves that it's not something that has an easy "natural" answer.

I don't think we will be able to agree on that :)

(That 3 years "prove" something.)

rbrunner: What is the "natural" answer then? If you seem to think there is one.

Not exactly. I think we are in a messy situation, because humans, and that the way out is, unfortunately, a primitive vote

Some notes on using statistical tests to exclude non-encrypted tx_extra contents:

If we start to discuss overarching design goals, we get into each other's hair about *those*

The statistical power of a test is one minus the probability of type II error. Type II error is the probability of failing to reject the null hypothesis when the null hypothesis should be rejected. It's a false negative, basically. Many factors determine the power of a test, including the contents of the data itself. We would want the test(s) with the highest power.

how much space would B3 allow for?

A simple standard test for uniform randomness of discrete items is the chi-squared test. It only tests the _proportions_ of random items. If we test at the bit level, a chi-squared test would just evaluate the proportions of 1's and 0's. This test has low power because it does not evaluate the _sequence_ of bits. For example, "00001111" has a clear sequential structure, but an equal number of ones and zeros and would easily pass

a chi-squared test.

I tried the chi-squared test on isthmus's tx_extra list here: monero-project/monero #6668#issuecomment-670978771 . I converted the data into bits. At the 5% level of significance, it only rejected about 30% of the tx_extra contents as non-random.

ASCII characters have a clear sequential structure since the last bit of the byte is 0. File types like jpeg also tend to have a sequential structure. Compressed files may have a sequential structure sometimes (need to investigate further). More thorough tests of cryptographic randomness of sequences try to detect non-randomness in the sequential structure.

Here is where my research time expired. These more powerful tests do not have many easy-to-use implementations. And generally you need to give them some specific parameters that I don't fully understand. Some of the tests that I am looking at include: binary matrix rank test, book stack test, birthday spacings test. They tend to target cyclical non-randomness, which is what we would expect with ASCII, jpegs, and other file

format.

Interesting thanks Rucknium[m]

moneromooo: to me, longevity means persistence (long-lived) and consistency (continuing to satisfy the same invariants/promises over time). A centralized organization has the inherent *potential* to break longevity, even if it doesn't in practice. Since there is no way to know in advance if a centralized project will break longevity, decentralization is seen as a more effective strategy.

M7in[m]: probably 128-256 bytes per tx output

Did you encounter interesting examples in history that illustrate that, or is this more a result of logical reasoning?

Interesting that you mention "per tx output". I assumed, maybe wrongly so, fixed 256 bytes, period, independently of the number of outputs.

so-called constitutional republics are prime examples of broken promises

if it's encrypted, it has to be encrypted for someone to read

Yeah, but for example a DEX could use a single key for all tx_extra entries of transactions that go in and out. Doesn't have to mean encrypted per receiver.

wasn't there some monero fork that just recently announced it was watering down its privacy?

Not sure, there are not that many left as far as I know

rbrunner: that's not a generic solution

Anyway, with 256 bytes *per output* I easily make a 16-out tx, giving me room for my highly problematic 4 KB JPEG. That's no limit, man :)

The field could probably be bimodal. Either encrypted at 128 bytes per-output (for example) or the entire field encrypted with a custom scheme. When a user decrypts their enote's extra field, if the decrypted bytes don't conform to TLV format then the field is ignored.

Sorry for late response: group A

I was also assuming global, as currently. Per output optional means you leak more than one bit.

It's more adaptable though.

moneromooo: it would be either all outputs get a field or none

OK, seems fair given the high prevalence of 2 out txes.

rbrunner: ok, and where does your argument fit into the design philosophy framework?

Which argument exactly?

the implied argument that the goal is to stop arbitrary data from being put in the chain

What would be the purpose of a memo field on a change output of a 2-out tx?

tevador: for the case where you want to send a memo to yourself

You can make a self-send for that.

I don't follow, are you not supposed to send a memo to yourself in txs where you send funds to other people?

that seems like the primary use-case for a self-directed memo

Not sure I understand the question. I just weight serveral arguments pro and contra forbidding arbitrary data, and *my* *personal* sum is net positive for allowing a reasonable amount

The use case is "back it up on everyone's disks in case I lose my wallet cache" ?

Those arguments are all well known already and open on the table, I just weight a bit differently than other people

Why would a self-memo need to be recorded on the blockchain?

Your personal sum, UkoeHB, seems also to be net positive to allow some reasonable amount, as I currently understand

tevador: why would any memo need to be recorded? the point is we don't know

That is a false dichotomy.

It makes some sense in the case of the recipient. It doesn't make sense for the sender.

Anyway, my "design philosophy" for things I personally design includes "make it flexible, to be able to counter any unforseen problems"

So I have the tendency to want my XMR coming with some technical flexibility. I would probably not get consensus for that, I think.

If the option B3 was meant to be per-output, 64 bytes would be more in line with PR #8733 (~1K for 16 outputs). 2-out transactions could have just one 128-byte field for the recipient.

Regarding B3 - I agree with UkoeHB points around it being an incremental improvement in privacy.

However, I did note isthmus and sech1 voiceds concerns that if tx_extra is optional, it impacts transaction uniformity.

Granted, B3 would improve uniformity vs the status quo.

So I'm just wondering what the counter argument for the uniformity issue is? Is worry about an optional encrypted tx_extra field, a worry about nothing?

It leaks one bit. vs 0 for option A. vs... a lot more, but unquantified, for current state.

Well, it leaks one bit unless some jerk starts putting unencrypted stuff in it I suppose.

john_r365[m]: making it optional reduces the average tx size increase of moving to a fixed-size field. By itself, an optional fixed-size field leaks very little information if the field is encrypted.

More information may be leaked in tx tree analysis, if an enote with a memo is more/less likely to be spent in a tree containing relatively more/less memos.

However the strength of tx tree analysis is asymptotic in the ring size, so an optional field would have strong privacy if global membership proofs are implemented.

tevador: how would the cost/benefit of moving away from ed25519 change if you contrast a global membership proof (~2^40 to 2^45 members) with an epoch-based proof (2^16 to 2^20 members)?

moneromooo: your last point about "jerks adding unencrypted stuff" - is that because it's not possible for nodes to validate if data is actually encrypted?

Yes.

2^16 members is less than 1 day, I don't think that would make a big difference. The point of the 2^40 membership proof is to completely get rid of any statistical attacks that are based on the decoy set.

tevador: I'm just interested from a technical point of view, the efficiency differences

I can't speak for PLONK, which I don't fully understand, but Curve Trees would have a very small difference between 2^20 and 2^40. The paper lists some benchmarks as: 2^20 = 24 ms, 2^40 = 43 ms. This is without batching.

^ verification time of the proof

john_r365: This is still being discussed. You cannot _prove_ something is encrypted if you don't have any of the keys (public or private). However, encrypted data should have an approximately uniform random distribution. Unencrypted data does not have a uniform random distribution. We are researching possible statistical tests that could reject obviously unencrypted data.

hmm I see, close to linear in the exponent

I'm assuming SNARKs would have a similar characteristic

I think it's a waste of time, especially for large numbers of small sets like 128 bytes or 256 bytes, unless you're doing this for fun.

(about guessing whether somehting is encrypted)

Yeah it may be a waste of time

You don't want false negatives at all, so that'll send false positives through the roof, making it useless.

(and you don't want false negatives at all because Alice doesn't want to be told "your perfectly good tx is rejected because law of large numbers said someone had to be punched")

I suppose the wallet can retry if the encryption is non deterministic...

OK, I revise my earlier opinion from "waste of time" down to "not convinced".

Any secure encryption method must use randomization, so if the test deterministic, false positives are a non-issue.

Do you mean for things like the same message being encrypted twice yielding the same ciphertext, or other ?

(because the plaintext can be prefixed by things like the key images being spent etc to ensure uniqueness)

Scratch that. I don't know enough here to have a useful conversation about it.

I forgot to say something at the meeting. MoneroKon is doing early review and approval of top-ranked presentations starting Friday: reddit.com/r/Monero/comments/11cgnn…kon_2023_call_for_reviewers_round_1

So if you want your proposal to be considered for approval before the submission deadline, submit by Friday.

Option B (formerly B3) seems like an ideal compromise from my perspective. It reduces the "fungibility puddles" resulting from tx_extra from infinite to two, which is a lot better than variables such as number of outputs/inputs. It successfully allows for soft forks, removes one of the biggest fungibility weaknesses, and doesn't enforce mandatory size increase to all transactions.

I also think that voting is pointless on this issue and loose consensus around B seems likely when all the arguments have been put on the table

I also think statistical test for randomness/encryption are pointless if encryption is the default in all reputable wallets, as a "fungibility" attack by using plaintext would have similar scaled costs as a flood spam attack

Just my 2 piconeros on the whole thing

I'm wondering if applying statistical tests truly accomplishes the desired results. If someone declares a standard of using another part of a transaction as an one-time pad for tx_extra, I would think they can enter data that passes the statistical tests as they please.

Even if the statistical tests are assumed to be perfect, they can only inconvenience the behavior, not ban it.

Am I wrong to think this way?

No.

I agree is only inconveniences bad behavior. Circumventing the default encryption would be similar to how some wallets are known to currently use nonstandard fees which has a similar impact on fungibility. Public shunning of such wallets is just as helpful as a wonky statistical test.

Btw, the ZKP based membership proofs have one cool side effect: light nodes can verify it without needing to store all historical outputs. All they need is the Merkle root.

Ok. I will stop looking into statistical tests until we decide that it should be looked into again.