Encrypting something that cannot be decrypted until a given future date is now possible :D
This was presented on Friday at DEF CON, and there's also a web demo to try it out using the second compatible TS library: https://timevault.drand.love/
How does this work really? Is this basically just putting someone on chain, presuming that there wont be a 51% attack, and relying on the chains normal block creation schedule? I presume this timelock can be cracked early if I spend enough compute resources on it.
Also I presume it doesn't work well for small time intervals (less than or equal to drand's block creation times)?
I have a healthy amount of skepticism of this approach.
>Is this basically just putting someone on chain, presuming that there wont be a 51% attack
There is no chain or block creation. Also it's not a public permissionless network, so outside actors can't join for a sybil attack.
>I presume this timelock can be cracked early if I spend enough compute resources on it.
Sure like any cryptography, if you have more computing power than exists in the world
>Also I presume it doesn't work well for small time intervals (less than or equal to drand's block creation times)?
There is a dependence on transmitting shares between nodes in the network to gain a threshold number of share - right now each epoch is 30 seconds, but new networks could be created with down to ~1 second epochs
It works by relying on identity-based encryption to encrypt plaintext that cannot be decrypted until the signature of a specific message is revealed. The League of Entropy is signing its beacons every 30 seconds and so acts as a reference clock to provide the signatures on time.
Onboarding new members on a drand network is fairly easy: there only needs to be a threshold of nodes doing a resharing ceremony and all nodes get new shares and new nodes can be onboarded like that. It's not handled by tlock or timevault, it's on the League of Entropy side and is how drand works. More details are in https://drand.love/docs/cryptography/
I used the term blockchain with liberty, it is based on a consensus mechanism so you need to assume the consensus is right which is different of timelock encryption usage in classic ways. The README was edited after the HN posts.
It's not really a consensus mechanism either really - the randomness in some sense is deterministic, it just requires participation. I'm unsure which 'classic ways' you're referring to - in principle it's not that different to having a notary, except the notary is a distributed network rather than a single entity.
> The README was edited after the HN posts.
You can see from that the tlock git history the README.md hasn't been updated in 13 days and the tlock-js one hasn't been updated in 4 days - both before the HN post. Are you talking about another README?
Ahahah, definitively. Where's the challenge otherwise? The PoC was ready since almost 8 months sitting in a branch of drand/kyber, and the Go tlock library since a month or so and it would have been enough if it weren't for the DEF CON presentation that made a web-demo more appealing for people to try it out :P
