hmmm

test

s/test/monerobux meant to say s/test/monerobux meant to say s/test/monerobux meant to say

s/s/s/test/monerobux meant to say test/monerobux meant to say test/monerobux meant to say

test

s/s/s/test/monerobux meant to say test/monerobux meant to say test/monerobux meant to say

@UkoeHB_ your github issue is a 3 course meal

Haven't finished it yet, but so far so good

is there anything a bunch of GPUs would be useful for regarding monero development?

seems unlikely. GPUs are optimized for 16bit floating point math

using them for anything else is pretty weak

well i didn't know if there's some math or stats or AI or something

AI accelerators on the market now are accelerating 8bit math

I guess a GPU can do that stuff, but precision is wasted

yeah, but free infrastructure. except for me swearing at them.

knaccc I think my main objection to change address for Janus mitigation is scope creep. It requires 'baking in' the change address designation, effectively increasing the number of types of basic addresses: normal addresses, subaddresses, and now change addresses (integrated addresses don't really count, since it's just appending the ID to other addresses). My feeling is 8 bytes per tx is not too much a

price to pay to prevent the design scope from increasing. The 48+8 Janus mitigation does not affect what kinds of choices an implementer can make, it's just an extra step during tx construction, and an extra step during scanning.

i'm not sure why you're classifying change addresses as a different kind of address. It's just a normal subaddress that you should never tell people about

i'm always concerned about bloat on the non-pruneable part of txs

and this 8 extra bytes would be non-pruneable

i haven't done the math recently, but i'd expect 8 bytes means an approx. 5% increase in the non-pruneable part of the tx

It's a new classification since it's not interchangeable with other subaddresses

what do you mean by "interchangeable"

You can't alter which subaddresses receive change for 2-out tx

right, i guess what this fundamentally comes down to is that you've got a gut feel that it could be worth preserving the ability to segregate funds between subaddresses inside the same account, and i'm of the opinion that we've already decided that there should be no segregation because each account has a shared balance and we've already decided the wallet will spend funds out of any available

subaddress

And it puts a burden on implementers to segregate change subaddresses from normal subaddresses, disallowing them from normal use

my response to that is as follows:

let's say you have an account

it's already the case that when you send funds, you don't choose which outputs from which subaddresses will be spent

and the funds could be spent out of multiple subaddresses within that account

which means:

1. the user is already expecting there to be no segregation within accounts

2. there is no natural consistent place to put the change. if funds were spent out of subaddresses 3 and 4, does the change go in subaddress 3? or 4? or 0?

so i'm saying we can bring consistency to this

change always goes into -1

i'm not sure how that could be considered a burden. it's a really simple rule

Ah, but to be clear: the account model is not 'baked in'. You'd more or less be canonizing the account model while creating a new classification of address.

i'll take a second to dwell on what you just said, so i'm fully absorbing its significance

So you'd be moving from 'can do what you want' to 'this is how it must be'. Hence a burden on implementers to constrain how they may use subaddresses

how strictly does monero follow RFC 8032 for things like point addition or private key generation.

I mean this: tools.ietf.org/html/rfc8032#page-11

maybefbi monero uses the exact same ed25519 stuff every other ed25519 lib does

It would be changing the design environment for implementers in the name of 8 bytes per tx

knaccc: which language has the best ed25519 library in my opinion for implementing things like blsag or other things mentioned in monero-zero-to-hero PDF?

*in your opinion

UkoeHB_ it's gonna take me a while to ponder what you said fully.it does occur to me that for the first time in monero's history, the inclusion of a schnorr48 would be an acknowledgement that subaddresses exist at all, at the consensus/tx format level

maybefbi if you're just playing with math, python maybe easiest. if you're building an app, choose whatever language the rest of your app is best coded in

The same could be said for how one-time addresses are constructed. Technically they don't need a tx pub key, but by moving the tx pub key to tx_supplement we are canonizing how addresses are constructed. Why do it? Since tx pub keys are non-optional. Likewise, being subaddress compatible is non-optional

