Lin Oshitani

> any updates regarding this for the current solution heading to mainnet soon? [@dantaik](https://github.com/dantaik) [@linoscope](https://github.com/linoscope) As discussed in Slack, mitigating prover-killer blocks won't be a requirement for whitelist launch as...

> The current Raid design seems to assume there’s only one unsafeHead at any time. If Alice, who is not the permitted proposer, submits an unsafeHead, then Bob - the...

> Seems the [optimistic approach](https://github.com/NethermindEth/Taiko-Preconf-AVS/tree/master/SmartContracts/src/avs) from Nethermind is still the way to go. I am also leaning towards this too unless the early inclusion can be enabled in RAID. But...

> This naturally leads to the idea that multiple parties, including Bob, should be allowed to propose in the same block N+5. Then in slot N+6, only one (or none)...

> we’d need to search through N+3, N+4, etc., to find the next preconfer. Also note that, if `N+5` is the next preconfer, then we need to prove that `N+3`...

> Is the assumption that the GTM preconf protocols support L2 execution preconfs? Yes, we are going for execution preconfs. > If not, can't non-contentious transactions be preconfed by the...

> Supporting only one unsafe head may work if the invalid proposer will be heavily slashed. Also note that, until EIP-7917, we risk slashing a honest submitter if the next...

Had same issue, as @fgimenez mentions `docker container rm kurtosis-logs-aggregator` fixed it.