16:37:46 <jeffro256[m]> <kayabanerve[m]> "You can hash the key images..." <- If you wanted to do this, then wouldn't you have to make sure you're talking about the same set of key images? Since you can't ever guaranteed what the state of the other
16:38:30 <jeffro256[m]> 's chain is, I'd imagine this would involve sending a block hash which is bigger than an IV
16:39:32 <jeffro256[m]> Also this wouldn't allow nodes who are not yet synced to communicate with the network b/c they don't know what the key image set is 
16:40:52 <jeffro256[m]> Also I'd imagine some grossness if the nodes' chaintips differ 
16:44:21 <jeffro256[m]> Oh makes sense ;)
16:46:22 <jeffro256[m]> Using key image set as IV is clever though. Do you know if the Seraphis impl does anything like that or does it just XOR w/ shared secret like cryptonote 
16:49:46 <jeffro256[m]> However, using key images as IV could have problems if you reconstruct and rebroadcast tx (accidental double spend) since that could leak secrets. You would need a RingDB-like persistent data structure to protect against that 
16:52:39 <jeffro256[m]> You could have the IV also depends on a hash of the transaction public key (or other ephemeral random data) so one you are 1) guaranteed to not reuse IVs across txs thanks to key image uniqueness and 2) you are less likely to reuse IV reconstructing the same tx b/c of random data 
16:54:00 <jeffro256[m]> True, assuming H(ecdh) changes then yeah you're okay 
17:01:10 <UkoeHB> in seraphis the shared secret is a function of input context, which is a hash of key images
17:05:13 <jeffro256[m]> The IV or the shared secret?
17:15:05 <UkoeHB> IV of what? I'm talking about the sender-receiver shared secret used to build enotes.
17:17:16 <jeffro256[m]> Is the shared secret solely a function of public input context then? 
17:28:37 <UkoeHB> jeffro256[m]: section 8.2.3 https://raw.githubusercontent.com/UkoeHB/Seraphis/master/implementing_seraphis/Impl-Seraphis-0-0-2.pdf
18:17:58 <jeffro256[m]> Thanks I'll take a look