<fr33_yourself> I've been reading the chat history and I just want to say I'm happy that ooo is back. ooo is perfect daemon right? Haha

<fr33_yourself> I'm still getting caught up, but also think tevador's proposals were both pretty genius. It would be nice if the subjectivity of the delayed workshare and block penalties didn't exist. Then we'd be able to extend to k = 9 instead of k = 3. But in practice that would be very problematic if there were partitions or competing cha [... too long, see mrelay.p2pool.observer/e/mo-73sUKOW1QdVJf ]

<fr33_yourself> Also I like Tevador's creativity with Lucky Transactions. When considering a scenario where Monero has to defend against a well resourced non-profit oriented majority hash attacker it provides a nice defensive element in the form of introducing "economic weight". But this could also be used to game things in the absence of a g [... too long, see mrelay.p2pool.observer/e/t9XD3sUKSkNtdVJv ]

<ofrnxmr:xmr.mx> @fr33_yourself: Yea

<fr33_yourself> ooo is GOATed

<fr33_yourself> It is crazy that he shows no mercy and basically rewrites whole chunks of the code though. No mercy from him

<spacekitty69420:matrix.org> craziness, literally yesterday got called a lil bitch, to shut up, to send pics

<spacekitty69420:matrix.org> but am the one getting muted for actually make an insightful post on a part of the internet that the glowies in the hierarchy doesnt have control over

<sk420:matrix.org> forums.d2jsp.org/topic.php?t=106240674&f=383&p=679795244

<sk420:matrix.org> in case u missed it, not gonna make alt accounts, thank you to anyone that saw value in those markets

<sk420:matrix.org> there is indeed people that dont want p2p to grow for monero, explained the reasoning in the thread, it's a theory but seems to make senses, good luck everyone!

Hey, I have two questions about Monero subaddresses:

1- why do generate subaddresses by using the same scheme when creating one-time addresses? Both are K^o = H(r K^v)G + K^s. Is it maybe some kind of key derivation standart of elliptic curves, and therefore we use this scheme for both subaddress and one-time address derivations?

It creates a secret and calculates its public key

Then adds the spend pubkey to it

That way you cannot spend this without knowing H(r K^v) AND secret spend key

2- When I receive a payment to one of my subaddresses, there is no possibility to know which one I received the payment from. Considering we might have infinite number of subaddresses how do I check this? Do I check all my subaddresses (which is impossible) for each transaction I fetched from block.

That addition there is a standard, same way for subaddresses. It's shifted so you can't spend it with viewkey only

You can. You build a subaddress map ahead of time linked to your spendkey

Due to how subaddresses are calculated, you just scan using the viewkey, then do a constant lookup on a hashmap

That gets you the subaddress index

As an example of what I implemented for view wallet lookups git.gammaspectra.live/P2Pool/consen…monero/address/wallet/legacy.go#L82

That recovers the target spend pub and matches it against the ones we have in the hashmap

<jeffro256> The wallet calculates all the address spend pubkeys ahead of time, puts them in the subaddress map, then when scanning an enote, calcuates K^j_s = K_o - H(r K^v)G G, then looks up K^j_s in the subaddress map

So effectively it does a single scan

See web.getmonero.org/resources/research-lab/pubs/MRL-0006.pdf

<jeffro256> Also there isn't an infinite number of them which the current addressing scheme, there's only 2^64

And generally getmonero.org/library/MoneroAddressesCheatsheet20201206.pdf is helpful

<jeffro256> And then there's another hard cap on the number of elliptic curve points in ed25519 in the prime order subgroup

okay, let's get the first question first. As far as I understood, we are able to translate our logic directly into EC cryptography. For example, we have a logic first: "cannot spend tx without knowing shared secret AND secret spend key", and we translate it into maths as putting the hash of shared secret and public spend key, and applying this "AND" as EC addition.

what part of our logic corresponds this "hashing"?

I feel like I have to understand a fundamental thing about EC operations

Otherwise this is just some fancy maths for me

