Handle PoET errors in ATX builder

[noamnelke]

In the ATX builder PoET errors require special handling. There are three possible PoET errors:

1. No response to registration requests - if the node is aware of another PoET (no implemented) it should try another one.
2. PoET membership proof doesn't include our registration and we have a signed receipt (not implemented) - blacklist PoET (not implemented) and publish fraud proof (not implemented).
3. Waiting for PoET proof timed out - blacklist PoET (not implemented). Proving this happened is non-trivial, perhaps we can piggyback the hare, but not sure it's worth it.

[dshulyak]

PoET membership proof doesn't include our registration and we have a signed receipt (not implemented) - blacklist PoET (not implemented) and publish fraud proof (not implemented).

i wanted to clarify what is the fraud proof and interaction with the signed receipt, let me know how accurate this is:

1. prover commits that challenge is accepted in RoundID with Signature

   type SubmitResponse struct {
   RoundID string
   SigChallenge     []byte // signature over hash(roundID || challenge)
   }

2. prove that at RoundID prover didn't include accepted challenge. i can do that if receive a poet proof message

type PoetProofMessage struct {
    Members [][]byte // all challenges?
    SigRoot []byte // signature over hash(roundID || root(members))
}

3. for someone else to verify that challenge was accepted and message in RoundID doesn't include it they need to be able to verify these two signatures

   type FraudProof struct {
   Challenge []byte
   RoundID   []byte
   SigChallenge []byte
   
   Root []byte
   NonMembership struct {
       Proof [][]byte
       Member []byte
   }
   SigRoot []byte
   }

SigChallenge is simple. For SigRoot we need to prove that either:

• no member was inserted where Challenge is supposed to be inserted in the tree
• another member is inserted in the tree instead of our Challenge

cc @noamnelke @antonlerner

[dshulyak]

or the fraudProof would be simply a SubmitResponse? and everyone who wants to verify it is assumed to have members list from broadcasted PoetProof

[antonlerner]

everybody should have the members list from broadcast so I think simply publishing a signed challenge was received by poet is enough as fraud, since all miners need to have the members list who enrolled to poet.

[noamnelke]

To add to what @antonlerner said, we also don't need a signature of the membership tree root, since that root is the input to the poet proof itself and is non-malleable. Trying to tweak the member list would invalidate the proof built on top.

It's important to note that all of this is only relevant assuming we have competing PoET services and the node automatically chooses which one to use.

[dshulyak]

@noamnelke So, i am allowing to register multiple poet servers using the command line. In case of misbehaviors (that you described) i will select another poet server (blacklist if required). But if there is only one server - misbehavior will not affect the algorithm, but only print error to logs.

And just to reiterate on the fraud proof, I will broadcast this object:

type FraudProof struct {
    RoundID      string
    ServerEntity []byte
    Challenge    []byte
    Signature     []byte // signature over hash(roundID || challenge)
}

In order to verify it, any other party will need a list of members that are received from another broadcast. It then checks that the signature belongs to the ServerEntity and Challenge is not included in the members list. Does it sound accurate?

[noamnelke]

imo, the proof should include the id of the poet proof so it's clear which object is referenced. This also encapsulates the round id and server id.

Are you working on this right now? Have we defined how this should work? Is there a SMIP or some other doc I can review before it's too late?

[dshulyak]

As discussed with @noamnelke and @antonlerner we are not going to support multiple PoET now. Must be re-assigned when we will consider to add such support.

[moshababo]

@noamnelke is any of it still relevant?

[fasmat]

@poszu @noamnelke Has this been addressed with the PoET changes in the last months?

[poszu]

@fasmat, 1. is implemented (support for multiple poets), 2. and 3. - not.