oh I suppose so

I just re-read the latest ristretto draft specifically looking for what is required and what is forbidden. Here are the highlights.

External ristretto functions: Decode, Encode, Equals, One-way map.

Implementations MUST NOT define any external ristretto255 or decaf448 interface as operating on arbitrary curve points.

Implementations MUST NOT construct group elements except via decoding and the one-way map.

Internal representations MUST NOT be compared in any other way than [the provided algorithm]

Implementations MAY also perform byte comparisons on encodings for an equivalent, although less efficient, result.

It is RECOMMENDED that implementations do not perform a decoding and encoding operation for each group operation, as it is inefficient and unnecessary. Implementations SHOULD instead provide an opaque type to hold the internal representation through multiple operations.

Implementations are allowed to apply any optimization strategy to the internal representations...

tevador> It's still better to have a design that supports more rather than less because we're unlikely to have a second chance to do a complete overhaul of addresses. When the proposal is complete, I will also add a "minimal implementation" specs that can ignore all of the extra features. >>> yeah, i assume this is how it will go. the first presentation on network will just be a different monero address.... except well you need to also

include the existing base functionality, so something equivalent to integrated addresses .. whatever tier that is

is it possible to roll jamtis out using the current RingCT machinery? this straddles research / dev, but I think a concern (no idea how valid, just throwin spaghetti on the wall) is that we're doing jamtis *and* seraphis all at the same time, because seraphis needs something new

i mean, because it sounds like something like jamtis would be beneficial even without seraphis, seraphis just gives us an excuse by way of being a necessity to change the addressing stuffs

and, in the case that seraphis runs into some major whoopsie during the next year and needs to cook for a few more years (i mean, obviously not wanting that to happen), should we wait for jamtis? or does jamtis require a new engine

jamtis only works with seraphis (it could probably work with lelantus-spark as well)

dang

<UkoeHB> "jamtis only works with seraphis..." <- What does RingCT need that jamtis cannot provide?

So, is the idea that view tags will remain one byte forever? Or is the plan to have an easily adaptable size that can change with changing needs?

Different key image construction

View tags could increase in size, but the performance gain is negligible. Jamtis scanning services would be more efficient with larger tags because users would have to download less data, but the scanning service would have a much more accurate view into your tx history.

So I doubt view tags will ever get larger

I'd be curious to know how view tags interfere with ring signatures and heuristics from change outputs.

That is, with a naive outlook, I think view tags might partly break the privacy ring signatures offer.

Not for a single tx, but for a tx history where a change output gets respent, etc.

I don't know how to go about checking though.

Is there a performance comparison for "scan N outputs" vs "scan N outputs with view tags" to see how much faster view tags are in practice ?

(or at least in "simulated" practice)

jberman has done simulations on the real-world gains for view-tags, will try to find.

moneromooo: we already discussed this, change outputs will have a new definition in jamtis to mitigate linking

<UkoeHB> "View tags could increase in size..." <- I am trying to understand how the performance gain is neglible from a future proofing perspective. With each additional bit on the view tag, the set of matches should halve in size. Is that correct?

If the set of results grows faster than light client performance, there will eventually be performance issues.

Yes there are fewer matches, but the cost of a match vs fail is only like 1.25x - 2.5x. If your rate of matches is 1/256, you can’t gain more than ~1% further speed up with larger view tags.

So... instead of T*N time to scan N outputs, you get T * N / 256 + 255 * T/2 * N / 256, roughly ?

(/2 being around 1.25x - 2.5x)

ie, you still need about half the time to reject ?

I was thinking of bandwidth, not computation. How long will it take a light wallet to download the set of potential matches? Will that growth outstrip light wallet performance gains?

hypothetically let's say it's dynamic: more transactions, bigger viewtag, more granular light wallets... consider what happens if a surreptitious lightwallet service launches a flood attack. Not only do they gain knowledge of their own outputs, which can be used to eliminate decoys from ring sigs, but they also gain information about their own users visa vie higher resolution viewtags. Anyway, considering light wallets work fine for

the most part without view tags right now, I'm not too worried about about future performance with viewtags.

I think most users will have a CPU bottleneck rather than a download speed bottleneck. I do not have hard numbers though.

I'd imagine some suers it's CPU some bandwidth but I also not hard numbers just personal experience

btw what if any work was done to settle on 1 byte? I understand 2 bytes isn't useful, but maybe 7 bits, or 9, Idk

LyzaL: Wouldnt flooding transactions be prohibitively expensive? You would have to double the total number of transaction in the blockchain with view tags to justify adding 1 bit to the view tag.

<wernervasquez[m]> not as expensive as you might think, according to research, and you gain a lot more by doing it than just the viewtag. It effectively would make FloodXMR slightly more effective for an attacker that also ran a lightwallet service, I think

moneromooo: yes, although I think it’s actually like [T*.6 - T*.75]

1 byte is a standard size, that’s all

wernervasquez[m]: if bandwidth becomes an issue for light wallets in the future, then we can revisit view tag size. That probably won’t happen for a long time.

Light wallets have to download all key images anyway, which should require more data than view tag matches on average. A view tag match is ~4-6 x 32 bytes and a key image is ~32 bytes, so on average ~1/64th of the data downloaded by light wallets is outputs.

In jamtis*

Although tevador’s idea to use a bloom filter instead of downloading key images might change that equation

So a rough approximation is that the maximum speedup you can get is ~3x, correct ?

No, it’s 40%

And only for 2-out tx

