how expensive would it be to check that all pub keys in extra field are actually pub keys and not random data?

Easy if we change them to be 1/8th of their actual value.

UkoeHB_: the seed has to be unique per signature

But that's doable

If the keys are uniformly distributed from random secret keys, it is not possible

Or are you asking about subgroup testing

based on how complex the code is it amazes me how fast creating a transaction is, barely 1 seconds

There's a probabilistic way to do batch testing for subgroup membership

But it's statistical

well group elements have a limited range, so if there is a pub key outside that range then someone must have made a random value, which is useful info to analyst

idk if it's worth the expense to test

Any key that decodes to a curve point in the G subgroup is equally likely to be random as to be a key generated correctly

Any key that does not belong to the subgroup was not generated correctly

I mean a random 32 byte scalar, rather than random point. Unlikely and probably not worth code up

figured something cool out, please take a look! response to sgp_ here monero-project/research-lab #58

UkoeHB_: that went well above my head haha

I responded to UkoeHB_ on github. You can _usuall_ infer the real spend with just the viewkey, the major exception being when someone uses your output in their ring to send you XMR

the probability is somewhat low, but could happen. So you can give some reasonable account balance estimate right now, without any changes to the chain protocol

Btw viewspent wouldn't be part of the protocol, as everything related to the extra field is unverified. It would require non-trivial code changes though, I think

it is part of a protocol - the wallet has to do something different

And that's a good point vtnerd

not part of consensus protocol, yes. just something extra for the wallet todo

By protocol I mean the minimum rules to get a transaction admitted to the block chain

is there a specific use case for this?

I think it could be interesting to try the technique I proposed, to see accuracy of it, etc. At the least its a stop-gap if someone wanted that behavior sooner without changing wallet2 and derivatives

I imagine the current view only wallet, or even the 'highly probable' version you just mentioned, would be adequate in a high stakes corporate environment

While view wallets are required for those environments for fund security

inadequate*

yeah, an exchange would want accuracy

I was thinking about light-wallet frontends. they currently require the spend-key to determine account balance. You should be able to do a view-key only frontend that does a "good enough" job for an individual to monitor the wallet from phone

then spend only on some other device

Since monero adoption is still fairly nascent, a probabilistic view wallet would not have many drawbacks, and would improve the situation greatly. I wonder though if it would hamper long term adoption. It has a psychological effect too, since lack of certainty often weighs disproportionately on people's minds.

Are you suggesting a "you might have that much monero, or not" mode ?

Sorry if I've got the wrong end of it, it just sounds htat way :D

me or UkoeHB_ ?

Good question.

'You probably have that much monero' mode

UkoeHB_ wanted a mode that determined the true account balance without the spend-secret-key

the initial proposal required changes to how a wallet sends txes for it to work

Ah, OK. Sounds good then, ignore me.

I pointed out, that you get a _really_ close balance without any changes

Yeah IIRC I had a patch for that but it was rejected because it required "honesty" from the wallet owner wrt the auditors.

with the unfortunate caveat.

By relying on getting change back ?

yup. its usually the giveaway to the real spend

(ie, sweep_all gets hidden)

moneromooo: I may have solved that with a new type of proof, that a key image does NOT correspond with an owned output. Very nice for audits :)

Research Issue #58

I think the uncertainty kills it. People will rely on it and complain when it's wrong.

And if it's uncertain, it's pointless, isn't it. The main use people want is to ensure they can see when their money is stolen.

Which relying on change does not help.

Says a lot about crypto btw, if the main use is "seeing when my money gets stolen"...

hmm. yeah, if any of this dependent on sender behavior, then they "hide the steal". I love that phrase lol

viewspent may also not work for verifying stolen funds, since a thief may edit out the curve point

although, if you are watching someone steal your XMR, its already too late lol

KoH wa

Typo. Only way to know for sure is with the key image

this is unfortunate, because the ability to view an account balance with just the viewkey on a phone to a light-wallet-server is kind of nice. But the false impression under adversarial cases ... :/