<jeffro256> The shared secret is actually an curve point for which you don't necessarily know the discrete logarithm to. You can't add it directly, othwerwise the receiver wouldn't know the discrete log of the one-time address, and thus couldn't spend the funds. The hash converts some secret value into a scalar, which we can multiple agai [... too long, see mrelay.p2pool.observer/e/rYzq-cUKYlUxeVg2 ]

It makes sense, but I have to see it myself. Let's make an example for this case. We don't hash it, thus, the one-time public key is K^o = r K^v + K^s, and the senders shares K^o and rG. Then, the receiver has k^v and k^s, thus, r G k^v = r K^v and k^s G = K^s. So, K^o = r K^v + K^s.

Oh wait, I guess the issue isn't deriving the one-time public key, but rather, its corresponding private key, which is used to sign the ring

its corresponding private key is the discrete logarithm of one-time public key, and if we don't use hashing, then we cannot get it

anyway ty, will think about it

21:26:15 <zarathust> what part of our logic corresponds this "hashing"?

shared secret = H(r K^v)

G -> pubkey

someone in control of viewkey has H(r K^v) (secret one time scalar)

the H() part falls outside of EC math, it's just a way to deterministically generate a scalar that receiver can generate

I again link the wallet imp git.gammaspectra.live/P2Pool/consen…onero/address/wallet/legacy.go#L182

Opening calculates the necessary scalars to spend the one-time output

later on git.gammaspectra.live/P2Pool/consen…ero/address/wallet/interface.go#L62

CanOpenOneTimeAddress

okay this implementation stuff is kinda confusing, I gotta understand the math first

tbh implementing carrot made things clearer for me

I don't know Go yet, and this is too much at once for me lol

if you want to complicate your life github.com/jeffro256/carrot/blob/master/carrot.md

