02:53:20 <zkao[m]> xmrhaelan, u should not do this, but if u just add https://sci-hub.tw/ in front of that link, then u get the article, i.e., https://sci-hub.tw/https://www.nature.com/articles/s41893-018-0152-7
03:02:53 <UkoeHB_> cool service thanks zkao[m]
15:54:54 <suraeNoether> good morning everyone, i'm getting offline for the day already
15:55:04 <suraeNoether> sorry to say hi and then goodbye but i'm out
15:55:29 * moneromooo waves
16:26:18 <sarang> If anyone is bored, feel free to run functional tests on this branch: https://github.com/SarangNoether/monero/tree/txproof
16:26:57 <sarang> It failed the GitHub commit-hook tests, but without good log data; and I'm having trouble getting them to run locally on my build
20:12:52 <sarang> Transaction proof update is now a WIP PR; comments requested: https://github.com/monero-project/monero/pull/6329
20:20:48 <sarang> (note there are no specific functional tests for verifying old proofs, only crypto-based unit tests, since V1 generation functionality is no longer exposed)
21:06:06 <sarang> UkoeHB_: on your idea 68, what public points is the verifer assumed to have access to?
21:06:20 <sarang> in order to perform its verification of the signatures
21:24:46 <UkoeHB_> Looks like at minimum: prover public spend key, one-time address being proven unspent, sender-receiver shared secret r*Kv based on the transaction public key from that one-time address tx, and a key image to prove doesn't correspond with the one-time address. The proof should start off by checking that the one time address corresponds with the spend key.
21:26:29 <UkoeHB_> In a broader audit context the verifier will already know the one-time address corresponds, since he will probably know the view key. Modularity dictates the proof itself check as well
21:28:25 <UkoeHB_> It's actually 8*r*Kv iirc
21:28:56 <UkoeHB_> Should also know the one-time address output index
22:12:06 <UkoeHB_> also needs to know k^s*K^s