jeffro256: Carrot specs section 7.1.1 should explicitly say that the encrypted PID is only included in 2-output transactions. github.com/jeffro256/carrot/blob/master/carrot.md#711-payment-id

<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 mrelay.p2pool.observer/e/r_yvr8EKdUtBc2ZL ]

<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.

<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

jeffro256: I missed the PID confirmation part in the specs. Makes sense now, but I think it's a very niche use case.

<jeffro256> That's fair. I would imagine the main use case is to makes batch payouts easier for large players

The blockchain cost is nonzero, though.

<kayabanerve:matrix.org> ... oh, right, sorry, CARROT still generates a y term even for legacy addresses, doy

<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.

<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

<jeffro256> Or we could always include a dummy and not leak that information.

Interesting read about lack of validating points in FourQ botanica.software/blog/cryptographi…udflares-circl-fourq-implementation

<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

<jeffro256> A 1-in/3-out FCMP++/Carrot tx is ~6500 bytes, so removing its dummy ecncrypted PID would save 0.12% storage

<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

Would a 346-character Jamtis address be acceptable?

Example: xmra1mj0b1977bw3ympyh2yxd7hjymrw8crc9kin0dkm8d3wdu8jdhf3fkdpmgxfkbywbb9mdwkhkya4jtfn0d5h7s49bfyji1936w19tyf3906ypj09n64runqjrxwp6k2s3phxwm6wrb5c0b6c1ntrg2muge0cwdgnnr7u7bgknya9arksrj0re7whkckh51ikxmra1mj0b1977bw3ympyh2yxd7hjymrw8crc9kin0dkm8d3wdu8jdhf3fkdpmgxfkbywbb9mdwkhkya4jtfn0d5h7s49bfyji1936w19tyf3906ypj09n64runqjrxwp6k2s3phxwm6wrb5c0b6c1n

<spirobel:kernal.eu> @jeffro256: why are we fetching whole transactions for wallet refresh in any case? shouldnt outputs / key images itself be enough?

Wallets are fetching pruned transactions blobs so they can verify the txid.

<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.

<spirobel:kernal.eu> And Or use different nodes

<jeffro256> They actually aren't verifying the TXIDs unfortunately, but yeah they should be.

<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

346 chars still seems fairly copy-pastable and can fit into a reasonably sized QR code

<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

And can fit into an IRC message.

FYI, it's a post-quantum forward secret address.

<plowsof:matrix.org> mrelay.p2pool.observer/m/matrix.org/IKrbgJCzbLyaljDvIMPtNZUt.png (346-char-jamtis.png)

<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

<spirobel:kernal.eu> (the getblocks.bin endpoint used in wallet2)

<kayabanerve:matrix.org> tevador: Then I'm explicitly interested 👀

<syntheticbird> tevador: YES YES YES YES YES YES YES

<jeffro256> Is the scan-time O(1) in the number of generated addresses?

Yes, scanning speed is the same as Carrot. It's a compromise proposal. View tags are still ECDLP based.

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.

<jeffro256> Hell yeah, I'm interested

18:46:54 <tevador> And can fit into an IRC message.

Now this is the key feature!

Using base32 also allows the use of the more compact QR character set

<rbrunner7> From 2 years ago: old.reddit.com/r/Monero/comments/zl…jamtis_addresses_will_be_so_awfully

<rbrunner7> "awfully long" back then, for Seraphis, was around 200 characters :)