or maybe if the UI said (in fine print) : "*Account balance shown might not be real" like one of those drug ads

then we're covered

The basic problem is view keys are not part of the consensus protocol. An alternate wallet may use single-key one time addresses, and ignore the view/spend concepts

So no kind of solution that doesn't involve the consensus protocol will solve it

Fine print! Of course! Time to update the roadmap

The idea of a point-in-time "account snapshot" using key images and proofs-of-non-spend could be useful

Where the improvement is not leaking unspent information

I think the problems with current view-only are, in order of importance: a) unable to view entire balance, b) unable to cooperate with audit without leaking unspent info, c) unable to know when theft has occurred. (a) is partially solved by probabilistic view balance, and fully solved by viewspent keys. (b) is solved by proofs of unspent, assuming person being audited has spend key and auditor has view key.

(c) is unsolvable without consensus changes.

Although auditor knowledge of view key is still problematic, since they can keep that key forever

At least in the immediate audit they don't learn more than necessary

Don't see a way around auditor knowing view key, since they must be able to know all the owned outputs.

The traditional use case for audits has been presented as the "club treasurer" problem

Where Alice is the treasurer for her club, and wants to show the members the balance is as expected

So there's not much of a threat model, and a point-in-time balance test might be sufficient

Members can use the view key to see incoming funds, and can request that Alice provide a point-in-time proof as needed to check the balance

Makes sense

and it doesn't involve changes to transaction structure etc.

Alice runs the point-in-time tool, and the members verify it with their own tools

While more robust handling of balance would be nice, I think it'd be a marginal benefit (at best) for a big cost in terms of development and chain bloat

Anything optional and sender-only seems to be useful more as a view-only convenience, not an absolutely-to-be-trusted-under-all-use-cases application

and then you have to weigh the practical convenience against the development cost and bloat

Maybe a good discussion is to identify the use cases for transaction/wallet proofs and assertions that are "must haves"

And see how well the existing options handle those cases, or could be adjusted to do so

Right now we have InProofs and OutProofs and ReserveProofs and SpendProofs

InProofs and OutProofs are being updated but would retain their same functionality

i dunno about the whole thing. if we're really trying to be like cash, how does this concept fit in?

I think it'd useful, but it'd have to be always segregated from the balance, like "likely balance if no corner case happened, and exchange key images for certainty".

Let's set aside the sophisticated adversary for a moment. It seems like an improved view only wallet would be very beneficial to the ecosystem, and would go a long way toward making Monero user friendly. There are now two options on the table: probabilistic view that depends on change output heuristics, and viewspent keys that show an exact balance. I expect high volume wallets would not be able to rely on

the probabilistic view, while viewspent keys certainly lost the chain. Both entail development costs

Because if not, you'll get tons of people complaining monero's buggy, even if they had to click on a "I understand it might not be right" button.

i think the viewkey functionality was just a side effect of how the monero system works. they went "oh, the way we designed it allows us to do this" kind of thing

UkoeHB_: for what specific use cases?

I don't want to fall into the "surely it would be handy" trap

because we can't make good cost-benefit analysis from that

For anyone using a view only wallet

OK, for what use cases

but I don't fully understand the viewkey/spendkey. But from what I sorta understand, its not like monero could use a single viewspend key to do what it needs to do

if you show someone your wallet full of cash they can take it

You can have the view key derived from the public spend key (giving a truncted address).

View only wallets are helpful when your spend keys are not easily or safely accessible.

OK, what are the trust requirements?

Any solution that can be reasonably gamed needs to be only a convenience feature

and we'd need to specify interactive (like Alice providing a point-in-time proof set) or non-interactive (only needs the chain data)

Trust requirements?

You could imagine use cases where you intend any view functionality to be used by you for convenience, so you can trust yourself to not mess with your own transactions and screw it up

But there could be other cases where you don't trust the prover/keyholder to do this

gingeropolous: current view only just shows all the outputs you received, not if you spent any of them. viewspent shows which are spent directly (assuming honest person or unsophisticated thief spent them). Probabilistic view estimates balance based on outputs you receive from tx where a previous owned output is referenced (probably spent, and the one you received is the change).

