UkoeHB_ if i understand correctly, the view tag concept is essentially that one scalarmultbase can be saved per output scanned, 255 out of 256 times?

that's very cool

i like everything in your issue #6456, with just the exception that the janus mitigation requires knowledge of the private view key. i think making the janus mitigation work with view-only wallets should be a design goal

s/knowledge of the private view key/knowledge of the private spend key

also, for the record, i'd be in favor of eliminating encrypted payment ids

and thus i'd be in favor of leaving them in txextra and not putting them into the new tx_supplement, and then hopefully they will be used less and less until not used at all

Ah I see a question. The 48-byte method seems to require using a secret subaddress for change outputs. However, in the future I imagine needing to do audits will be fairly widespread. Based on the framework I laid out in ZtM2 ch8 (section 8.2), the only way to do an audit is for the auditor to know the auditee's addresses and subaddresses. Note the framework includes InProofs, which require addresses

A solution might be a spend-wallet/view-wallet hierarchy, where the view wallet has access to the chain, and then talks to the spend wallet for importing key images (to identify change outputs). The view wallet would need to send info to the spend wallet to get key images, so it could just send the information to perform Janus tests too, a point in favor of Janus base key method. However, a view wallet

would only talk to a spend wallet periodically, so its set of key images would always be older than new outputs being discovered. In that case, with 48-byte proofs you could do a Janus test sooner on non-change outputs, a Janus test on change outputs up to the block height with known key images, and then leave the remainder change outputs as 'tentative change outputs' pending a refresh with the spend

wallet.

Im not sure if we want to base the design choice on that complex of a setup though

Hm although the auditor has to learn addresses and subaddresses.. while the point of Janus is to prevent that!

But an auditor would be able to use the secret change address to Janus attack subaddresses hidden from the audit

Regarding the change subaddress assumption.. what if someone doesn't want all their change outputs to go to the same address? It seems to have some privacy implications for advanced users.

One big point against Janus base key method is TxTangle wouldn't be compatible

i should catch up on TxTangle, i don't know what that is

good points above

so either we accept that an auditor (or anyone with knowledge of the private view key) is able to janus attack a wallet

or we add a janus schnorr proof on both of the 2 outs in a 2-out tx

it's worth pointing out that the auditor can't gain anything from janus attacking the wallet, since all a janus attack achieves is proving that subaddresses belong to the same wallet

anyone who knows the private view key can calculate all subaddresses, so it isn't a concern

he could uncover hidden subaddresses from the same private keys

right

ok so great, the auditor issue isn't a concern, right?

auditor doesnt need to know the private view key, which is the point of the audit framework

so there is a small window

i should read up on your auditor framework stuff

txtangle is in there as well, ch11

what is the advantage of not simplifinh things by just giving the auditor the private view key?

they don't learn about future outputs you might receive

and don't learn key images, so can't know when current unspent outputs are spent

ok so without the auditing framework, the other way to achieve the same outcome would be to simply get the auditee to switch to a new wallet/new private view key at the point where they want to cut off the auditor from seeing future transactions, until some point at which they wish to have further txs audited and where they will provide the auditor with the more recent private view key

yes that would work, although they would have to update all contacts with new addresses, and transfer all funds over from all subaddresses

so the auditing framework is for when you only want to restrict recent transactions from an auditor until the next audit

right, it also means if the auditor gets compromised then your view key/key images are not compromised

minimizes risk

interesting, ok

i'll take a read of it in z2m2

btw i still marvel at z2m all the time. incredbile piece of work

thanks :)

I think these are the main tradeoffs to consider:

1. Janus base key: +32 bytes on average, requires private spend key, not compatible with TxTangle

2. 48-byte Schnorr (w/ change out assumption): +48 bytes on average, view-only compatible, change assumption is not super clean/robust given design goal of view-only compatibility

3. 48-byte Schnorr (w/o change out assumption): +96 bytes on average, view-only compatible, no concern about change outputs

notes: 48-byte Schnorr is TxTangle compatible; no compromises are made on scanning time for any solution

UkoeHB_ can you be specific about the change assumption not being clean/robust given design goal of view-only compatibility?

is that only with reference to the auditing framework?

there is the auditing scenario, and also that maybe people don't want to always use the same change address

given that balances received to any subaddress in an account are generally supposed to be in a single pool, i'm struggling to see a scenario where it'd be useful to send change to a particular subaddress within an account

