13:27:36 <slave_blocker> hello :)
13:30:31 <slave_blocker> just a sanity check for me, let alice send a transaction to bob. The receiving one-time addresses of bob don't appear anywhere in the ringCT right?
13:31:31 <moneromooo> What is "[t]he receiving one-time addresses of bob" ?
13:31:53 <moneromooo> If you mean "the address Bob gave Alice to send to", then it does not appear in the tx.
13:32:37 <moneromooo> But your wording suggests it's not that. If you mean the output pubkey, then it's obviously in the tx. If something else, be more precise.
13:33:45 <moneromooo> Also, I take "ringCT" to mean the entire tx. If you just mean the ringct structure, then the output pubkey technically isn't, it's in the prefix. I don't think that's what you meant, even though you did say ringct and not tx.
13:48:42 <slave_blocker> well, as far as i have understood, when alice sends a tx to bob, she must first prove she owns the outputs she is spending.
13:51:26 <slave_blocker> if i refer to zero to monero page 138, there is the part of the tx that for me represents the ring signature, from line 81 until 129.
13:54:28 <slave_blocker> so basically what i m asking is if the ring signature only contains the previous one-time public addresses (wich are now inputs), and the corresponding output commitments (pseudo and normal).
13:55:20 <moneromooo> The tx prefix contains indices pointing to the output pubkeys included in the rings. In each ring, one of those will be the one that gets spent.
13:59:40 <slave_blocker> Bob's ownership is upon the addresses in vout right? line 27 and 32 in this case. What i am asking is if bob's keys appear in the ring signature...
14:00:42 <moneromooo> If by "bob's keys" you mean the public keys of bob's destination address, then those do not appear in the tx.
14:01:08 <moneromooo> The output pubkey of the new output now belonging to bob does.
14:01:26 <slave_blocker> yes
14:01:37 <slave_blocker> but not in the ring signature right?
14:02:15 <moneromooo> Right.
14:02:19 <slave_blocker> :)
14:02:30 <slave_blocker> thanks
14:02:36 <slave_blocker> also,
14:03:14 <slave_blocker> second sanity check,
14:09:54 <slave_blocker> the commitments to the new amounts now belonging to bob, who now owns these new output pubkeys, also don't appear in the ring signature right? page 137, namely the "outPk"'s of the transaction at hand.
14:22:02 <moneromooo> I guess it depends what you call the ring signature.
14:22:08 <moneromooo> The outPk are included in the ringct structure.
14:27:23 <slave_blocker> i am calling the ring signature the part of the tx where there is "MGs"; page 138 line 81 to 129.
14:28:21 <moneromooo> Then it is there.
14:28:59 <slave_blocker> the outPk are not in the MGs in any way right?
14:31:44 <slave_blocker> they naturally would invalidate the ringct, if the sums of input commits - sums of output commits - fH != 0 . But they are not part of the mlsag ?
14:32:24 <moneromooo> They are not in MGs.
14:32:44 <moneromooo> MGs and outPk are alongside each other in the same structure.
14:32:56 <slave_blocker> moneromooo, thanks for your patience :)
14:32:57 <moneromooo> Well, one's in the prunable part and the other in the unprunable part.
14:38:38 <coinstudent2048[> Hello! I started dumbp256k1: https://github.com/coinstudent2048/dumbp256k1. The only implemented so far are the Scalar and Point classes.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/462517d932797c88a84b8f245b99fa42be35fe03)
14:58:19 <slave_blocker> another thing, how are the ring one-time addresses referenced? I can only see the "vin" part, "key_offsets" there i count 11 numbers referencing to block numbers but not tx's ?
15:10:03 <moneromooo> key offsets refer to outputs, not blocks.
15:12:46 <UkoeHB> coinstudent2048[: interesting thanks :)
16:04:00 <slave_blocker> how are the one-time addresses found?
16:09:08 <wernervasquez[m]> slave_blocker: step 3 on page 38 of ztm for standard addresses
16:09:15 <wernervasquez[m]> Ztm2*
16:09:17 <slave_blocker> from page 136 : "key_offsets": [ 14401866, 142824, 615514, 18703, 5949, 22840, 5572, 16439,
16:09:17 <slave_blocker> 983, 4050, 320]
16:11:07 <wernervasquez[m]> slave_blocker: step 3 on page 40 of ztm2 for subadddresses
16:12:24 <slave_blocker> how do these 11 numbers represent 11 "vin"'s ?
16:14:00 <slave_blocker> wernervasquez[m], thanks for the reply, but i mean how are the ring members found?
16:46:46 <UkoeHB> slave_blocker: chapter 6 footnote 13
16:53:12 <jtgrassie> slave_blocker: https://monero.stackexchange.com/a/12368/7493
20:25:56 <fr33_yourself[m]> <moneromooo> "The output pubkey of the new..." <- Just to clarify my understanding, Bob's (recipient) actual pub address is nowhere in the blockchain or transaction, but his onetime stealth address (randomly generated) is? I am a noob to the tech of Monero. How "random" is the generation of stealth 
20:27:37 <fr33_yourself[m]> * generation of one-time recipient addresses in Monero? I watched Sarang Noether discuss this with the ciphertrace guy and it appears ciphertrace hasn't broken the stealth, * stealth addresses used for recipients? Does this still seem to be the case? 
20:28:38 <slave_blocker> the public addresses are nowhere to be seen in the xmr chain.
20:29:03 <slave_blocker> its only one-time addresses.
20:29:17 <fr33_yourself[m]> Niceu. Thanks 
20:29:40 <slave_blocker> i call the addresses but i guess they are rather one time public keys...
20:30:20 <slave_blocker> these are subtle syntactic nuances...
20:30:34 <fr33_yourself[m]> I intend on reading Zero to Monero after finishing Mastering Monero. So I haven't gotten into the details of how the stealth addresses are generated yet.
20:31:32 <fr33_yourself[m]> slave_blocker: Yep I just learned about Monero around Christmas last year, so apologies if I botch the official/technical syntax
20:45:57 <moneromooo> I dunno what a onetime stealth address is. Don't use that term, different people mean different things with it. Worse even, some use that term without even knowing what they intend to mean.
20:46:23 <moneromooo> Assuming you mean the output pubkey (which is not an address), this one is on the chain.
20:46:49 <slave_blocker> oh
20:46:59 <slave_blocker> so i'm wrong...
20:47:48 <slave_blocker> so it's a one time public key?
20:48:27 <slave_blocker> why does it get referred to as a stealth address?
20:48:30 <moneromooo> Depends what you mean by "it" here.
20:51:02 <slave_blocker> well from what i understand, the members of a ring signature (inputs) from "vin", aswell as the "vout" public keys, are all one-time...
20:51:43 <slave_blocker> Now i was calling them one-time addresses. and i heard about them as stealth addresses...
20:52:08 <wernervasquez[m]> <moneromooo> "I dunno what a onetime stealth..." <- Does monero have a style guide? Or some authoritative reference? IMO one time address desribes it well as does output pubkey....
20:52:30 <moneromooo> The members of a ring are outputs, and each output has a public key. They're one time enough, though you can tachnically construct dupes.
20:53:11 <moneromooo> wernervasquez[m]: try to match hte style of whatever you're modifying at first approximation.
20:53:29 <moneromooo> There's no fascist style guide.
20:53:38 <slave_blocker> :)
20:54:17 <dangerousfreedom> > <@coinstudent2048:matrix.org> Hello! I started dumbp256k1: https://github.com/coinstudent2048/dumbp256k1. The only implemented so far are the Scalar and Point classes.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0af4c8da3df00f1207a75dbc3d2c60b1eab911e7)
20:54:35 <dangerousfreedom> I will present my results by the end of the week. Now I have something to show :)
20:57:16 <w[m]> dangerousfreedom: Thats good news or bad 🙃
20:59:09 <fr33_yourself[m]> <moneromooo> "I dunno what a onetime stealth..." <- I will try not to use that term moving forward. To restate my question, on the blockchain there is a recipient address shown right? The output goes from sender to recipient, but on YouTube videos I heard that the recipient's true address is kept private to only themself and the sender. Not even miners can see the receiver's true address. The recipient address shown on
20:59:10 <fr33_yourself[m]> chain is random, thus unknowable? Is my understanding here correct or incorrect?
21:02:09 <fr33_yourself[m]> I don't have a technical understanding of the method by which a random address/key for onchain is generated, so I was more so hoping to hear it's super random and ciphertrace can pound sand haha
21:02:14 <dangerousfreedom> w[m]: I hope it is good news :p
21:02:14 <dangerousfreedom> I have been spending a lot of time to build some tools and some educational material to explain (to myself and others) why there is no inflation in monero.
21:03:23 <slave_blocker> pound sand
21:03:27 <slave_blocker> ;)
21:04:41 <moneromooo> The recipient address is not on the chain.
21:05:01 <moneromooo> Not even encrypted.
21:05:10 <fr33_yourself[m]> moneromooo: Oh that is super strong privacy then
21:06:09 <moneromooo> Basically, when an output is created, it's done in such a manner that the recipient (and only the recipient) can calculate its secret key, using the recipient's secret keys, and is thus the only person able to spend it.
21:06:38 <moneromooo> So there is no keeping track of who owns what by means of assigning outputs to addresses like it Bitcoin.
21:06:46 <moneromooo> And thus no need to have addresses on chain.
21:07:24 <moneromooo> s/ like it Bitcoin/
21:07:48 <moneromooo> er, ,/$,//,
21:07:59 <fr33_yourself[m]> moneromooo: I wish the btc maxis I spoke to knew this haha
21:08:25 <fr33_yourself[m]> Monero too stronk, thank you moneromoo for helping make it stronk. 
21:08:45 <moneromooo> np, none of the theory is mine fwiw.
21:09:05 <fr33_yourself[m]> Yes, but you are a bigtime dev
21:09:16 <fr33_yourself[m]> Without the devs we would not have Monero 
21:09:29 <fr33_yourself[m]> and without monero i would be permatrapped in fiat slavery haha
21:14:51 <fr33_yourself[m]> <moneromooo> "Basically, when an output is..." <- Is it the case that the output is created / encrypted with one of receiver's keys, such that only his wallet can decrypt/know he owns it? The output is encrypted when it is created/being sent? If my understanding is correct, a similar process is used in transparent ledgers with regards to ability to spend outputs, but in Monero it is the case that knowledge of owning funds
21:14:51 <fr33_yourself[m]> is encrypted such that only the receiver's private view key can decrypt this knowledge of output ownership?
21:15:48 <moneromooo> I... think so :) It's not really encrypted, but close enough.
21:17:42 <fr33_yourself[m]> moneromooo: To the best of your understanding the method by which output ownership is kept private is both secure and legit though right? I'm sure all of the nitty gritty are in Zero to Monero, I just haven't made it to that stage of understanding/reading yet.
21:17:56 <moneromooo> Yes.
21:18:47 <fr33_yourself[m]> Gotcha, thanks :)  I have a couple more questions if you don't mind my asking 
21:20:48 <fr33_yourself[m]> Let's say an individual has a cold wallet that has never come online, will this individual need to do anything prior to the coming hardfork to make sure nothing goes amiss? I would also wonder how this will work when Seraphis comes, but that will probably be a question for later when Seraphis is ready for deployment. Could anyone make a guess as to how long Seraphis would be tested prior to implementation for Monero
21:20:48 <fr33_yourself[m]> users?
21:25:49 <moneromooo> Nothing to do prior to the fork.
21:25:54 <rbrunner> I assume your "cold wallet" consists of a standard Monero 25 word seed. Those will continue to work, Seraphis or no Seraphis. Nothing to prepare then.
21:27:49 <fr33_yourself[m]> moneromooo: Sweet, I wouldn't want the boating accident meme to become a reality haha
21:27:53 <rbrunner> If you mean a Monero wallet file that you just never use and don't sync: Monero will have to keep the capability to import such wallet files somehow indefinitely, I would say
21:31:38 <fr33_yourself[m]> <rbrunner> "I assume your "cold wallet..." <- So the idea with implementing Seraphis is that every single wallet's mnenomic seed will remain unchanged, but all of their public and private keys will change. Meaning that if one has the seed saved somewhere they will be fine, even if they boot up their wallet one year post-Seraphis implementation and their public and private keys (character strings) have all changed?
21:33:39 <fr33_yourself[m]> <rbrunner> "If you mean a Monero wallet file..." <- It's more so a question of an untouched cold wallet that never spends or goes online, and is only synced as a viewonly wallet. Even this unspent/receive only cold wallet will be a-ok?