Unsophisticated thief who manages to steal coins from a cold wallet ? :)

Or just a thief who doesn't care

what is the currency parallel here? not that existing things should restrict future things....

I like the club treasurer model because it's an example of a partial trust. The club members don't trust Alice enough to let her simply have the wallet with no oversight, but they might trust her enough to provide monthly point-in-time proofs to assure that everything is ok

And that model has reasonable solutions

Financial analysts know a lot about company finances, but can't spend any of the money. And in fact the records may be fake or incomplete

yeah but thats not the money doing that. thats some institution

sarang I'll have to think about that carefully for a bit

gingeropolous: the blockchain is just a ledger, a cash metaphor breaks down under too much scrutiny

Including something that's optional and can be gamed by a dishonest party might work in the case where you trust yourself, but that probably incurs a big cost for the entire ecosystem and wouldn't address more stringent trust models anyway

yeah thats more true of a transparent ledger. monero's ledger is more a history of mathematical proof that everyones playing the same game

Off-chain stuff is point-in-time and interactive, but can be made hard to game and does not incur ecosystem-wide costs

If you don't need any of the point-in-time proof stuff, you don't ever need to care about it

I'm curious about wallets in open ledger coins (everything except monero). What is the prevalence of spend-authority wallets vs non-spend authority wallets/balance checkers?

you don't need wallets to do it.

Any explorer could do it

Oh, but you mean with multiple derived addresses

for the club treasurer model, it would be cool to do something where you can send someone an output that is effectively a fake transaction

maybe thats what you were talking about

?

point-in-time proof set

I meant that when the members only have the view key, they don't have full insight into Alice's spending

but they can request/require point-in-time proofs to account for the balance

and presumably fire Alice if anything shady happened

like, i could imagine a new type of transaction, where it is formed in much the same way, except the output that is created isn't spendable, and it doesn't actually nullify the outputs it used as inputs

so the only way to create that new output thats worth 20 XMR is if you had the 20 XMR to create it

The MLSAG asserts that one of the input ring members was used as the signer

so you can send that tx to someone, and they can reasonobly conclude that indeed you have 20 XMR

You can always generate an "output to nowhere"

of course, one could spam the chain with these things

but they would cost the same tx fee

or an output addressed properly but with bad commitment data, for example

(this would not be spendable)

but at that point your wallet detects this and says no-good

well thats just wallet and consensus rules

Isn't everything? =p

indeed! Blue skies baby!

"Any explorer could do it" smh

?

Look at an address balance?

smh = so many hamsters

yeah lol, the fungibility maximalist in me shakes his head

oh

I thought you weren't sure about that claim

would your position change for viewspent with Triptych, since the extra scalars are there?

I thought the key image format mechanism could allow for the same functionality, but it doesn't appear so

Triptych et al. use nonlinear key images

thats my favorite kind

You can still store up to 64 bytes of arbitrary data per input proof, to be clear

But the linking tag format for output private key `x` is `J := x*U`, where `U` is a globally-fixed group element

sigh

typo

`J := (1/x)*U`

FWIW Omniring can support the existing tag format

but it isn't clear to use that format with multisignatures

ah so next gen of protocol may not even support viewspent; does it still support current view capabilities?

The proof system doesn't care how you derived your output keys

Just like how MLSAG/CLSAG don't care

Everything's a commitment, and some things are commitments to zero :D

However, I was thinking about if/how the hiding could be safely done in CLSAG

where all round scalars are random except for the scalar at the signing index

So you could generate all but the signing scalar via PRNG, and hide the data in one of those

and have a rule about where it's hidden (e.g. the index after the signing index)

provided the scalars are still independent and uniformly distributed, adversaries can't detect which is hiding the data

and if you know which output is yours, you know where to look in the ring

makes sense

we could do that right now with MLSAG scalars

of course they are pruned which is problematic

I think we need to differentiate two main uses of the view key

