04:04:27 <br-m> <spirobel:kernal.eu> > <@gingeropolous> so according to that table we get "might have received an enote in block x" for either 5x or 18x the scan time. This 5x or 18x... is this another thing we can optimize, or hold another competition to optimize? where's the dude that did the divisors crazy speedup....
04:04:27 <br-m> <spirobel:kernal.eu> the "might have received an enote in block x" is an ergonomics problem not a cryptography or code optimization problem. because this information is known to the sender. it is a matter of sharing this information with the receiver of the transaction. aside from this: https://xcancel.com/spirobel/status/2020397980818264502 and t [... too long, see https://mrelay.p2pool.observer/e/8IK0zIELMi1kV3U3 ]
10:31:43 <tevador> spirobel: 1. "Might have received an enote" is from the attacker's perspective, so it's a desirable property. 2. We want to keep the functionality of static donation addresses, which your proposal doesn't support (without leakage). 3. Jamtis will specify an interactive protocol in which the receiver learns one of the key images in advance, so the payment can also be found without scanning.