it feels too far away from the basic protocol, requiring users to use specific addresses for specific scenarios

a scoping problem, if you will

i think i get the gist of what you mean. i see this more as just the tiniest of changes, where the change subaddress will be set to subaddress index -1 instead of subaddress index 0

i'm assuming that 0 is the default change subaddress if none is specially given

i'm not sure if that assumption is correct for the monero wallet

i also can't think of any use cases we'd want to preserve when it comes to directing change to particular subaddresses rather than to particular accounts

if when an outgoing tx is made, if outputs received to any subaddress in an account can be spent, i don't see any advantage to directing change to any particular subaddress within the account

and given that we're not showing balances per-subaddress in most wallets, i don't see how it's useful to send change to a particular subaddress

I see what you mean, that seems a reasonable assumption. The risk with change outputs all going to the same place is when you spend them they can create heuristically significant ring loops on-chain. However, if subaddress accounts are considered separate behavioral units then that situation isn't affected by the change subaddress designation.

right, *if*

but we decided not to consider subaddresses within accounts as separate behavioral units

I mean the account itself as a unit

ok i'd better clarify something just in case it wasn't clear:

i didn't mean that an entire wallet would have all change sent to a particular change address

i meant that for each account, there would be a change subaddress of index -1

so you still have account segregation

Yeah I noticed that after what you said 10mins ago :p

ah ok cool :)

btw with the auditor framework, i guess the advantage is that you prevent the auditor from seeing future txs, but the disadvantage is that the auditee could decide to not declare 10% of the incoming txs to the auditor, and siphon off those funds to a personal account, and the auditor would be none the wiser?

so making a change assumption and implementing Janus would require widespread consensus about the account model

right, yes wallets would have to agree

otherwise wallets wouldn't be interchangeable for users since Janus might get flagged in different ways

although I think spend enabled wallets should try to use key images to identify change outs just in case

yeah if wallets for some reasons wanted to work in a different way, they could ignore the janus stuff and do things however they wanted, and it woulnd't affect anyone else

with the audit framework you make an inproof on all on-chain outputs

so none can slip through the cracks

oh, so you can't just neglect to tell the auditor about certain inbound txs?

right

ok thanks, i'll read it again, i didn't realize that

from a maintainability standpoint then, change assumption would be the most expensive

Updated main tradeoffs to consider:

1. Janus base key: +32 bytes on average, requires private spend key, not compatible with TxTangle

2. 48-byte Schnorr (w/ change out assumption): +48 bytes on average, view-only compatible, change assumption entails code maintainability costs and extra logic for identifying change outputs

3. 48-byte Schnorr (w/o change out assumption): +96 bytes on average, view-only compatible, no concern about change outputs

notes: 48-byte Schnorr is TxTangle compatible; no compromises are made on scanning time for any solution

"and extra logic for identifying change outputs" <- other than just ensuring that the subaddress lookup table is generated from -1 onwards rather than from 0 onwards, what logic are you referring to?

well logic for spend wallets vs view-only if necessary, or logic to deal with new subaddress account schemes that might crop up

the other solutions, once implemented, would never need to be touched again, but the change out assumption _may_ need to get touched again

what would be different with spend vs view-only?

a spend wallet can use key images to identify change outs

I guess it's 'possibly* extra logic' not guaranteed lol

to be explicit: i think you're saying that if you know a change output was an output you spent yourself, you can trust it as not being a janus attack

right

and that that test should happen regardless of whether there is a 48-byte schnorr or not

i agree, i like the double check

although i can imagine that is annoying for the wallet implementers

it's the way Janus base key method would use to identify change outs

since that must be spend key enabled

anyway

since the schnorr can be checked immediately, and the key image check is something that is delayed to when key images are available for view-only wallets

right, it seems like a question that has no perfect/ideal answer

hence, the risk of maintenance and logic costs

can you be explicit abotu what you mean about maintenance?

for example, let's say a spend wallet was implemented and used key images to identify change outs since that is most simple (or seems that way to the implementer), then they want to make it view-only capable and now have to make all new logic around identifying change outs

ok i see what you mean

or a new kind of subaddress account scheme appears, and old wallets have to add logic to harmonize with tx made with that new scheme

ooh new subaddress schemes, you're talking :)

now* you're talking :)

