xmrhaelan, u should not do this, but if u just add sci-hub.tw in front of that link, then u get the article, i.e., sci-hub.tw/https://www.nature.com/articles/s41893-018-0152-7

cool service thanks zkao[m]

good morning everyone, i'm getting offline for the day already

sorry to say hi and then goodbye but i'm out

If anyone is bored, feel free to run functional tests on this branch: github.com/SarangNoether/monero/tree/txproof

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

Transaction proof update is now a WIP PR; comments requested: monero-project/monero #6329

(note there are no specific functional tests for verifying old proofs, only crypto-based unit tests, since V1 generation functionality is no longer exposed)

UkoeHB_: on your idea 68, what public points is the verifer assumed to have access to?

in order to perform its verification of the signatures

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.

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

It's actually 8*r*Kv iirc

Should also know the one-time address output index

also needs to know k^s*K^s