11:01:18 I read that FCMP will make transactions hidden even from quantum computers, does this only apply to the sender side? FCMP doesn't affect stealth addresses does it? 11:11:39 It brings forward secrecy and some improvements but not full post-quantum privacy. The TL;DR (jeffro256 please correct me) is: 11:11:40 - On-chain data cannot be used to break privacy 11:11:42 - If a post quantum computer have access to a public address, it will be able to break amount and sender of transactions to this address (and i think other). Detect with way higher precision if an enote is actually owned by this wallet. 11:11:44 - Churning transactions are actually quantum proof as they are using symmetric encryption. 11:11:46 - Due to CARROT key hierarchy, a QC cannot compute the seed from publicly available infos like public address. And I think since each keys are derivated having the view keys don't compromise the spend keys but i could be wrong 11:12:21 QC cannot compute the main private key 11:44:25 I think this is incorrect? 11:44:26 Ring sigs are vulnerable 11:44:28 If they have an address, they can see which coins were spent to that address. 11:44:30 Churning transactions if quantum proof? How does it use symmetric crypto? 11:48:24 I was talking of FCMP/Carrot here 12:55:05 This is correct , just want to clarify though that churning/selfsends are only quantum forward secret if you have the Carrot key hierarchy (I.e. you will have to generate new private keys and new addresses than today) 13:00:49 Jeffro, just read the mrl meeting backlog re serialization limits. 13:00:50 - 1mb block size limits sounds very bad. 13:00:52 vtnerds 8867 gets rid of the dom and fixes the serialization limits 13:01:14 The ring signatures aren't the main thing that is vulnerable to quantum adversaries (they are). The main problem is the key image composition . For an enote with output pub key O = x G, the key image is L = x HP(O). This is 100% deterministically trackable by a QC . However, with FCMP++'s composition proof (SA/L), the output pubkey knowledge is spread over two independent generat 13:01:14 ors: O = x G + y T, and the key image is L = x Hp(O). This definition is backwards compatible but effectively turns output pubkeys into Pederson commitments for the key image secret x, which is perfectly blinding and this private from QCs 13:01:48 You can sync up to ~25mb blocks is you only merge dynamic block sync size (even with serialization limits) 13:02:02 HP meaning ? 13:02:04 You can sync up to ~25mb blocks if you only merge dynamic block sync size (even with serialization limits) 13:03:45 ah Hash to Point got it 13:04:05 (i'm rudely interrupting psychoticbird. I can wait my turn) 13:08:18 Hp is the hash-to-point function used in Monero for key images. https://github.com/monero-project/monero/blob/c2e3835223943732cd9f293d4e85da3a7b837a0e/src/crypto/crypto.cpp#L611 13:10:18 Yes I definitely mean to rereview that PR soon 13:19:22 9494 (dynamic block sync size) is a relatively simple pr, and gets around the issue of batches of 1.5mb blocks hitting serialization, as well as syncing relatively consistent batch sizes instead of using a static value. Can still set a static value is one chooses to 13:19:36 8867 is a beast of a pr though 13:20:09 Ive tested both, separate and together, fwiw 13:20:31 (full chain syncs with 50mb batches) 15:50:32 Hello guys :) do you have experience with guardarian service? I'm looking to buy xmr with credit card in europe fastly. I know they have a KYC verification but I can deal with that 16:04:09 the alternative is to buy ltc from my verified kraken acc then swap on trocador but I have 0 experience with these exchanges services, is it fast enough? 16:14:57 It’s fast 16:16:21 It's so fast I received my btc before sending my xmr 16:16:35 specultative to the next level 16:39:09 hehe :D 16:39:17 thanks guys 20:42:42 Hi