One is the MyMonero wallet scanning type, where we want the LEAST info revealed to optimize efficiency

Another is the audit functionality, where presumably it would be great to have the same view as the spend key holder

to optimize efficiency <- if you mean scanning time, both viewspent and probabilistic would involve insignificant time compared to actually finding owned outputs in the first place (basic view key function)

UkoeHB_: I took an ever bigger step back into the reasons why you would want to hand over a view key in the first place

in the first case, I want as many barriers to preventing someone from figuring out which outputs are actually spent as possible

in the second case, I would want to be 100% sure it can't be gamed

I'm going to switch the conversation to something more timely

If the intent is to have CLSAG code reviewed, there needs to be a scope specified for this

^ moneromooo etc.

what do you need help on when defining scope?

At a high level, we need to tell the auditor what to review

At one level, there's "we ripped out X and directly replaced it with Y", which is true for some functionality

Ideally this would assert that the CLSAG implementation is _at least_ as secure as the MLSAG functionality was (but that was never externally reviewed)

Or it could be extended out somewhat to other parts of the tx protocol, but then the "stopping point" becomes less well-defined

and eventually it's the whole damn codebase =p

Separately, the math is reviewed... and the CLSAG code is checked against that as well

I await news from suraeNoether on some further updates to the paper we've been working on to really ramp up the security model

(and none of which presently change the sign/verify algorithms)

If it's.... name escapes me.... they already reviewed MLSAG, so it's easy. Review the patch. And apparently Tim Ruffing (IIRC ?) was willing to review the made side (though not sure how this differs from what he did in the first place).

Right now there are 3 commits that relate to this, from older to newer:

?

There was an audit group that reviewed a secp256k1-based implementation of MLSAG, is that what you mean?

AFAIK that was _not_ any review of the Monero implementation

Unlikely.

I'm talking about the people who went to review a load of things then came back to say "it was more htan we expceted, can we get some more money" ?

They were hired for bulletproofs but pulled all the other stuff in.

Not X41.

quarkslab

Quarkslib\

I didn't realize they asked for more money

If it ends up being "review the patch", then that's a nicely defined scope

Maybe I'm confusing with another ?

they went beyond scope. that was them

I'll need to review their report, but I don't believe it extended to a complete review of MLSAG

I didn't think so either

Well, part of it anyway. Still, whether they did or not does not really change the point.

And we'd need to list obvious caveats: "yes, we know this isn't constant time"

"yes, we know this is not a prime-order curve"

Looks like total patch for the 3 relevant commits is ~1800 lines

Main functions to compare to the math are only ~200-300

what's the next realistic scope cutoff? best guess

One extension could be to the way commitment offsets are used to form the input rings to MLSAG/CLSAG

and the balance assertion via commitment sums

It's one of those "how much time and money ought to be spent"

Presumably, reviewing the 3-commit patch would assert that CLSAG is at least as solid an implementation as existed before

might tie in nicely with bulletproofs, since those take as inputs the commitments

Our initial bulletproofs deployment was heavily reviewed

(but note that it has been updated in the meantime)

What would 1-2 broader scope audits look like for the cost of 3 just on clsag?

(narrow clsag)

Right now I know of only audit group that indicated availability and interest: Teserakt

I'm sure there will be more when we ask, no?

OSTIF did

ostif asked kudelski, quarkslab, etc?

they all said no interest?

FWIW the complexity of MLSAG -> CLSAG is far less than that of Borromean -> Bulletproofs

There was a lack of confidence in the expertise needed to review the math/proofs

I wonder if broadening the scope will get them interested

ah

There would be _some_ benefit to having a group review only the code, but having one group that understands both deeply has its advantages

why could they find people for bulletproofs but not clsag? is it a different type of complexity?

and Teserakt is well qualified

They weren't reviewing the math

only the implementation's match to the paper

how important is the math review?

Very

It's new math

Wait, I just realized I confused things with my comment above about Tim reviewing math. That was BPs.

You're thinking of Benedikt?

and bulletproofs wasn't because it was old math, or that everyone else in the world already reviewed it?