the wallet ecosystem is fairly simple right now, but if Monero adoption expands too much who knows what people will do with it

another point against Janus base method: multisig groups can't perform Janus tests on change outs until they have computed key images for spent outs, which may be problematic for subcoalitions who did not originally make the relevant tx, since they need to collaborate with an M-size group to construct key images

s/perform Janus tests on/identify

ooh interesting point

knaccc: I updated intro part 2, and proposal part 2, would you mind taking a look? anything I should add/change?

In your new issue?

yes

Im on the fence about which solution is best. Janus base has limitation but is small and I invented so Im biased, +48 it bugs me the idea of loose ends we can't completely tie down, and +96 might be too big.

UkoeHB_ nice, thanks for writing it up

couple of quick things:

1. "Although, with the 48-byte Schnorr proof method there is a niche case where if both recipients are normal addresses then a 2-out tx with 1 tx pub key can work" <- it only works if the normal address recipient does not also use subaddresses, and the sender cannot know whether this is the case

2. Am I correct in saying that the janus base key would require 2 txpubkeys on a 2-out tx, meaning that for the vast majority of txs (which are 2-out with one change output) the storage comparison is +64 bytes for janus base key vs +48 bytes for schnorr, since the janus base key method requires that extra txpubkey?

3. that since the janus base key method requires a txpubkey per output on a 2-out tx, there are 2 variable base scalarmults for janus base key scanning s 1 variable base scalarmult required for schnorr48? so schnorr48 is twice as quick for scanning?

s/s 1/vs 1

1. two normal non-change addresses would work if you used two Schnorr proofs, one for each shared secret using the same tx pub key

2. with Janus base key you can also make the change out assumption, in which case only one tx pub key is necessary (constructed based on the non-change output's address)

3. yes if you don't make the change out assumption, Janus base key method would affect scan times

edited to clarify about the niche case a little

1. ah sorry, i only now understood the point you were making

and 2/3: ah, ok i get it, thanks

the reason i had view-wallet compatibility as a primary goal was that if i were designing a system, i'd use a view-wallet for notifying me of all incoming funds and for then notifying people of successful receipt

and so i wouldn't want to have to have a full-wallet to monitor incoming transactions in order to be janus-proof

that's a fair objective

not sure if this is insane or not: you can brute force random values of alpha until the first byte of the challenge is the same as the byte that you'd otherwise have to store separately in the tx :)

so a 1-byte saving per output, in exchange for an extra quarter second to generate the transaction :)

idk about the security implications

120-bit security vs 128-bit

why not just make the challenge hash smaller

hah excellent point

yeah it's a silly idea

going a little too far.

ok I think we could do it in 80 bytes lol, a 48 byte Schnorr proof for non-change output, then 32 bytes to encode the tx private key for the change output

actually it would have to be 32 bytes to encode the tx author's view key, since the details around how tx pub keys are currently constructed for 2-outs precludes the tx private key being useful for this purpose (ztm2 pg 40 footnote 16)

it also means the 96+ version wouldn't work, i.e. 1 tx pub key but 2 schnorr proofs

basically you'd encode the view key with the view key, so no information leak

oh I wonder.. maybe you'd only need to record 16 bytes of the view key, so 64 bytes; sarang what do you think?

Sorry, have not been following conversation lately due to other work

What's up

so, we want a way to identify an owned output is a change output, in the name of optimizing potential Janus solutions

roger

one possibility I just thought of, would be to add an encoded scalar in chain data, e.g. the private view key Diffie-Hellman encoded with a value produced by the private view key

could you Diffie-Hellman just the first 16 bytes without risk?

Can you write out a pseudoformula for exactly what you mean, for clarity?

on it

H_16 is a hash function that outputs 16 bytes, which we would also use for the 48-byte Schnorr proof

