Note that the The received difficulty doesn't match the claimed one! issue also happens when applying the following to commit 4b82fdc2f879f4661093ab208984a2a020a53b79 :
diff --git a/prover.py b/prover.py
index 6247131..0ef4b43 100755
--- a/prover.py
+++ b/prover.py
@@ -62,7 +62,8 @@ print(f'{merkleTreeRoot=}')
## Execution phase: 3. Receive a random set of indexes from the verifier.
-indexesRequest = ast.literal_eval(input('indexesRequest: '))
+with open(input('indexesRequest: ')) as f:
+ indexesRequest = ast.literal_eval(f.read())
## Execution phase: 4. Respond with the corresponding table entries and commitment openings.
@@ -103,5 +104,10 @@ for verificationMerkleTreeLevelsIndex, verificationMerkleTreeLevel in enumerate(
else:
entries += [otherHash]
-print(f'{entries=}')
+entriesFilePath = 'entries.txt'
+
+with open(entriesFilePath, 'w') as f:
+ f.write(str(entries))
+
+print(f'entries: {entriesFilePath}')
diff --git a/verifier.py b/verifier.py
index 078931d..c968f48 100755
--- a/verifier.py
+++ b/verifier.py
@@ -39,7 +39,12 @@ while len(indexesRequest) < common.ENTRIES_NUMBER * FRACTION_OF_SPACE_TO_VERIFY:
index = secrets.randbelow(common.ENTRIES_NUMBER)
indexesRequest.add(index)
-print(f'{indexesRequest=}')
+indexesRequestFilePath = 'indexesRequest.txt'
+
+with open(indexesRequestFilePath, 'w') as f:
+ f.write(str(indexesRequest))
+
+print(f'indexesRequest: {indexesRequestFilePath}')
## Execution phase: 4. Receive and verify corresponding table entries and commitment openings.
@@ -48,7 +53,8 @@ print(f'{indexesRequest=}')
# Proceeding in a minimum number of passes could be interesting but this can be left for future work.
-entries = ast.literal_eval(input('entries: '))
+with open(input('entries: ')) as f:
+ entries = ast.literal_eval(f.read())
merkleTreeLevels = [{} for _ in range(common.LEVELS)]
It seems that the more the SPACE_TO_PROVE_IN_BITS is low, the more often the verification passes.
Maybe this issue occurs the more verifications are done.
With latest commit starts to have issues with PROBABILITY_TO_CATCH_MALICIOUS = 1 - 2 ** -3 as far as I tested.
Note that the `The received difficulty doesn't match the claimed one!` issue also happens when applying the following to commit 4b82fdc2f879f4661093ab208984a2a020a53b79 :
```diff
diff --git a/prover.py b/prover.py
index 6247131..0ef4b43 100755
--- a/prover.py
+++ b/prover.py
@@ -62,7 +62,8 @@ print(f'{merkleTreeRoot=}')
## Execution phase: 3. Receive a random set of indexes from the verifier.
-indexesRequest = ast.literal_eval(input('indexesRequest: '))
+with open(input('indexesRequest: ')) as f:
+ indexesRequest = ast.literal_eval(f.read())
## Execution phase: 4. Respond with the corresponding table entries and commitment openings.
@@ -103,5 +104,10 @@ for verificationMerkleTreeLevelsIndex, verificationMerkleTreeLevel in enumerate(
else:
entries += [otherHash]
-print(f'{entries=}')
+entriesFilePath = 'entries.txt'
+
+with open(entriesFilePath, 'w') as f:
+ f.write(str(entries))
+
+print(f'entries: {entriesFilePath}')
diff --git a/verifier.py b/verifier.py
index 078931d..c968f48 100755
--- a/verifier.py
+++ b/verifier.py
@@ -39,7 +39,12 @@ while len(indexesRequest) < common.ENTRIES_NUMBER * FRACTION_OF_SPACE_TO_VERIFY:
index = secrets.randbelow(common.ENTRIES_NUMBER)
indexesRequest.add(index)
-print(f'{indexesRequest=}')
+indexesRequestFilePath = 'indexesRequest.txt'
+
+with open(indexesRequestFilePath, 'w') as f:
+ f.write(str(indexesRequest))
+
+print(f'indexesRequest: {indexesRequestFilePath}')
## Execution phase: 4. Receive and verify corresponding table entries and commitment openings.
@@ -48,7 +53,8 @@ print(f'{indexesRequest=}')
# Proceeding in a minimum number of passes could be interesting but this can be left for future work.
-entries = ast.literal_eval(input('entries: '))
+with open(input('entries: ')) as f:
+ entries = ast.literal_eval(f.read())
merkleTreeLevels = [{} for _ in range(common.LEVELS)]
```
It seems that the more the `SPACE_TO_PROVE_IN_BITS` is low, the more often the verification passes.
Maybe this issue occurs the more verifications are done.
With latest commit starts to have issues with `PROBABILITY_TO_CATCH_MALICIOUS = 1 - 2 ** -3` as far as I tested.
Related to #2.
It seems that the problem is that the prover doesn't send all expected nonces.
More precisely it seems that the problem is happening when the verifier requests multiple times the same pair, so because the prover uses a dict, it doesn't send the repeated nonces.
To solve this issue, let's pick different indices couple as the theory requires. Does it actually require that?
More precisely the theory would go for sending neighbor hashes but we send nonces as it doesn't cost much on the first level.
It seems that the problem is that the prover doesn't send all expected nonces.
More precisely it seems that the problem is happening when the verifier requests multiple times the same pair, so because the prover uses a `dict`, it doesn't send the repeated nonces.
To solve this issue, let's pick different indices couple as the theory requires. Does it actually require that?
More precisely the theory would go for sending neighbor hashes but we send nonces as it doesn't cost much on the first level.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Note that the
The received difficulty doesn't match the claimed one!issue also happens when applying the following to commit 4b82fdc2f879f4661093ab208984a2a020a53b79 :It seems that the more the
SPACE_TO_PROVE_IN_BITSis low, the more often the verification passes.Maybe this issue occurs the more verifications are done.
With latest commit starts to have issues with
PROBABILITY_TO_CATCH_MALICIOUS = 1 - 2 ** -3as far as I tested.Related to #2.
It seems that the problem is that the prover doesn't send all expected nonces.
More precisely it seems that the problem is happening when the verifier requests multiple times the same pair, so because the prover uses a
dict, it doesn't send the repeated nonces.To solve this issue, let's pick different indices couple as the theory requires. Does it actually require that?
More precisely the theory would go for sending neighbor hashes but we send nonces as it doesn't cost much on the first level.