No, the implementation you link to uses parallel-serial hash chains. Using that implementation, the person creating the file has to do as much work as the person reading the file, it's just that the creation can be parallelized. Use the linked to code, if you'd need to dedicate 1.5 months on a 16-core machine to generate a file that takes 2 years to read.
I'm suggesting something based on quadratic residues moduo a Blum integer instead of repeated hashing. This allows a shortcut if you know how to factor the Blum integer. It takes a few minutes on a single core to create a file that would take 2 years to read. Most of the file creation time is spent checking large random numbers for primality.
There are tradeoffs between the two different ways of creating timelock puzzles, but for the time being, I'm willing to assume anyone who can factor an 8192-bit number in under 2 years has better things to do with their cracker than decrypt my 0-day.
I suppose it would be nice to have a hybrid system where you could have stronger guarantees that someone capable of factoring 8102-bit integers would still need (for instance) at least 6 months of computing hash chains after they finished solving the quadratic residue portion of the problem, and someone who couldn't factor 8192-bit integers would spend (for instance) 18 months computing quadratic residues, followed by those 6 months of hash chaining. This would need 11.25 days of compute time on a 16-core machine to set up the hash chains, but at least it's not months of setup time.
I should point out that I would suggest using the solution to the quadratic residue problem as a key for a Blum Blum Shub stream cipher to encrypt the hash chains and the message, so that portion of the system only relies on square roots and quadratic residues modulo a Blum integer. (Using the quadratic residue solution as a key for AES-GCM or ChaCha20-Poly1035 would open you up to weaknesses in those ciphers, and in this case the slowness of Blum Blum Shub isn't a problem.)
Then, for the inner puzzle, I would use hash chains using a hash in the Blake family to generate a ChaCha20-Poly1305 key to encrypt the plaintext. Since Blake's round function is based on ChaCha20, this also reduces the number of different primitives you're relying on.
In the end, the cipher text would be doubly encrypted with Blum Blum Shub and ChaCha20-Poly1305, with keys being the solutions to repeated quadratic residue modulo a Blum integer and repeated hash chains using a hash from the Blake family. This minimizes the number of possible points of failure.
I'm suggesting something based on quadratic residues moduo a Blum integer instead of repeated hashing. This allows a shortcut if you know how to factor the Blum integer. It takes a few minutes on a single core to create a file that would take 2 years to read. Most of the file creation time is spent checking large random numbers for primality.
There are tradeoffs between the two different ways of creating timelock puzzles, but for the time being, I'm willing to assume anyone who can factor an 8192-bit number in under 2 years has better things to do with their cracker than decrypt my 0-day.
I suppose it would be nice to have a hybrid system where you could have stronger guarantees that someone capable of factoring 8102-bit integers would still need (for instance) at least 6 months of computing hash chains after they finished solving the quadratic residue portion of the problem, and someone who couldn't factor 8192-bit integers would spend (for instance) 18 months computing quadratic residues, followed by those 6 months of hash chaining. This would need 11.25 days of compute time on a 16-core machine to set up the hash chains, but at least it's not months of setup time.