<j​effro256:monero.social> spirobel: If you send to the same payment ID twice, the receiver decrypts the payment ID as the same payment ID, but because of the encryption, it shows up different on the chain to external observers. Just like how sending to the same Monero address makes a unique onetime address on the chain, but the receiver can decrypt it as going to the same address each time

<j​effro256:monero.social> This is currently how payment IDs are implemented

<j​effro256:monero.social> It used to be that payment IDs were 32 bytes and unencrypted, but that was a privacy risk

<s​pirobel:kernal.eu> to be specific: the risk was that practically it would be known to the sender ( anyone who knows the address) how often funds were sent to this address

<j​effro256:monero.social> No, the risk that was every owner of a copy of the Monero blockchain could see anyone's payment IDs

<j​effro256:monero.social> Not just the sender

<j​effro256:monero.social> But yes, if someone sent XMR to the same main address twice with the same payment ID, external observers could tie them together with high probability, especially with the smaller ring signatures at the time

<j​effro256:monero.social> B/c payment IDs predate integrated addresses. You used to just type in whatever payment ID you wanted, or what the receiver told you to send

<s​pirobel:kernal.eu> i was thinking about ways we can avoid having external observers being able to tie them together without having the encrypted payment id rely on a sender known secret only.

<s​pirobel:kernal.eu> after the first one it is trivial. made me think of hedy lamarrs frequency hopping technique

<j​effro256:monero.social> The receiver also knows the secret. They must know it, otherwise they wouldn't be able to scan

<s​pirobel:kernal.eu> yes but they dont know it in advance

<s​pirobel:kernal.eu> what i want is more like determining a unique key for the transactions you will receive from your seedphrase

<s​pirobel:kernal.eu> which means you can just find the outputs you own without having to scan every output

<s​pirobel:kernal.eu> (key in the sense of key value store)

how would that index be maintained if the key is random?

<s​pirobel:kernal.eu> like frequency hopping the sender would increment it after you found the first one "opening the channel" you will find all others