Chance

I discovered an interested problem with `commitMassDeposit` using the `maxGasUsed` value here. Using a gas limit of 41,000 will fail (in some cases) for the `commitMassDeposit` function because more than...

> @JChanceHud Is this enough for fix it now? Yes, doing a comparison to `'0'` should be fine for now. > the withdrawal tx's outflow utxo hash is included for...

So there's a race condition between the mass deposit commit worker and the proposal worker? Seems like we should refactor these to operate one after the other. Good catch, this...

I think we're already guarded against this. In [`propose()`](https://github.com/zkopru-network/zkopru/blob/develop/packages/contracts/contracts/zkopru/controllers/Coordinatable.sol#L86) there is the line: ``` require( _block.header.proposer == msg.sender, "Coordinator account is different with the message sender" ); ``` Any call...

@wanseob Why do we allow this condition? https://github.com/zkopru-network/zkopru/blob/main/packages/contracts/contracts/zkopru/controllers/validators/TxValidator.sol#L65

But the depth couldn't be more than 128 right (or whatever we set the ref depth to)? If we set a sensible limit could we avoid this condition? It causes...

Hm, it might be good to force a user to fully synchronize before making a deposit. Otherwise they can deposit, then have to synchronize to do a transfer or withdrawal....

This is a good find. We should have the http requests be processed in a separate thread. Right now the `/tx` endpoint verifies the transaction immediately which makes it easy...

I think it's worth a try. `@ethereumjs/tx` is a major version ahead of `ethereumjs-tx`, it might have fixed transaction gas estimation. In the meantime I did this to allow the...

@wanseob Should this be a http/ws interface for accessing these functions? It would be nice to expose the client package as a wrapper for connecting to this for things like...