14:47:29 <tevador> jeffro256: Carrot specs section 7.1.1 should explicitly say that the encrypted PID is only included in 2-output transactions. https://github.com/jeffro256/carrot/blob/master/carrot.md#711-payment-id
14:57:21 <br-m> <jeffro256> I intended to have a dummy PID in all transactions, even >2-out. The payment ID confirmation feature allows payment out to any amount of mixed addresses (still max 1 integrated address) and allow all recipients to recover their corresponding PID unambiguously. This is in constrast to the current situation where other main addr [... too long, see https://mrelay.p2pool.observer/e/r_yvr8EKdUtBc2ZL ]
15:02:19 <br-m> <kayabanerve:matrix.org> @jeffro256:monero.social: Even if you don't share your address, a QC can still link legacy spends, so your comment that legacy w/ LWS makes more sense if the address is hidden is wrong.
15:04:27 <br-m> <jeffro256> Yes, a QC can link current RingCT spends with a legacy address format, not FCMP++ spends with a legacy address format. I was comparing legacy address format vs Carrot address format on FCMP++ only
15:14:24 <tevador> jeffro256: I missed the PID confirmation part in the specs. Makes sense now, but I think it's a very niche use case.
15:15:53 <br-m> <jeffro256> That's fair. I would imagine the main use case is to makes batch payouts easier for large players
15:16:11 <tevador> The blockchain cost is nonzero, though.
15:17:29 <br-m> <kayabanerve:matrix.org> ... oh, right, sorry, CARROT still generates a y term even for legacy addresses, doy
15:18:35 <br-m> <jeffro256> Yes the cost is non-zero. For the record, Carrot doesn't need the encrypted payment ID to function, but it does PIDs better in case they are needed. Whether or not to include them by default in certain cases is a subjective design choice. 
15:19:47 <br-m> <jeffro256> IIRC, dummy PIDs are never included in >2-out, so if an encrypted PID is present in a >2-out tx, then an external observer knows that one of the recipients is an integrated address. We could make the same privacy / size trade-off
15:20:30 <br-m> <jeffro256> Or we could always include a dummy and not leak that information.
15:21:35 <DataHoarder> Interesting read about lack of validating points in FourQ https://www.botanica.software/blog/cryptographic-issues-in-cloudflares-circl-fourq-implementation
15:22:37 <br-m> <jeffro256> I honestly don't see 8 bytes per transaction as a huge deal considering that A) Zcash has a mandatory padding of 500 bytes for encrypted memos, and B) each Carrot enote is at least (32 + 32 + 16 + 3 + 8) bytes, not including ephemeral pubkeys. But I'm open to removing dummy encrypted PIDs by default in >2-out txs
15:24:23 <br-m> <jeffro256> A 1-in/3-out FCMP++/Carrot tx is ~6500 bytes, so removing its dummy ecncrypted PID would save 0.12% storage 
15:25:48 <br-m> <jeffro256> Though a dummy encrypted PID is a much bigger portion of the unpruned part of the transaction, which is what constitutes the bandwidth during wallet refresh 
16:23:20 <tevador> Would a 346-character Jamtis address be acceptable?
16:23:27 <tevador> Example: xmra1mj0b1977bw3ympyh2yxd7hjymrw8crc9kin0dkm8d3wdu8jdhf3fkdpmgxfkbywbb9mdwkhkya4jtfn0d5h7s49bfyji1936w19tyf3906ypj09n64runqjrxwp6k2s3phxwm6wrb5c0b6c1ntrg2muge0cwdgnnr7u7bgknya9arksrj0re7whkckh51ikxmra1mj0b1977bw3ympyh2yxd7hjymrw8crc9kin0dkm8d3wdu8jdhf3fkdpmgxfkbywbb9mdwkhkya4jtfn0d5h7s49bfyji1936w19tyf3906ypj09n64runqjrxwp6k2s3phxwm6wrb5c0b6c1n
16:39:56 <br-m> <spirobel:kernal.eu> @jeffro256: why are we fetching whole transactions for wallet refresh in any case? shouldnt outputs / key images itself be enough? 
16:42:22 <tevador> Wallets are fetching pruned transactions blobs so they can verify the txid.
16:44:10 <br-m> <spirobel:kernal.eu> tevador: they could do that after the fact when they found an output. That would be a privacy concern. But they could fetch a bundle of maybe 1000. 
16:44:15 <br-m> <spirobel:kernal.eu> And Or use different nodes 
16:44:22 <br-m> <jeffro256> They actually aren't verifying the TXIDs unfortunately, but yeah they should be.
16:45:16 <br-m> <jeffro256> tevador: I think that once you get past a certain point, no one's writing down these long Jamtis addresses lol. As long as they can be transcribed into a QR code, it should be fine 
16:46:29 <tevador> 346 chars still seems fairly copy-pastable and can fit into a reasonably sized QR code
16:46:54 <br-m> <jeffro256> @spirobel:kernal.eu: This is effectively what is contained in a "pruned" transaction: key images, ring member offsets, outputs, fee, and auxilliary info needed to scan outputs
16:46:54 <tevador> And can fit into an IRC message.
16:52:02 <tevador> FYI, it's a post-quantum forward secret address.
16:55:20 <br-m> <plowsof:matrix.org> https://mrelay.p2pool.observer/m/matrix.org/IKrbgJCzbLyaljDvIMPtNZUt.png (346-char-jamtis.png)
16:56:19 <br-m> <spirobel:kernal.eu> @jeffro256: true its probably close to optimal already. only thing annoying is the part where we cant easily request ranges. But I guess that is getting fixed now with the merging of the PR that allows for that 
16:57:41 <br-m> <spirobel:kernal.eu> (the getblocks.bin endpoint used in wallet2) 
17:05:24 <br-m> <kayabanerve:matrix.org> tevador: Then I'm explicitly interested 👀
17:10:11 <br-m> <syntheticbird> tevador: YES YES YES YES YES YES YES
17:10:46 <br-m> <jeffro256> Is the scan-time O(1) in the number of generated addresses?
17:17:44 <tevador> Yes, scanning speed is the same as Carrot. It's a compromise proposal. View tags are still ECDLP based.
17:21:06 <tevador> Btw, my proposal is meant to be on-chain compatible with Carrot without the need for a hard fork. And sends are indinstinguishable from sends to Carrot/legacy addresses.
17:21:52 <br-m> <jeffro256> Hell yeah, I'm interested 
17:59:01 <DataHoarder> 18:46:54 <tevador> And can fit into an IRC message.
17:59:06 <DataHoarder> Now this is the key feature!
17:59:59 <DataHoarder> Using base32 also allows the use of the more compact QR character set
18:01:31 <br-m> <rbrunner7> From 2 years ago: https://old.reddit.com/r/Monero/comments/zl4615/why_seraphis_jamtis_addresses_will_be_so_awfully/
18:02:05 <br-m> <rbrunner7> "awfully long" back then, for Seraphis, was around 200 characters :)