Suneal

@d0cd The sum in the figure is not the final reward. `f(h)` is `anchor_block_reward_at_height`. We need to multiply `f(h)` with `combined_proof_target/coinbase_target` to get the `coinbase_reward` of block `h`. ``` let...

> The only way to differentiate "program address" from "real address" would be to track all program names and their addresses. I'm not sure that's what you meant here. >...

> Can you please put a link to the rendered version of this Arc in the PR description? Done.

I am the reporter of #2935. The root cause of the issue is that the validator didn't verify the certificate before entering recursion. I think we can resolve the issue...

> > I am the reporter of #2935. The root cause of the issue is that the validator didn't verify the certificate before entering recursion. I think we can resolve...

@howardwu I believe this issue still exists in `mainnet-staging`. Now the committee is fixed for every round. We can address this issue by: 1. Upon receiving a Certificate, immediately check...

I can reproduce it with a single malicious validator in 4 nodes. @niklaslong Make sure to start the malicious validator before round 5. Also, use the same snarkOS version.

I submitted some bug reports about the PoW part at HackerOnce several days ago. I think this is a bug of incorrect updating `coinbase_target`, (report 2315260).

@raychu86 The `coinbase_reward` and ’zero date‘ will fluctuate greatly due to the real block time. For example, if the real `block_time` doubles, the `coinbase_reward` will decrease to 0 in 20...

> For BLS12-377 we can perform this check using native arithmetic as we constrain s1, s2, λ to all be 127 bits and we never overflow the outer curve scalar...