Oh sorry. x1.5 then.

isthmus[m]: do you have an opinion on what damage can a third party being able to pigeonhole users into 256 bins do ?

People allowing themselves to be fingerprinted would have x256 scanning speedup, right ?

Hmm, more like ~x170 since they'd get the x1.5 even if they did not.

x170 is very significant, x1.5 isn't. Mixed emotions...

I have no idea what you are talking about

Which line(s) ?

All of it

Hrm. OK:

"x1.5" -> if the speedup for "matching" outputs is 40%, then speedup is about x1.5 roughly.

"isthmus" -> I was asking about the "strenght" of an attack based on an adversary being able to know "outputs A and B do not belong to the same account" for a good amount of accounts, since a good amount of users will presumably allow themselves to be fingerprinted for the speedup gain.

"People..." -> I was asking whether the speedup you get if you get fingerprinted is really about x256. This seems likely since you only get 1/256 outputs to scan.

"x170" -> the very rough speedup you'd get from: x1.5 base (you scan all yourself) and x256 (you let an adversary prescan for you).

Does that clear it up ?

Light wallets don't have to do any scanning (aside from change and self-spends), they just need to do bytewise matches with their subaddress table.

In general, it should be assumed that a scanning service will know all the non-change/self-spend outputs you receive, and can narrow down change/self-spend outputs to 1/256 of the output set. The only way to hide non-change/self-spends is to use a unique address with a semi-trusted party.

non-change/non-self-spend*

So, if Alice receives money from Bob several times (same address), the third party daemon knows all these outputs are to the same address, rather than all go to an address with hte same view tag ?

So basically no privacy in exchange for... ok, really good speedup.

(no privacy for received outs at least)

So third party daemons can basically split the output set between people who like privacy and people who don't care, even for future outputs.

(right ?)

So there is massive incentive for people who don't care about privacy to shrink the privacy pool for others.

(and we can assume TPDs will be run by assholes, like we've seen with public access daemons)

Currently TPDs don't know which outputs are owned by their users (or should not, there used to be a timing vuln for this, so it's always possible there's a remnant or another).

That is, assuming I understand "bytewise matches with their subaddress table", which I take to mean "the TPD calculates that value, and since it's a bytewise match, it implies two sends to that address mean the TPD also cals the same value".

This scanning ability is to replace what MyMonero does, not what remote nodes do.

So you think people who use TPDs now would not switch to these new third party scanning types ?

? I am making a technical statement, not speculating. M

The problem is we either get a cryptonote-style view key that gives remote scanners deep insight into user finances, or this view-tag based approach that hides as much as possible while still being useful enough that people don’t fall back to the super-power-view-key approach.

Well, I thought the view tag was "pigeonhole in one of 256 buckets", but from the above, it seems it allows much more.

(I might be wrong here ?)

Well I’d encourage you to go read the material on this, because I can’t explain it here

I think I'm burnt out enough on monero not to, at least for now. I'll shut up then.

I could see a lot of people switching away from remote nodes to this, potentially. Seems like a reasonable concern despite what the intent is

the intent of the proposal I mean

I think the upshot is there would be a bunch of different service providers in that case

spreading the info

random idea: monero-project/research-lab #96

tevador: you can only make a tx input with a real key image, ie only a real spend works

moneromooo: Ok there are two things here. 1) view tags let a scanner efficiently discard 255/256 outputs (~25-40% faster than usual). 2) the scanner computes a nominal spend key for the 1/256th output. In jamtis, the scanner would send all view-tag matches with nominal spend keys to the light wallet, which would match those nominal spend keys against their subaddress spend keys to find real spends. If A) the scanner

knows user addresses then they can immediately recognize outputs send to those addresses, B) if multiple outputs are sent to the same address then there will be duplicate nominal spend keys. Change and self-spends are hidden from scanners by using a hidden nominal spend key. To find change and self-spends, the light wallet looks in all txs that contain the wallet’s key images and manually checks their outputs

(actually, just the outputs that the remote scanner flagged as view tag matches, since those are the only available outputs to the light wallet - if change-out view tags were hidden from remote scanners then the light wallet would have no way to efficiently obtain the outputs of those txs without leaking much more info to the remote service). The tricks to hide change outputs done work in cryptonote because your view

key must be able to identify all owned outputs. Jamtis has a key hierarchy that splits out some viewing authority into a separate key that the scanning service can use.

Oh, maybe a three-key address could allow cryptonote to hide change outs as well...

Anyway the standard cryptonote address scheme doesn’t allow it

UkoeHB: if you have a zero-amount commitment C = r G then r Hp(C) is a valid key image and the LSAG will validate AFAICS

oh I see now

yes I suppose that would work

<tevador> "UkoeHB: if you have a zero-..." <- I think it is a promising idea.

I guess the only issue I see is that dummy inputs add a lot more to the TX size that dummy outputs thanks to ring sigs. but for sure seems worth exploring

I guess the optimal configuration would be something like 6/16

that woule be around 5 KB in size

Just a short independent notice: I've just integrated the preliminary version of optimization to the blockchain prediction. I will be releasing it about in the middle of next week.

Which coincidentally matches the above message :)

blockchain prediction?

UkoeHB: Actually - prediction of whatever series you put in.

I just don't like to speak in 100% abstract way.

In this case, but current test data are the number of transactions in a discrete timestep.

did someone say dummy inputs....

<gingeropolous> "did someone say dummy inputs...." <- It looks pretty promising.