From 91b5c3f9cf245b453feb1b55afed3b13a0167ca4 Mon Sep 17 00:00:00 2001 From: nkohen Date: Thu, 4 Mar 2021 02:41:18 -0600 Subject: [PATCH] Responded to Tibo's review --- FraudProofs.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/FraudProofs.md b/FraudProofs.md index 5e31f4a..6293d1a 100644 --- a/FraudProofs.md +++ b/FraudProofs.md @@ -57,7 +57,8 @@ always generate proofs which show that a fraudulent oracle attestation must exis The most important piece of this proof is the `aggregate_oracle_attestation` which is recoverable from on-chain information as the difference between the broadcast CET's signature and its corresponding adaptor signature. -In the case that one has access directly to an oracle's attestation, then this can be used as the aggregate. +If `num_oracles = 1`, then the `aggregate_oracle_attestation` is directly equal to the attestation released by the one oracle. +As such, if one has access directly to an oracle's attestation, then this proof should use `num_oracles = 1`. The `oracle_announcements` and `oracle_outcomes` are used to compute a signature point `S` corresponding to an anticipation of these oracles attesting to these outcomes. @@ -141,14 +142,10 @@ for the same `oracle_announcement` but for different `oracle_outcome`s. * [`32*bytes`:`oracle_attestation_1`] * [`nb_signatures*string`:`outcomes_2`] * [`32*bytes`:`oracle_attestation_2`] - * [`32*bytes`:`oracle_private_key`] This second kind of oracle equivocation proof is specialized and compressed (when compared to the other version) to be optimized for equivocation proofs where the prover has direct access to non-aggregate `oracle_attestation`s. -This proof has the added feature of containing the `oracle_private_key` (which is computed from the announcement -and the two attestations). - ## Authors Nadav Kohen