Jehan

So i guess the debate here is that @tac0turtle feels that extraneous information should not be kept in state if you can just look it up in events. That's definitely...

> The major concern with this approach is that the client to the consumer doesn't need to be updated on every block. Thus, some consumer headers will be skipped. The...

Something I'd like to see before we spend too much time working on the trustless downtime code is some analysis of how far just improving the throttling mechanism can get...

To expand on the downtime daemon idea- I think it is an optimal solution, except for the fact that each validator will need to run a separate daemon process, which...

So my overall opinion right now is that we should focus on throttle improvements and possibly look into a downtime daemon system when we have more than 20~ consumer chains.

I'm usually not that into garbage collecting state that people paid gas to add, but I wouldn't reject this. Certainly not a high priority IMO

Closing to reduce clutter. My rule of thumb is that if there is state that 1. a user has paid to add and 2. is not iterated on endblock We...

@mpoke this does make a possible catastrophic key rearrangement impossible. It doesn't solve the problem 100%, since there's still the potential for the numbers to become scrambled and have gaps...

Hey @albttx very interested in the potential this has to make things much simpler, but we'll probably table this for now and pick it back up after launch.

@mpoke All of your points sounds good on their own, but allow me to introduce some counterpoints- We cannot actually lock collateral for much longer than the provider chain's own...