This issue track will contain the process for adding the Timelock logic. Here are the steps that we need to take:
[x] Make a RSA safeprime modules which we know it's generator and other needed parameters (according to the write-up)
[x] Implement Timelock Public-Private key pair sampling, aggregation, and validation.
[ ] Implement Timelock verification algorithms. There are a few other pieces for validation and verification. Some TODOs in validation module.
[x] Add timelock object to beacon block
[x] Add timelock object to execution block
[x] Replace AttestationData's publicKey with a fresh randomly generated timelock.
[x] Replace the Attestation aggregation behavior.
[x] Replace timelock solving algorithm.
[x] Add Timelock solver engine to beacon-chain. We need to ensure that each Timelock would at most be solved half-way through the destination slot so that the block proposing won't delayed.
New theoretic problems:
BLS signature requires the AttestationData objects to share the exact same message; however, our TimelockPublickey piece is problematic for the signature aggregation. Currently, we exclude all the TimelockPublicKeys from for signature processes. Accordingly, the block producer can include whatever publicly that they want which is totally insecure (enough for MVP). The obvious idea is to add separate signatures for each publicKey share but it makes the system impractical for light clients.
Because of the nice property of our underlying messages (Timelock publicKeys should be multiplied together), there might be a way to extend BLS signature generation/verification to support our need. It needs further investigation though.
This issue track will contain the process for adding the Timelock logic. Here are the steps that we need to take:
New theoretic problems: BLS signature requires the AttestationData objects to share the exact same message; however, our TimelockPublickey piece is problematic for the signature aggregation. Currently, we exclude all the TimelockPublicKeys from for signature processes. Accordingly, the block producer can include whatever publicly that they want which is totally insecure (enough for MVP). The obvious idea is to add separate signatures for each publicKey share but it makes the system impractical for light clients. Because of the nice property of our underlying messages (Timelock publicKeys should be multiplied together), there might be a way to extend BLS signature generation/verification to support our need. It needs further investigation though.