I might,

Who reviewed our prototype?

Benedikt was the author of the BP paper

Yes, I am. Thanks.

sgp_: Bulletproofs had its math/proofs heavily scrutinized already

got it

CLSAG has not received that level of scrutiny

I would not advocate deploying without a proof review

how realistic is it to get published in another paper?

I happen to be confident in the math, but I am naturally biased

Tough

There's waaaaay more new work than spaces/eyes available for peer review

It's a losing battle to wait and hope for inclusion in proceedings, and there's no guarantee of the quality of review

(plus it'd be anonymous)

I would think "this is going to be deployed in an open-source, billion dollar project" would help a bit, but academia is weird

I'd rather have a known entity (JP) review it

Academia is busy

I'm moreso getting at both

And you get no credit for reviewing a paper outside of a journal/proceedings

I certainly plan to submit CLSAG to PoPETS, no doubt

But it often takes several submissions with different deadlines

Political... pets ?

perhaps

Proceedings of...

I knoew it, it's about pets.

pet symposium is a dumb name

police pets

I feel... all fuzzy inside knowing such a thing exists ^_^

FWIW, the CLSAG security model is already better than that of MLSAG

But we're trying to improve it even more to handle some cases that LSAG/MSAG did not

by better security model, does that essentially mean you feel more confident in the math of clsag than mlsag already before review?

Yes, assuming our proofs are correct

did Teserakt give a rough estimate for the narrow scope review?

So far, informally it'd be the patch changes

TBD more specifically

Cost ~7200 USD for code, and another ~7200 for math/proofs

we should split off the math/proofs and compare other providers for the code portion (including varying scopes)

Just to be clear, the fact that we're changing the security model doesn't mean there are exploitable problems with LSAG/MLSAG

only that the proofs couldn't guarantee the non-existence of certain edge cases

"lack of proof of non-existence" != "existence"

got it

Hiring someone else for code review would certainly involve billable hours just to get familiar with the paper

which is built in to the Teserakt stuff already (same people doing both)

could you recruit other crypto researchers to do reviews, as standin for academia which may be inaccessible?

If you know people with time and interest, go for it

We'll have the preprint updated on IACR as soon as the updates are done

I'd still like to see what it looks like to compare firms for the code reviews of narrow and medium scopes

all the people I know are already working on it :p

"Get peer review" is one of those things that is always harder than it sounds, even when it sounds hard

I can ask Derek at OSTIF if any of the other firms would be interested in code-only reviews, given the new timeline (or lack thereof)

yes, I think that would be great

it sounded like the security proofs are pretty novel, would that inspire peer review?

The proofs techniques aren't novel

the security model is different than other LRS definitions, though

and have Teserakt clearly specify quotes for (math), (math + narrow), (math + medium)

Depends what those scopes mean specifically

Math is a defined scope

yeah of course, I mostly defer to your and moo's judgement on the code scopes

but "narrow" and "medium" require a "these commits / these files / these functions" listing

"medium" to me means "what's the next reasonable 1 thing that could be audited by extension"

Oof

I'd like to know what moneromooo thinks of that question

you only get to pick one, choose wisely :p

I can think of conceptual scopes, but it isn't clear what tentacles that extends into the recesses of the codebase

sounds like moo can help define that

If we can get a nice limiting scope for commitment offsets and balance assertion, that'd be my pick

since that's the crux of the transaction model

UkoeHB_: this is where something like ZtM could come in handy, as the closest thing to a written spec

How to define the scope between math and code ?

now we're getting somewhere

moneromooo: no, just what code to review

The patch seem like a good target.

They'd check that the CLSAG_Sign/Verify functions do the Right Thing

As in "it does not introduce any flaw".

Right, that's a narrow scope

sgp_ asked about the "next biggest useful scope"

As in "we did not find any flaw it introduces" :)

Well, given it pulls things which pull things... that'd be the whole protocol really.

that was my worry

And given we might switch to omniring/triptych/rct3/lelantus, it seems not worth it at this point.

