nic carter
@nic
@faust is there any on-chain element to the proofs?
2 replies
16 recasts
66 reactions
polymutex
@polymutex.eth
In the tweet below, @july said the camera will be local-first. Since connectivity would be required for provable timestamping, my guess is that this implies no onchain proof; at least not while it's in local-only mode. I'd be happy to be wrong! https://x.com/0xJuly/status/1869868117670932811
1 reply
0 recast
4 reactions
July
@july
You are correct that we are local first. We also will have connectivity and we will post proofs onchain https://warpcast.com/july/0x3f5cd3cb
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
Still curious about provable timestamping. Posting proofs onchain proves "photo taken ≤ timestamp(proof inclusion block)". In order to prove the other leg ("photo taken ≥ T"), it'd require baking the current block height and hash into the proof itself (hence requiring connectivity), correct?
2 replies
0 recast
3 reactions
July
@july
this is an interesting idea. timestamping is a critical component in creating trust. i've given some thought to provable timestamping. clocks are such an interesting idea, and at the end of the day it is about coordination. the way we've done it is to include timestamp of the clock that's onboard the embedded device. but if you're doing linux, you need to do RTC (real time clock) or NTP (network time protocol), and in order to have RTC you need a microcontroller with a clock and a calendar that can save the state in EEPROM or have internet connection to query NTP. it would get the timestamp, add it as metadata in the ZKP input, then generate the proof. we'd need tamper proof resistance in the RTC chip (in the long run too) then there are the questions of: - when did the button get pressed? - when did the photo get saved? - when did the photo get hashed? - when did the proof get generated? - when did the camera call the contract and submit the proof onchain? these are all different times
1 reply
0 recast
0 reaction
polymutex
@polymutex.eth
It's unfortunately fairly trivial to hijack NTP traffic and fake the time returned. There's no encryption/authentication in NTP at all; as a sidenote, that's actually one of the weaknesses of TLS since it relies on both client and servers having accurate clocks to ensure cert expiries are respected. And since devices typically get their NTP settings from DHCP, it's also easy to set up for devices on the local network without physically having to touch/tamper with the device. If connectivity is available, seems to me like the more trust-minimized way to encode an unforgeable "taken-after" timestamp is to source it from a blockchain, like OpenTimestamps.org
1 reply
0 recast
1 reaction
July
@july
Ntp being hack able makes sense Cool — will checkout opentimestamps
1 reply
0 recast
1 reaction
