16:45:50
jeffro256: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
16:46:32
jeffro256:monero.social:
This is currently how payment IDs are implemented
16:46:53
jeffro256:monero.social:
It used to be that payment IDs were 32 bytes and unencrypted, but that was a privacy risk
16:50:33
spirobel: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
16:51:59
jeffro256:monero.social:
No, the risk that was every owner of a copy of the Monero blockchain could see anyone's payment IDs
16:52:33
jeffro256:monero.social:
Not just the sender
16:54:31
jeffro256: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
16:55:39
jeffro256: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
17:03:38
spirobel: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.
17:04:29
spirobel:kernal.eu:
after the first one it is trivial. made me think of hedy lamarrs frequency hopping technique
17:04:32
jeffro256:monero.social:
The receiver also knows the secret. They must know it, otherwise they wouldn't be able to scan
17:04:46
spirobel:kernal.eu:
yes but they dont know it in advance
17:05:16
spirobel:kernal.eu:
what i want is more like determining a unique key for the transactions you will receive from your seedphrase
17:05:48
spirobel:kernal.eu:
which means you can just find the outputs you own without having to scan every output
17:06:18
spirobel:kernal.eu:
(key in the sense of key value store)
17:07:49
DataHoarder:
how would that index be maintained if the key is random?
17:09:19
spirobel:kernal.eu:
like frequency hopping the sender would increment it after you found the first one "opening the channel" you will find all others