we could alternatively key prefix with the one-time address of the change output if they were enforced to be unique like key images (they aren't currently as Isthmus pointed out)

that may be more compatible with how scanning works

OK, so the use of a truncated hash does decrease the collision resistance

However, I don't think that's a problem in this case

Since effectively an adversary would need second-preimage resistance on another private key

Ah, not even that

Standard preimage resistance

interesting idea. i'm still not really sure why setting the change index to -1 is so important to avoid

it just seems so simple to tell wallets to send change to subaddress -1 instead of subaddress 0

idk it bugs me somehow

anyway Ill present the different ideas and let people decide

using a designated change address doesn't bug me, just making it part of the basic consensus does

it can't be part of consensus

consensus can't detect if the correct change subaddress was used

well whatever the right word is, basic requirements for universal compatibility

even then, failure to send change to -1 only affects janus-protection of the wallet of the person that decides to use that non-standard wallet

hah

Here's a question related to batching for ya

Imagine you have a 2-input transaction, which is very common

Right now, you pick separate rings for each input and build a separate MLSAG (or CLSAG, same deal) signature on each

Triptych still requires a signature per input

But imagine that we've chosen to use 64-rings or something

and that you decide to use the _same_ ring for both signatures

Meaning both true spends are within that common ring

This lets you get all sorts of speedups in verification, but at the cost of changing the ring distribution somewhat

How good or bad is this, based on the ring size?

sounds perfectly fine to me

You can already use cross-ring correlations to try to identify spends

e.g. if both spends come from the same very old block

does it also save on having to create pseudo-outs when there are multiple inputs?

But it changes two separate 1-of-N signatures to effectively a 2-of-N

i don't see how the cross-ring correlation issue is any different whether you have 2 rings or one

knaccc: you still use pseudo-outs, just like you do with CLSAG

Arcturus (the modification to Triptych) lets you get rid of them

I also think the use of a common ring is not a problem in practice

I don't see any problems with it

And if binning were used, it becomes helpful

Since outputs from the same block/txn are likely to appear in the same bin

if you were going to use two inputs each with a seperate 32-ring, i'd say that's pretty much exactly equivalent to using one 65-ring with two outputs in that ring being spent

so you can use exactly the same distribution

just select the inputs based on what you'd do for two rings, but put those selections into a 64-ring

Note that Triptych works perfectly fine if you don't do this (except verification takes a hit)

You could do the same thing for MLSAG/CLSAG, but wouldn't see any verification benefit

verification time is the main thing we care about

The trick is that Triptych verification reduces to a single multiscalar multiplication, so any group element reuse lets you amortize it among anything in a batch

MLSAG/CLSAG don't have this property

Right now I'm coding such a modification to Triptych in order to get real numbers on it

This will provide better real-world data to augment the plots I showed at the last meeting

i assume the reason that CLSAG is being released is because Triptych is a long way away?

as opposed to just jumping straight to Tryiptych?

There are still research and engineering questions to be worked out for Triptych

CLSAG is effectively ready to go now

and provides a substantial size and time benefit

what is the assumed Triptych timeline?

the rough guestimate

I do not have one

ok fair enough

The math hasn't been peer-reviewed

The questions surrounding multisig engineering are still open

FWIW the preprint is now submitted for review, but that'll be a while

The deadline hasn't hit yet

Peer review is a very lengthy process

and it can't happen in parallel

makes sense

Anyway, just thought I'd toss out that ring question, since it's an interesting one

as far as heuristics/analysis go, you can already assume all ring members are part of the same ring, so actually doing it changes nothing

Yeah, I think my underlying question was really about how/if the distribution sampling changes, depending on how you do the selection

btw is surae doing ok? not seen him around here lately

Surae sait that he'd be only occasionally available in channels

s/sait/said

so he can concentrate?

He's not currently under any community funding, but I know he's still been doing some research

(I don't want to speak for him, of course)

as long as he's healthy

how come he didn't put in further CCS funding requests?

He wanted to be able to devote time to personal and family matters

And I'm sure the general upheaval caused by the health pandemic did not help

ouch, i hope he's ok

If you like, I can reach out via separate channels and see if he has anything he'd like me to pass on to this channel

it'd be nice to know he's ok

updated with the change_tag idea; I initially thought the proposal was going to be good-to-go from the getgo, but here we are lol

Such is research

the secret is to propose things so complicated that no one can bikeshed it :)

I think there is a long road ahead before the issue gets resolved..

for the record, my vote is currently on the 48-byte Schnorr + 16-byte change_tag Janus mitigation; based on the limitations of the Janus base key method, sadly I must admit it looks like it will die

Maybe the fact that projects like Bulletproofs have basically no downsides makes it more challenging to accept that other aspects of the protocol's design absolutely do

would there be a reason not to go down to 8 bytes for the change_tag? it's a 2e19 domain space

Well, let's consider the conditions under which an adversary beats it

when a change_tag is included that passes validation, but in fact the user did not make the tx and the tx author did not know the private view key

And this occurs provided the adversary produces `y` such that `H(private_key,other_data) = y`

where the adversary does not know `private_key`

hah yeah they'd have to flood the network with transactions like crazy to get lucky

right, so if H() is uniform then they must guess

These are effectively similar conditions to how amounts are encoded

but with a different risk model

what do you think knaccc? tastier and tastier

what do i think about the change tag?

8 bytes!

i can't see why it could possibly be worth any bytes when it's so easy to set the subaddress to -1 instead of 0

perhaps you'll find a way of explaining your reluctance about that that i'll eventually understand :)

