04:36:41 <br-m> <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
04:38:51 <br-m> <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 https://mrelay.p2pool.observer/e/mo-73sUKOW1QdVJf ]
04:41:11 <br-m> <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 https://mrelay.p2pool.observer/e/t9XD3sUKSkNtdVJv ]
04:45:46 <br-m> <ofrnxmr:xmr.mx> @fr33_yourself: Yea
04:50:13 <br-m> <fr33_yourself> ooo is GOATed
04:50:37 <br-m> <fr33_yourself> It is crazy that he shows no mercy and basically rewrites whole chunks of the code though. No mercy from him
12:15:08 <br-m> <spacekitty69420:matrix.org> craziness, literally yesterday got called a lil bitch, to shut up, to send pics
12:15:08 <br-m> <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
13:38:04 <br-m> <sk420:matrix.org> https://forums.d2jsp.org/topic.php?t=106240674&f=383&p=679795244
13:38:04 <br-m> <sk420:matrix.org> in case u missed it, not gonna make alt accounts, thank you to anyone that saw value in those markets
13:38:05 <br-m> <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!
20:16:48 <zarathust> Hey, I have two questions about Monero subaddresses:
20:17:02 <zarathust> 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?
20:18:09 <DataHoarder> It creates a secret and calculates its public key
20:18:14 <DataHoarder> Then adds the spend pubkey to it
20:18:39 <DataHoarder> That way you cannot spend this without knowing H(r K^v) AND secret spend key
20:19:03 <zarathust> 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.
20:19:09 <DataHoarder> That addition there is a standard, same way for subaddresses. It's shifted so you can't spend it with viewkey only
20:19:40 <DataHoarder> You can. You build a subaddress map ahead of time linked to your spendkey
20:19:56 <DataHoarder> Due to how subaddresses are calculated, you just scan using the viewkey, then do a constant lookup on a hashmap
20:20:10 <DataHoarder> That gets you the subaddress index
20:21:18 <DataHoarder> As an example of what I implemented for view wallet lookups https://git.gammaspectra.live/P2Pool/consensus/src/commit/ea8d8f4f252a5b31ce46342839646f3034920b56/monero/address/wallet/legacy.go#L82
20:21:56 <DataHoarder> That recovers the target spend pub and matches it against the ones we have in the hashmap
20:22:08 <br-m> <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 
20:22:09 <DataHoarder> So effectively it does a single scan
20:22:23 <DataHoarder> See https://web.getmonero.org/resources/research-lab/pubs/MRL-0006.pdf
20:22:28 <br-m> <jeffro256> Also there isn't an infinite number of them which the current addressing scheme, there's only 2^64
20:22:42 <DataHoarder> And generally https://www.getmonero.org/library/MoneroAddressesCheatsheet20201206.pdf is helpful
20:22:56 <br-m> <jeffro256> And then there's another hard cap on the number of elliptic curve points in ed25519 in the prime order subgroup 
20:25:50 <zarathust> 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.
20:26:15 <zarathust> what part of our logic corresponds this "hashing"?
20:27:53 <zarathust> I feel like I have to understand a fundamental thing about EC operations
20:28:30 <zarathust> Otherwise this is just some fancy maths for me
20:35:24 <br-m> <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 https://mrelay.p2pool.observer/e/rYzq-cUKYlUxeVg2 ]
20:46:19 <zarathust> 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.
20:47:01 <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
20:47:37 <zarathust> 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
20:56:49 <zarathust> anyway ty, will think about it
21:11:45 <DataHoarder> 21:26:15 <zarathust> what part of our logic corresponds this "hashing"?
21:11:59 <DataHoarder> shared secret = H(r K^v)
21:12:12 <DataHoarder> G -> pubkey
21:12:29 <DataHoarder> someone in control of viewkey has H(r K^v) (secret one time scalar)
21:13:11 <DataHoarder> the H() part falls outside of EC math, it's just a way to deterministically generate a scalar that receiver can generate
21:13:58 <DataHoarder> I again link the wallet imp https://git.gammaspectra.live/P2Pool/consensus/src/branch/master/monero/address/wallet/legacy.go#L182
21:14:17 <DataHoarder> Opening calculates the necessary scalars to spend the one-time output
21:16:33 <DataHoarder> later on https://git.gammaspectra.live/P2Pool/consensus/src/branch/master/monero/address/wallet/interface.go#L62
21:16:33 <DataHoarder> CanOpenOneTimeAddress
21:19:58 <zarathust> okay this implementation stuff is kinda confusing, I gotta understand the math first
21:21:11 <DataHoarder> tbh implementing carrot made things clearer for me
21:21:57 <zarathust> I don't know Go yet, and this is too much at once for me lol
21:23:13 <DataHoarder> if you want to complicate your life https://github.com/jeffro256/carrot/blob/master/carrot.md 
21:23:49 <DataHoarder> if you know rust, carrot-rs was the inspiration (and source for the comments
21:24:09 <zarathust> 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?
21:24:33 <zarathust> DataHoarder: nice source
21:24:54 <zarathust> I'm also planning to implement all monero cryptography myself, but I'll probably use python and sagemath
21:29:45 <DataHoarder> zarathust: "directly using the EC point" which point specifically?
21:31:53 <DataHoarder> as for subaddresses, read https://web.getmonero.org/resources/research-lab/pubs/MRL-0006.pdf
21:32:15 <DataHoarder> this explains some of the reasonings behind it
21:33:26 <zarathust> 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 
21:33:26 <zarathust> what's the point?
21:33:33 <zarathust> MRL-0006 >>> ++
21:33:45 <zarathust> Yes, I'll read this and think more about this before asking further
21:34:11 <zarathust> probably there are some points I'm missing
21:35:54 <DataHoarder> point 5.1
21:36:27 <DataHoarder> you also have a minor/major subaddress index, these are indeed hashed
21:37:13 <DataHoarder> the point in one time addresses is the result of key exchange, zarathust 
21:37:43 <DataHoarder> you should not use these points directly (you also don't have it's secret counterpart) so it's used in hashing
21:37:54 <DataHoarder> it's similar to X25519 but the operations are done in Edwards25519 -> 
21:38:16 <DataHoarder> then a new scalar (Secret data) is derived from that
21:39:12 <DataHoarder> it is standard for the ECDH to derive the final secret using hashing of this point (plus other context)
21:40:13 <DataHoarder> so it is similar but different. for one time address derivations, it's due to ECDH point being hashed
21:40:35 <DataHoarder> on viewkey, viewkey scalar is interpreted as pure bytes and hashed along with the account index, subaddress index (uint32)
21:40:50 <DataHoarder> then that gets a scalar for that
21:45:33 <zarathust> Yes, I guess this scalar conversion is a standart coming from elliptic curves, and not about monero cryptography
21:46:53 <zarathust> 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"?
21:46:54 <DataHoarder> generally it converts a point that may be linked to original derivations to an irreversible scalar
21:48:31 <DataHoarder> 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
21:48:53 <DataHoarder> to get k_p * G = P you'd need both secret sides
21:49:13 <DataHoarder> k_p is secret counterpart
21:49:16 <DataHoarder> effectively you never use this
21:49:54 <br-m> <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
21:49:54 <br-m> <jeffro256> zarathust:  This is correct
21:51:11 <zarathust> "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"
21:53:01 <zarathust> 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?
21:53:54 <DataHoarder> 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
21:54:09 <zarathust> jeffro256: This is correct >>> Yes, I feel it, but cannot see it lol
21:56:40 <zarathust> Maybe hashing is used to make one-time public keys "uniformly distributed"?
21:57:11 <br-m> <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 https://mrelay.p2pool.observer/e/jMSV_MUKdllYMHVS ]
21:58:21 <zarathust> 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"
21:58:24 <br-m> <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 
21:58:27 <DataHoarder> yes, zarathust 
21:59:02 <DataHoarder> but this is usually relevant when used for let's say, different contexts
21:59:48 <br-m> <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. 
22:00:43 <br-m> <jeffro256> And an external observer can determine which address spend pubkey the enote is destined to. 
22:02:37 <zarathust> jeffro256: The ECDH's discrete log against G [...] >>> very nice explanation!
22:03:12 <br-m> <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 https://mrelay.p2pool.observer/e/39Gr_MUKNThpTGhi ]
22:06:02 <zarathust> jeffro256: oh yes "domain seperation" is also another reason why we hash it
22:07:11 <br-m> <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
22:09:16 <zarathust> 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
22:09:27 <zarathust> I hope this is true
22:10:19 <DataHoarder> also - I think see answer https://crypto.stackexchange.com/questions/30367/ecdh-security-when-no-kdf-is-used point 2
22:11:59 <DataHoarder> (cheon's attack)
22:12:28 <DataHoarder> it allows efficiently attacking a set of targets compared to individually attacking each one
22:12:33 <DataHoarder> hashing breaks this linkage
22:19:04 <zarathust> DataHoarder: wow this is kinda confusing
22:19:29 <zarathust> Again, I feel the point, but cannot grasp it
22:20:14 <zarathust> For example, if an oracle can get h -> h^x, then why it cannot get h -> H(h^x)?
22:20:29 <zarathust> Isn't it possible to make h -> h^x -> H(h^x)?
22:21:21 <DataHoarder> it cannot be iterated
22:21:38 <DataHoarder> but I'd need to read more there, it escapes me as well :D
22:21:59 <DataHoarder> you can do that for individual outputs zarathust 
22:22:16 <DataHoarder> but not aggregate all of them in an efficient manner
22:22:21 <zarathust> there is no end of it lol
22:23:19 <zarathust> not aggregate all of them [...]  >>> yes, probably something like that
22:23:49 <DataHoarder> generally zarathust https://safecurves.cr.yp.to/rho.html can be applied in parallel if you have multiple points
22:23:50 <zarathust> I hope this is true >>> tbh if this understanding of mine was correct, then it's sufficient for me
22:24:15 <DataHoarder> by unlinking them finding one doesn't give you knowledge of anything before H part, nor linkage
22:24:28 <DataHoarder> "Does rho become cheaper against multiple targets?"
22:25:50 <zarathust> I think this is because hash function somehow makes is more ""uniformly distributed" and unlinks it from its real value
22:25:51 <zarathust> idk
22:26:03 <zarathust> this is also too deep for me xd
22:26:04 <DataHoarder> that'd require reversing H(...)
22:26:19 <DataHoarder> say, reverse SHA256 or Keccak256
22:26:27 <zarathust> you also cannot reverse h^x