opentimestamps-server

hat HMAC gets timestamped securely with Bitcoin. But since OTS servers are not supposed to be trusted, that HMAC digest is deliberately truncated to 64 bits to make it feasible to brute force with significant effort, thus making them not useful as an actual timestamp: https://github.com/opentimestamps/opentimestamps-server/blob... This is ok for their intended purpose, because if you're willing to brute force 64-bits, I'm ok letting you add some junk to the OTS calendars in the event of a disaster. I'm actually considering using that scheme as a trusted timestamping mechanism for OTS, by simply revealing the HMAC keys after they've been timestamped by Bitcoin. They're already derived with a merkle tree from a single seed - each second gets a different HMAC key. To turn that into a verifiable signature you just need to derive all the keys in advance, construct a tweaked version of that merkle tree, and then publish the root. A full signature is then the HMAC output, and a path up the tree to the public root. The advantage for OTS is the amortized size of the signatures would be smaller than a ECC signature, plus being hash based it's a quantum resistant scheme.