if you know rust, carrot-rs was the inspiration (and source for the comments

And I'm still not sure about the reason we generate a scalar by hashing, and not directly using the EC point etc., and even if I accept this, I still don't understand some parts about subaddresses: for example, why do we define public-sub view key K^{v,i} as k^v K^{s,i}? Yes, it works mathematically, but are there any logical reasons behind it?

DataHoarder: nice source

I'm also planning to implement all monero cryptography myself, but I'll probably use python and sagemath

zarathust: "directly using the EC point" which point specifically?

as for subaddresses, read web.getmonero.org/resources/research-lab/pubs/MRL-0006.pdf

this explains some of the reasonings behind it

As I wrote before: "Let's make an example for this case. We don't hash it, thus, the one-time public key is K^o = r K^v + K^s, and the senders shares K^o and rG. Then, the receiver has k^v and k^s, thus, r G k^v = r K^v and k^s G = K^s. So, K^o = r K^v + K^s." I mean, hashing makes me feel like encoding in this context. We are just converting a value into another value, and we don't even have one-way function concerns here. Then

what's the point?

MRL-0006 >>> ++

Yes, I'll read this and think more about this before asking further

probably there are some points I'm missing

point 5.1

you also have a minor/major subaddress index, these are indeed hashed

the point in one time addresses is the result of key exchange, zarathust

you should not use these points directly (you also don't have it's secret counterpart) so it's used in hashing

it's similar to X25519 but the operations are done in Edwards25519 ->

then a new scalar (Secret data) is derived from that

it is standard for the ECDH to derive the final secret using hashing of this point (plus other context)

so it is similar but different. for one time address derivations, it's due to ECDH point being hashed

on viewkey, viewkey scalar is interpreted as pure bytes and hashed along with the account index, subaddress index (uint32)

then that gets a scalar for that

Yes, I guess this scalar conversion is a standart coming from elliptic curves, and not about monero cryptography

DataHoarder: you should not use these points directly (you also don't have it's secret counterpart) so it's used in hashing >>> Can you also make this point more clear? You mean random r by "secret counterpart"?

generally it converts a point that may be linked to original derivations to an irreversible scalar

for ECDH you do this. A = k_a * G, B = k_b * G. You now share A, B and calculate P = k_a * B, P = k_b * A

to get k_p * G = P you'd need both secret sides

k_p is secret counterpart

effectively you never use this

<jeffro256> > Oh wait, I guess the issue isn't deriving the one-time public key, but rather, its corresponding private key, which is used to sign the ring > <zarathust> Oh wait, I guess the issue isn't deriving the one-time public key, but rather, its corresponding private key, which is used to sign the ring

<jeffro256> zarathust: This is correct

"it converts a point that may be linked to original derivations to an irreversible scalar" >>> hmm, then can I consider its high-level function as following?: "When deriving a subkey from original key, hashing allows us to make it irreversible for a given subkey, which unlinks the subkey from original key"

DataHoarder: k_p is secret counterpart, effectively you never use this. >>> Got it! And can you also explain "you should not use these points directly" part?

zarathust: there is a definite linkage, as long as you know all values used to derive it. but someone without these can't link them backwards, yes

jeffro256: This is correct >>> Yes, I feel it, but cannot see it lol

Maybe hashing is used to make one-time public keys "uniformly distributed"?

<jeffro256> The ECDH's discrete log against G is a function of the sender's ephemeral private key, which you do not know. Thus, you cannot know the discrete log of the ECDH. If you do not know the discrete log of the ECDH and you add it directly to your address spend pubkey, then you cannot know the discrete log of the one-time address be [... too long, see mrelay.p2pool.observer/e/jMSV_MUKdllYMHVS ]

Maybe hashing is used to make one-time public keys "uniformly distributed"? >>> Otherwise, since we have same view key, the distribution of one-time keys would be only up to the random value chosen by sender. But by hashing it, we ensure that it is indeed "uniformly distributed"

<jeffro256> No, the one-time public keys will be uniformity distributed if and only if the sender's ephemeral private key is uniformly distributed. Hashing the ECDH will not hurt nor help this

yes, zarathust

but this is usually relevant when used for let's say, different contexts

<jeffro256> Hashing doesn't help b/c if the ephemeral pubkey is the additive identity element, then hashing the additive identity element and a transaction-local output index does not provide any hiding: the sender extension is effectively public.

<jeffro256> And an external observer can determine which address spend pubkey the enote is destined to.

jeffro256: The ECDH's discrete log against G [...] >>> very nice explanation!

<jeffro256> The hash-to-scalar is used to make the resulting sender extension scalar bit-independent for different outputs in the same transaction which might shared the same ECDH. For example, if you sending to 10 of the same main address, there will only be one ephemeral pubkey, and the ECDH for the different outputs is the exact same, [... too long, see mrelay.p2pool.observer/e/39Gr_MUKNThpTGhi ]

jeffro256: oh yes "domain seperation" is also another reason why we hash it

<jeffro256> Sure, you can think of hashing in the transaction-local output index into the one-time address as domain separation for the different outputs in the transaction

but I feel like the main reason is that we cannot retrieve sender's ephemeral private key, thus, we don't try this. Instead of going backwards and trying to retrieve it, we push it forward by hashing the point of shared secret (which results in actual shared secret) and use this as part of the one-time secret key besides spent key

I hope this is true

also - I think see answer crypto.stackexchange.com/questions/…7/ecdh-security-when-no-kdf-is-used point 2

(cheon's attack)

it allows efficiently attacking a set of targets compared to individually attacking each one

hashing breaks this linkage

DataHoarder: wow this is kinda confusing

Again, I feel the point, but cannot grasp it

For example, if an oracle can get h -> h^x, then why it cannot get h -> H(h^x)?

Isn't it possible to make h -> h^x -> H(h^x)?

it cannot be iterated

but I'd need to read more there, it escapes me as well :D

you can do that for individual outputs zarathust

but not aggregate all of them in an efficient manner

there is no end of it lol

not aggregate all of them [...] >>> yes, probably something like that

generally zarathust safecurves.cr.yp.to/rho.html can be applied in parallel if you have multiple points

I hope this is true >>> tbh if this understanding of mine was correct, then it's sufficient for me

by unlinking them finding one doesn't give you knowledge of anything before H part, nor linkage

"Does rho become cheaper against multiple targets?"

I think this is because hash function somehow makes is more ""uniformly distributed" and unlinks it from its real value

idk

this is also too deep for me xd

that'd require reversing H(...)

say, reverse SHA256 or Keccak256

you also cannot reverse h^x