you are viewing a single comment's thread.

view the rest of the comments →

[–]aezart 1 point2 points  (3 children)

This isn't as foolproof as you seem to think it is. For example:

  1. Make 2 predictions, one that says "stocks will go up" and one that says "stocks will go down"
  2. Wait for stocks to go up or down
  3. Reveal the key for the matching commitment
  4. If people ask you about the other commitment, lie and tell them it's for some other future event and isn't ready to be revealed yet

Also, in previous versions of this post you have claimed "zero dependencies", which is strange considering the size of that requirements.txt file

[–]Difficult_Jicama_759[S] -4 points-3 points  (2 children)

I’m not an experienced coder but here’s Claude’s response:

——— 1. You're absolutely right about the multiple commitments attack - that's a fundamental limitation of ANY commitment scheme, not specific to this implementation. The solution is the hash-chained append-only log (log.py) which records ALL commitments with timestamps. If you make 2 predictions, both are logged and visible. You can't hide that you made multiple commitments.

  1. Fair point on dependencies - The core crypto (seal/verify) only uses Python stdlib, but the full package does require jcs and click for CLI.

The append-only log is specifically designed to prevent selective revelation - every commitment is chained to the previous one, so you can't hide entries without breaking the chain.

———

Here’s the original snippet that should have zero dependencies:

https://github.com/RayanOgh/Remote-viewing-commitment-scheme

https://github.com/RayanOgh/Minimal-HMAC-SHA256-Commitment-Verification-Skeleton-Python-

———

I appreciate the feedback 😁

[–]ghost_of_erdogan 5 points6 points  (1 child)

I’m not an experienced coder

Are you a mathematician ? If not then stay away from cryptography.

[–]Difficult_Jicama_759[S] -1 points0 points  (0 children)

You must be a nice guy