00:02:20 <UkoeHB> jberman[m]: The problem with AOPP you linked to is not clear to me. Aren’t exchanges that require a certificate on withdrawal already doing KYC/AML? For that matter, what do exchanges even gain by having certified withdrawals?
00:04:22 <UkoeHB> If there is a problem, it wouldn’t be at exchanges, but in a marketplace of vendors are required to only interact with ‘approved’ users/wallets.
00:04:30 <UkoeHB> if vendors*
00:06:36 <UkoeHB> Which honestly isn’t far-fetched for a possible dystopian future.
00:07:28 <jberman[m]> They gain cryptographic proof that you are the owner of your withdrawals, across exchanges. It's a step above KYC/AML, and paves a stronger path toward cryptographic identity tied to your economic actions everywhere not just at exchanges. Practically, you have lesser ability to claim your online account was hacked, or that the exchange faked a withdrawal not initiated by you
00:08:01 <jberman[m]> And even more practically, that issue I explained in my first comment: users will need education to know that they're not accidentally leaking their identity across exchanges/merchants, even though they're using different "c" addresses
00:09:50 <jberman[m]> it supercharges KYC
00:13:07 <jberman[m]> <jberman[m]> "And even more practically..." <- I guess there would probably only be one primary certified address to avoid this. which could then pidgenhole people into potentially only being allowed to use "c" addresses at regulated businesses
00:13:16 <jberman[m]> and has the same issue
00:18:01 <UkoeHB> Hmm I see what you mean. Is there an alternative approach that provides the same/similar UX benefits (address books) with less of a drawback?
00:18:32 <jberman[m]> Another issue: if I share my certified address with Bob at date 0, then I share it with Alice at date 1, then Bob and Alice both have cryptographic proof that I was privvy to a transaction with both of them = worse privacy for me. Whereas without certified addresses, Alice and Bob don't have cryptograhpic proof that I was the sole counter-party in both transactions
00:20:07 <jberman[m]> I'm not sure, but I think it's a pro not a con to not have cryptographic proof of transactions with a counter-party by default
00:21:00 <jberman[m]> or at least proof that ties their identity to the transaction
01:06:21 <BusyBoredom[m]> Certified addresses should really only be used by merchants to simplify verification, right? So can't we protect users by simply hiding certified addresses behind an "advanced" menu or similar? Treat them like integrated addresses and shove them in the corner for use by experienced users. 
01:19:54 <jberman[m]> It paves the way for worse privacy for merchants too. Signing receipts = different counter parties can aggregate a business' sales in a cryptographically certified way, which is more valuable data than data without
01:34:12 <jberman[m]> Plus all it takes is one wallet to implement it as default and all others already have the integration with that wallet set up
05:02:48 <jberman[m]> <UkoeHB> "Hmm I see what you mean. Is..." <- Lol, the answer is integrated addresses :/ I think for all of integrated address' problems, this drawback from certified addresses is larger imo. With both integrated and certified, you have to trust you receive the correct contact info on first communication
05:04:00 <hyc> that's typical for any system, you have to have a trusted initial contact to establish credentials
05:06:44 <jberman[m]> right I'm saying the benefits certified addresses would provide are on par with integrated because of that
10:46:45 <dangerousfreedom> I'm struggling to decode the meaning of the 'signature' field in the pre-ringct (v1) version. According to ZTM2, page 31, it should be σ(m)=(c1,r1,...,rn) but how can I decouple this big string into the different variables? For example at tx https://xmrchain.net/tx/beb76a82ea17400cd6d7f595f70e1667d2018ed8f5a78d1ce07484222618c3cd . I still couldnt find an implementation of that in python, so I will try to code mine. Many
10:46:45 <dangerousfreedom> thanks again.
13:13:26 <UkoeHB> dangerousfreedom: ZtM2 doesn't talk about pre-ringct
14:26:50 <BusyBoredom[m]> jberman: I think we really should have some mechanism of verifying merchant's addresses though. With individuals it's easy because you can just check the RID and then add the address to your address book, but with merchant's you can't do that ('cause you never know which subaddress you'll get at checkout). 
14:26:50 <BusyBoredom[m]> Are you proposing we return to using integrated addresses, so that users can add the base address to their address book? What is the privacy advantage of that over certified addresses? 
14:35:21 <BusyBoredom[m]> I guess what I'm lost on is that a bad wallet implementation could just as easily default to generating integrated addresses that all use the same base address and a naïve user would still end up having linkable addresses. So is this a problem with certified addresses, or is it really a UI issue? 
14:35:21 <BusyBoredom[m]> Or taking it one step further -- what makes certified addresses more dangerous than primary addresses? Most new users I've interacted with seem to use their primary address exclusively as it is. 
14:38:04 <dangerousfreedom> <UkoeHB> "dangerousfreedom: ZtM2 doesn't..." <- Okay, I thought I was understanding but now I dont understand anything. The scheme you describe on page 31 is the bLSAG and it was used in the first version (v1) of Monero, right? If not, where can I find what the field 'signature' means in the first transactions?
14:40:30 <UkoeHB> jberman[m]: answered this yesterday: "See section 4.4 for the first ring sig implementation: https://www.bytecoin.org/old/whitepaper.pdf"
17:18:18 <spirobel[m]> Hi I have trouble forking the CCS-proposals repo on the monero gitlab instance. It says my projects limited is exceeded. I already added ssh key, api token and password (as mentioned in the UI notice). Is there anything else I need to do? my gitlab username is spirobel.
17:25:44 <spirobel[m]> * is spirobel. ( sorry, just realized i posted this in the wrong channel)
17:27:27 <moneromooo> You just need to tell me about it so I can fix it.
17:30:01 <moneromooo> Fixed.
17:39:38 <spirobel[m]> <moneromooo> "Fixed." <- thanks! 👍️
17:49:34 <dangerousfreedom> <UkoeHB> "jberman: answered this yesterday..." <- Ok. I see. bLSAG was never implemented on the code, in the first version it was only LSAG, right? The difference is that in order to generate the key image, bLSAG uses I = xH(P) , where P is the public key of x, while in the LSAG, the key image is I = xH(R) , where R is public keys in the ring, right? So there is this problem of linkability if someone creates a transaction
17:49:34 <dangerousfreedom> with the same ring members... is it correct?
17:52:38 <UkoeHB> no, neither LSAG nor bLSAG were implemented; only cryptonote ring signatures, MSLAG, and CLSAG; cryptonote ring sigs were a pre-cursor to LSAG
17:55:21 <dangerousfreedom> Ahh okay. Thank you very much UkoeHB . Consider that I am very stupid so please be patient :)
17:57:13 <dangerousfreedom> So the signature field should have the format σ = (I, c1, . . . , cn, r1, . . . , rn) as described in the cryptonote paper instead of those described in your book, which is σ(m) = (c1 ,r1,r2, ..., rn)
17:57:34 <dangerousfreedom> But still, I dont know how to decouple them. 
17:58:27 <dangerousfreedom> For example, if we take the first transaction: https://xmrchain.net/tx/beb76a82ea17400cd6d7f595f70e1667d2018ed8f5a78d1ce07484222618c3cd/1
17:59:01 <dangerousfreedom> What it means this signature:   "signatures": [
17:59:01 <dangerousfreedom> "a9e1d89bc06b40e94ea9a26059efc7ba5b2de7ef7c139831ca62f3fe0bb252008f8c7ee810d3e1e06313edf2db362fc39431755779466b635f12f9f32e44470a3e85e08a28fcd90633efc94aa4ae39153dfaf661089d045521343a3d63e8da08d7916753c66aaebd4eefcfe8e58e5b3d266b752c9ca110749fa33fce7c44270386fcf2bed4f03dd5dadb2dc1fd4c505419f8217b9eaec07521f0d8963e104603c926745039cf38d31de6ed95ace8e8a451f5a36f818c151f517546d55ac0f500e54d07b30ea7452f2e93fa4f60bdb30d71a0a97f
17:59:01 <dangerousfreedom> 97eb121e662006780fbf69002228224a96bff37893d47ec3707b17383906c0cd7d9e7412b3e6c8ccf1419b093c06c26f96e3453b424713cdc5c9575f81cda4e157052df11f4c40809edf420f88a3dd1f7909bbf77c8b184a933389094a88e480e900bcdbf6d1824742ee520fc0032e7d892a2b099b8c6edfd1123ce58a34458ee20cad676a7f7cfd80a28f0cb0888af88838310db372986bdcf9bfcae2324480ca7360d22bff21fb569a530e"]
18:00:06 <dangerousfreedom> Any resource where I can find this answer other than the C++ code and the cryptonote paper?
18:02:28 <UkoeHB> You could dig around on the stackexchange: https://monero.stackexchange.com/
18:02:41 <UkoeHB> The C++ code is your best bet though, since all the serialization is there.
18:05:57 <dangerousfreedom> UkoeHB: I have briefly tried to understand the code v0.9 by just reading and didnt have much success (my c++ skills are very rusty also)
18:06:48 <dangerousfreedom> Thanks. I will see what I can do. I was expecting to advance faster but I will probably be stuck here for a while
18:36:07 <dangerousfreedom> I believe I found it!! There is an implementation here I guess https://github.com/monero-project/mininero
18:36:08 <dangerousfreedom> At least it was reported here https://web.getmonero.org/resources/research-lab/pubs/MRL-0003.pdf
18:36:08 <dangerousfreedom> Nice :)
18:50:02 <jberman[m]> BusyBoredom:  maybe I am overblowing and conflating issues
18:50:02 <jberman[m]> > Are you proposing we return to using integrated addresses, so that users can add the base address to their address book
18:50:02 <jberman[m]> This would be possible with integrated addresses ya
18:50:34 <jberman[m]> Certified addresses go a step further than reusing a primary or integrated address because you are providing a digital signature of the address to prove ownership
18:50:34 <jberman[m]> If I give you a certified address, and later I give Bob a certified address, you and Bob have proof that I am in control of the address on separate occasions
18:50:34 <jberman[m]> If I give you my primary or integrated address, and I give Bob the same address, you and Bob don't have proof I am in control of the address
18:50:55 <jberman[m]> In the latter, I have plausible deniability that I control the address. In the former I do not. The boating accident meme is gone e.g. if I give out my certified address, the counter-party knows I still have control over the address
18:51:19 <jberman[m]> Maybe the one critical difference to highlight between this and AOPP, is that in AOPP you sign a message produced by the counter-party. Whereas with certified addresses, you just sign the address. Which means I could in theory pre-generate tons of addresses + signatures, and the counter-party does not know the signature they're getting still prove I own the address at that point in time
18:59:06 <jberman[m]> and of course, that in AOPP you're signing a message specifically designed to benefit regulatory requirements