knaccc: i tried to use golang's ed25519 to follow along monero-zero-to-hero but it doesnt have the right primitives. it uses things like extended homogeneous coordinates with cached coordinates and projected coordinates etc

You could try Rust and the dalek library

let me try dalek. THanks UkoeHB_

maybefbi javascript might be the easiest way to get started. take a look at github.com/knaccc/subaddress-js

i tried pkg.go.dev/golang.org/x/crypto⊙v0…25519/internal/edwards25519?tab=doc but it is too opiniated and just for doing sign-verify as per RFC8032

it can add field elements, but not group elements

maybefbi yeah some ed25519 libs only implement signing stuff and don't give you eveything you need. javascript 'elliptic' gives you everything you need

oh

take a look at github.com/knaccc/subaddress-js/blob/master/index.js

You could also try making your own primitives implementation based on the modular arithmetic, idk how much work that would be tho

i dont want to make a mistake. just want to understand the math high level

iirc sarang has a python library as well for crypto. Not at the computer atm

So a few options :)

sarang is sarangs' github username?

@SarangNoether

ah ok

thanks

will follow that lead too

Good luck and lmk if you have any questions/ find any errors :p

thanks a lot.

UkoeHB_ let's say that some wallet software wanted to go down a different path to our current account/subaddress model. So, instead of having no segregation between outputs between subaddresses within an account, they wanted to have each subaddress effectively behave as a separate wallet. So each subaddress would be segregated, and an outgoing tx must use outputs only out of a single subaddress,

and change must be returned to that subaddress. If we did have the extra 8 bytes, it would be straightforward, and they would be janus-protected. If we didn't have the extra 8 bytes, they'd have to segregate such that each segregated unit had two subaddresses: one for incoming funds, and one for change. And the change subaddress would not be shared, and they'd present things to the user as if

there was only one address, even though technically change was going to a different incoming address. Or to put it another way, effectively they'd be creating an account for each user in their wallet, and would not have to reinvent anything. I'm struggling, in practical terms, to think of any kind of real world examples where leaving out the extra 8 bytes will tie the wallet software's hands.

Perhaps you can think of some examples that I've not noticed yet

to put the question more simply: can you think of any situations where the account/subaddress model could not be applicable?

as another thought, i think there might be a fundamental difference in each of our sensitivites about whether an extra non-pruneable 8 bytes on a 2-out tx is a significant burden on tx size or not. I'm of the opinion that those bytes are very precious, and that we should not add extra bytes unless we absolutely have to. we should get others to weigh in on that narrow point

for example, in a marketplace where subaddress index corresponds 1:1 with product ID/payment order

that is probably true

can you flesh out what the obstable would be, i'm not sure i understand the example

osbtacle*

lol obstacle

well anyone generating subaddresses for a vendor would have to: A) work around the change addresses while assigning subaddresses to new product/order IDs (possibly even skipping IDs, which could be confusing to users), and B) to spend money received to those subaddresses figure out how to properly direct change. I'd even expect some implementers to not understand the Janus mitigation, and end up

distributing change addresses publicly (perhaps not a threat to this example, but more generally implementers would be required to _understand_ the Janus mitigation on some level).

Are we at least agreed on: "You'd more or less be canonizing the account model while creating a new classification of address.", "It would be changing the design environment for implementers", and "implementers would be required to _understand_ the Janus mitigation on some level"?

i still don't quite understand your scenario

"anyone generating subaddresses for a vendor"

what does that mean

are you talking about someone providing wallets to vendors, so vendors don't have to have their own wallets?

and in that scenario, wouldn't they assign an account per vendor, and then allow the vendor to have one or multiple subaddresses?

i'm not sure why the account/subaddress model would not be suitable

I mean someone making a wallet useable by vendors

or integrated with some kind of marketplace for vendor useage

ok, so what would be a reason that that wallet software could not use the account/subaddress model

Rather than any thinking about specific reasons, Im trying to point out that the implementation framework is changing