At least the patch would show "no less secure than however secure it was before"

can we say "treat this as a black box and lob this off?" throwing out ideas, not dictating

OmniTripLantus3

I can do a CLSAG writeup of how it would be implemented if that would help getting reviewed. At this point I should be doing CCS since my work is getting way off ZtM2 scope

UkoeHB_: that's what the paper is for

we already have that

It would be useful if more of the RCT protocol were in scope

However, I'm sure Teserakt would find ZtM useful to help them understand how MLSAG/CLSAG fit in to the tx protocol (basically a drop-in replacement)

if there's no good way to define a medium scope, then it's probably best to not do one

if it's drop in then not much is actually changing

Anyway, most of this is a moo point until the paper gets the thumbs-up

UkoeHB_: it's still like 1800 lines

There are underlying crypto functions that were custom-written to speed things up

well in terms of how the transaction protocol fits together

and integration code

Yes, there's basically no change to how the tx protocol works

Hence the idea of narrow scope

that's what I meant

gotcha

but it's still a non-trivial change in code, even if it's a small change in the math

The old math didn't have formal security definitions that we liked

So the non-triviality in math exists mainly because of the security model change

The handling of linkability and non-frameability was super limited, for example, and had strong assumptions

Well at least we have some agreement on a scope, which is good

moneromooo: when it comes time to send the list to the auditors, should they review the 3 commits in your crash branch?

Or is there a PR for changes

I plan to send them any commit/PR lists, the CLSAG preprint, and ZtM as a reference for MLSAG and the overall tx protocol

Let me know and I'll rebase first.

OK, will let you know

UkoeHB_: what version of ZtM is most appropriate for this use case?

Assume that it would get sent in a week-ish

And I'll make a branch just for it.

great

I hope it still works ^_^

moneromooo: did that silly extra-data-in-hash issue get fixed too?

heh

What is the silly extra-data-in-hash issue ?

I pointed out a few lines in the sign/verify routines where space in hash input was allocated and zeroed, but never used

It was along with a note about serialization that you'd already addressed

Ah, a few days ago ? I've got that here, yes.

great

That was the only change I noticed (and it wasn't security related obviously, just a waste of spacetime(

Probably the latest draft, since rcttypefull has been deprecated

Just missing bulletproof really

And that's most definitely out of scope

I'll ping you again before I send it, to confirm the right draft

Sounds good

thanks UkoeHB_

ZtM wins again

🥳

did a brief analysis of txtangle, assuming 1% of current tx volume is converted, is 230 participant tx per day, for about 9 per hour, so 15-30mins per txtangle, at around 0.05-0.10 USD per output to be financially viable

coinjoin is at 4% volume but that's an open ledger, and bitcoin is easier to implement

Plz define txtange

join protocol

and why 1% would be expected

just an approximation based on coinjoin adoption

How is txtangle != joinmocoinjoin

expected adoption is lower since monero is already not an open ledger

its a better name

and coinjoin means bitcoin]

OK so, "txtangle" == "input joining" or whatever generic term we wish to use

sry :p

Whenever I see an undefined term that sounds cool, my subconscious assumes it's a marketing thing and automatically recoils =p

Unless I came up with the term, in which case I am proud of it :D

Also, "tangle" means something else depending on what projects you know of :/

whatever! it's mine now!

I am cool with reclaiming that word

it's a cool word

I mean, I only chose the term "Triptych" because I got sick of saying "the new LRS construction proposed in issue #XYZ"...

and you only get media attention with a badass name

i figured koejoin was way too much ego ;p

You can call it whatever you want! But you need at least 51% of nodes to agree on the name

I was told during my math training that you can't name something after yourself; someone else needs to

shit need to work on my outreach

<Isthmus> Crap, I ran out of money and my IRC cloud account got cancelled

<Isthmus> I get paid at midnight PST

<Isthmus> Please don't talk about anything interesting for the next few hours

<Isthmus> plz n thx

there is monerologs.net

you should definitely read the entire scroll back asap :)

^

Who runs monerologs?

It's a great interface