let me sleep on it lol

here is another consideration: if you wanted to dice up an output (take a large amount output and split it up into 10 smaller outputs, so that outgoing txs aren't waiting on one another to fully confirm), then you'd have to have a change tag for every single output in a transaction

so the cost is now an extra 8*num_outputs per tx, rather than just 8 bytes per tx

for tx with >2 outs there would be one tx pub key per output, and a separate 48-byte Schnorr for each; the change tag vs change subaddress is only relevant for 2-outs

oh right, good point

ok so then it's 2*8=16 bytes extra for a 2-out tx

wait 2*8? how?

actually never mind. i was thinking that if you were simply splitting an output into two, with both outputs essentially being change outputs back to yourself, then you'd need a change tag for each

but i just realised that as long as you saw that one of the two outputs had a valid change tag, you can assume the tx was created by you, so you could also trust the other of the 2 change outputs

yeah that would work

although the logic would be: first check the Schnorr proof, then if it fails check the change_tag

oh lol good point, you could decide to always use a schnorr proof to apply to one ouf the 2 outputs, and a change_tag to apply to the other of the two :)

right, that's how tx are made now anyway afaik

yeah

another insane idea: if the private keys or all txpubkeys in a tx are determinstically created from a single source of randomness r, and if r was created deterministically as a hash of (private view key || lexicographically sorted key images declared in the transaction), then you could know when you were the one that created the transaction

so now you can trust the change output if your recreation of the deterministic txpubkey matches

s/or all/of all

the problem is tx pub keys are made weird sometimes with change outputs

so knowing the tx private key isnt enough

good point

but then that means you can't do the test on your change output txpubkey, but you can do the test on the other txpubkeys

and that's enough

that works in all situations

as long as a single txpubkey can be shown to have been created with knowledge of the private view key, that proves you sent the tx

oh wait i'm talking all sorts of nonsense

yeah this doesn't work if the non-change outputs are destined for subaddresses

because you'd need to know the destinations of those outputs, and that's not possible to know when receiving change

yup

oooh no it actually does work i think

so in a 2-out tx, the txpubkey R=sD

change is Q = Hs(x*R)*G + Y

so if x = Hs("change" || private view key || maybe key images here too)

then you can check the change was created with knowledge of the private view key

oh no i'm talking nonsense again

x is the private view key in that algebra

nvm :)

ok more insanity:

change output is Q = Hs("change_output" || private view key || R)*G + Y

and that means you can use the new view tag to check whether to attempt to then multiply with G to check the output

so the shared secret for change outputs is Hs("change_output" || private view key || txpubkey) instead of Hs(private view key * txpubkey)

and that change output is ultra fast to calculate since there is no variable base scalarmult

it does mean that when the view tag matches, you're now doing two scalarmultbases (one for the regular shared secret and one for the change output shared secret) to detect an incoming output

but thanks to the view tag, that's only in a small number of cases

hmmm

seems reasonable

and obviously you'd probably want to concatenate in the output index too

I like it! will update the issue again

it would also let us deprecate a bunch of complex logic in construct_tx_with_tx_key() and its friends

lolll i'm surprised this isn't making your eyes bleed, or that it isn't causing mooo to chime in with threats of physical violence :)

what logic are you talking about deprecating?

web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf pg40 footnote 16

although.. that kind of fundamental change would probably affect LOTS of code

yeah that's why i was surprised you didn't immediately hate it :)

i guess it depends on how the code is written

it had to percolate a bit

adding an extra entry to the subaddress table for -1 and then using that subaddress change sounds 2 orders of magnitude easier than messing with the shared secret derivation

s/subaddress change/subaddress for change