I don't have an objection to the account model, but _Im not an implementer_

so my opinion on it doesn't really matter

i'm effectively saying that the account/subaddress model is so universally applicable, that there is no harm in tying ourselves to it

and that no one should ever feel the need to reinvent the wheel there

and so i see an extra 8 bytes as an insurance policy for the account/subaddress model turning out not to be universally applicable

ok, so long as we are agreed on the core question, then it will be clear for others what they need to evaluate

i do sympathize with the abstract principle you're putting forth

i'm predisposed to a much more concrete rather than abstract way of evaluating things i guess

and i also take into consideration that if the 8 byte insurance policy needs to be invoked, it can be invoked either by having it in place now, or by simply introducing it in the future

and a future introduction could be done without consensus changes, since it could just be added to txextra if wallets ever decide that it was a mistake to not include it

also on a related topic, apparently the average output count is 2.2, and that extra 0.2 refers to tx with >2 outputs; 0.2*48 = 9.6 bytes (additional Schnorr signatures per output), and 0.2*32 = 6.4 bytes (additional tx pub keys per output assuming no additional tx pub keys currently, let's assume for argument it's around 1/2 so 3.2 bytes average increase from mandating 1tx pub key per output for >2 outs)

so about 13 bytes average increase above the 2-out consideration

interesting

If I may dumb things down with an analogy, imagine that Monero is a software for letting an author write books. It allows the author to have a hierarchy of books, chapters, and pages, and that's it. Some authors come along and say "hey, I can't write a book without sub-chapters; how hard can it be to add? please add this feature." Monero says "no, believe it or not, the extensibility isn't worth the

technical debt and loss of the current clarity/simplicity, in our opinion." Well, that's the actual story of the open source BookStack web app, and book/chapter/page is mostly analogous to our wallet/account/subaddress. And that opinion is what it appears you're trying to converge on. Hopefully this parallel triggered a light bulb for someone

Hm if I understand it right, the question is whether to mandate sub-chapters or not.

Maybe not a perfect analogy

i do get the gist. it's the perpetual question of whether we need to offer future flexibility, and flexibility generally often comes with a cost

not mandate. allow. the point is they have a rigid structure. i say "they" but it's a single maintainer, so much easier to reach "consensus."

here is another way to go about things: instead of saying "do we really need those 8 bytes", maybe we should be asking whether we need to add not only those 8 bytes but more

is 16 bytes the limit for reducing the challenge hash? e.g. could we go down to 8 bytes for the Schnorr? sarang ?

so the 8 bytes are there to prove that we were the ones that sent the transaction that is returning change to us

maybe we should take this opportunity to not only prove we sent the tx, but also to indicate to ourselves which outputs were spent

and thus solve the "view-only balance is wrong" issue

