Alex

yes Marco, having linear orders is even better. I was thinking about it from a perspective minimizing current changes to the protocol, but these linear orders are way cooler. Having...

Thanks for opening this issue. I agree that we need to find a solution for it! Before we decided on one option, I just wanna brainstorm about the solution space:...

> I wonder if for now as a workaround a withdrawal request in a pooling contract could be implemented as a future cancellation of orders (e.g. to the next full...

> Maybe we can do the computation inside submitSolution and thus keep the dependencies as is. Are we sure this is an important enough issue to redeploy the contracts? It...

>An alternative suggestion would be, that when balances are increased in the solver submission, that instead of manipulating balance directly the "deposit" function could be used that will only affect...

>The addition would simply be that one would need to run over all touched orders and if user==user and buyToken==withdrawl token then sum up a variable "pending_receive_amount". If we have...

My conclusion so far: **Keep the contract as it is** This would have three significant disadvantages: 1. The pooled bracket strategy will have a high likelihood of failing withdraws unless...

The conclusion from the meeting's discussion: There are essentially two paths: The first one would be to redeploy the contracts with a fix and require everyone to switch to new...

Validating the previous contributions is quite resource intensive on slower machines. I think it would nearly double the execution-time for each participant. I thought that the ceremony master would simply...

From this upper input, I think we should go with 2M download and each client only verifies that they downloaded the right data via a hash check of the 2M...