(although not solving the "funds were stolen but the view-ony wallet couldn't tell" issue

UkoeHB_ i'm fairly sure we need to stick to 128 bits for the hash

because that can be brute forced without spamming txs

you'd just need an extra 1 byte to encode the index

maybe we need 1 byte per input spent in a tx, to indicate the spent output, and encrypt that with the private view key

the only objection is that people might rely on the view-only wallet to know if their funds have been stolen

but i think it's worth the byte to make view-only wallets more useful

hm it seems like to brute force 8-byte challenge you'd have to test on the order of 1e17-1e18 scalar-mult-keys (or scalar-mult-base), since all you could do is figure out all the possible tx private keys and then test them against a selected base for the listed tx pub key; it wouldn't be enough to find a collision for the hash

i guess if there are 17 real inputs being spent, we could encode more compactly. we look at the number of inputs, go to the next power of 2 and decide how many bits required to encode the real index of each input in the ring, and use only as many bits as required per ring. then pad to the next byte boundary

yeah the scalarmult does mean the hash could be less than 128 bits i guess

i wonder how many bits that scalarmult buys us

i think it allows us to maybe reduce it at most from 128 bits to 110 bits, so only 16 bytes to 14 bytes roughly

based on?

based on a 0.25ms scalarmult compute time

and a 2ghz processor with one core

these are very rough and wildly inaccurate approximations

i just assume one instruction per cycle

so log_2 of (.25e-3)*2e9 is 18.9 bits

that's with the assumption though that one hash is one cycle, and that's not true

I think we could reduce the change tag to 6 bytes, which is 2.8e14 domain space (280 trillion)

even with 1mill outputs the chance is 1 in 280million to guess

what would be the objection to simply adding the change tag to the txextra if some future wallet implementation has some unforeseen reason to need it?

if could put it in some future encrypted memo space that might be introduced into the future, to not affect tx uniformity

that wallet would be implementing it selfishly, and it would become difficult to get other wallets to update

but i don't think that's possible

because the change tag is only useful when a wallet sends funds outbound

it doesn't matter if there is only one running instance of that alternative wallet in the world

it doesn't need any other wallets to use the change tag

it's only useful for the wallet to put on its own txs if it finds it useful

so the only argument against making the change tag optional is tx uniformity

well other wallets would now have to start adding the tag to be compatible with the unorthodox wallet, which may cause some drama/etc

not adding, reading the tag

and that other wallet would have a harder time reading orthodox wallets if they are using the change address for some other purpose

"well other wallets would now have to start adding the tag to be compatible with the unorthodox wallet" < that's not true

I meant reading

we already know how to put extra txextra tags that wallets ignore

you just ignore unknown txextra tags

right, but if someone transferred their keys to another wallet it wouldn't be able to read the change tags (unless updated)

but if someone was using a wallet that threw away the account/subaddress model, they wouldn't expect things to make sense when restoring with a standard wallet

well it would certainly make even less sense

i guess i'll take back some of my last sentence

i can see your point that it would make more sense if change tags were universally adopted

yeah i think then we're back to "i can't imagine a scenario where accounts/subaddresses aren't universally applicable, and if we do realize a shortcoming, we can always introduce change tags when we understand how they can be useful"

so the point of the insurance would be if we don't think the tx format will be evolving such that we can easily add change tags in later

if we assume that things like triptych or other future changes are inevitable, then adding change tags when we understand a real world application for them sounds very easy

there may be some centralization objections there, i.e. relying on the core team to permit/enable innovations

yes

although not in this case, i'd argue

because all of this could be implemented in txextra instead

and the marketplace could decide whether they wanted to use wallets with view tags and change tags and schnorr48s etc

there is a broader point here, that you've identified

which is, if a wallet e.g. doesn't support addresses that start with a 4 or an 8, can that really be called "monero"?

there is no reason that wallets need to use base58 addresses

they could use base64

i think the reality is that we're going to have to always look for consensus on what "monero compatible" really means

and that'll bleed into all sorts of things that aren't anything to do with the tx format or consensus protocol

just for completeness: the proposal is currently that, given m=Hs(a || account index || subddress index), change is sent to subaddress index -1. As an alternative, if we deemed it valuable to preserve subaddress balance segregation within accounts, we could make it so that for every subaddress m there is a change address m_change=Hs("change" || a || account index || subddress index).

and wallets would simply consider change to be part of the corresponding subaddress balance

updated proposal part 2, hopefully it captures all the salient points

UkoeHB_ thanks for all the hard work in writing this stuff up. couple of quick things:

"Implementation complexity will rise as implementers will be required to comprehend the Janus attack on some level"

It'd be useful i think to make clear that you're talking about people writing their own Monero wallets, rather than implementers in the sense of people using a monero wallet

and secondly, "Note: @knaccc argues change addresses could be used initially, then we could switch to change tags if they seem more reliable/better." -> i do agree with what you noted about " I am concerned about technical debt from change tags"

so if it came across that way, i withdraw the argument that it is a simple win-win where you can not have change tags now, and introduce them in the future

so really my argument is that we've already gone down the path of introducing the concept that users should not expect there to be output segregation between subaddresses belonging to the same account, and have told users that having multiple accounts within a wallet is the correct way to segregate balances. therefore i see the no-change-tag-required option as a natural followon from that

approach, and we can add change tags later if we later discover that it provides any compelling additional flexibility

and of course i welcome anyone to suggest compelling possibilities that I have not currently have had the imagination to consider

you're totally right that people writing wallets will need to know what a janus attack is

but then, if they're writing a monero wallet, and they don't know what a janus attack is, then they're also ignoring the schorr48

and they'll also ignore the change tag

if i had misinterpreted you and you really did mean implementers in the sense of people using the monero wallet, then i'd advocate for dropping the ability of users to direct change to particular subaddresses

(although allow direction of change to different accounts)

There is a possibility of wanting to segregate within accounts even further. I also have a vague idea there could be utility to controlling which specific address gets change outputs, e.g. some kind of key management scheme where a bunch of outputs must go to the same exact address. Just spitballing, since imo the current system isn't constrained enough for adding change outputs to be a neutral change

Well there may be people forking the core wallet to implement their own address related schemes

And a new implementation would have to take into account 48-byte and change tag since they are stuck in the tx structure

Possible that Janus could be mitigated through tx uniformity. Make all txes the same size (set at some reasonable limit), and could include in that tx proofs/tags/whatever or dummy padding for smaller txes

So it basically forces all possible implementers to deal with it

By having change tag

thinking along the lines of how mixnets defeat traffic analysis attacks with uniform packet length/format

derbleak: I think that would entail way bigger tx, like 20x bigger

yes, it would be *very* space inefficient

but a huge gain in privacy, iiuc or it actually works

And here knaccc and I are squabbling over 6 bytes :p

may be not worth the tradeoff

right

:)

but the concept may apply in the future, or when space per tx is not a huge concern

currently agree, the chain would bloat to becoming unusable atm

I suppose if unexpectedly petabyte thumb drives become commonplace then we could go wild with memory consumption

:p

could potentially archive the uniform tx separately, with a witness chain similar to segwit, but then we are talking *huge* architectural changes

anyway, tangent over, just wanted to put it out there

btw despite the implementation pain, there is a certain sense of correctness to the idea that shared secrets with strangers should happen using asymmetric means, and shared secrets with yourself should be achieved via symmetric means

and that therefore you shouldn't be diffie helmanning with yourself

for the change outputs

i agree though that simplicity trumps the notion i just described

knaccc: so smth like a HKDF for self-secrets, DH for shared w/ others?

derbleak yeah, so specifically in this case, an output is Hs(rA||i)G+B when sending to others, but Hs(private view key || txpubkey || i) for change to yourself

Hs(rA||i)G+B vs Hs(a||R||i)

Hs(rA||i)G+B vs Hs(a||R||i)G+B

or even skip the mult with G and make an output A'+R+iG+B for change outputs, where A' is a secret known only to the person with the private view key, calculated as A'=Hs("my secret ec point"||a)G

actually that doesn't work unless you remember your choice of random r

heh we really need to get lots of people to weigh in with opinions and considerations we may have missed, or we're gonna go crazy :)

i think we'll probably come to a consensus pretty quickly once the discussion is opened up

will definitely keep thinking about Janus, and re-read the discussion up until now

hopefully nothing too moronic flows through my keyboard :p

my mind can be changed on this incredibly rapidly through some potential use cases that would be hindered by -1 subaddresses

-1 mod p, or negative index?

as in the subaddress 0003FFFF for the -1 subaddress in the fourth account in a wallet

oops i meant 00000003FFFFFFFF

ah, so -1 in the normal sense :)

yeah, and actually i really meant 03000000FFFFFFFF since it's supposed to be two little endian uint32s

why not just invalidate xxxxxxxxFFFFFFFF?

i don't understand

to achieve what?

o, thought that was causing the Janus issue, or contributed to it

no

then nvm

option 4 for mitigation sounds the most compatible (tags + schnorr-48)

agree w/ knaccc about not including integrated address stuff in any new tx schemes