Eugene Kabanov

I could also confirm that this (asyncdispatch version) ```nim import asyncdispatch proc t(): Future[int] = var retFuture = newFuture[int]("") retFuture.fail(newException(ValueError, "")) return retFuture proc m(transp: int): Future[void] = var retFuture...

`Connection` object is **NOT** easily accessible and needs to be accounted in `nimbus-eth2` to properly access this value, its an overhead for application, imho. This functionality should be accessible via...

What OS is being used? I suppose it is Linux, if so this is `ECONNABORTED` error which is handled in `accept()` call, but it impossible to handle it in `acceptLoop()`....

Feel free to open this issue again if my answer is not enough.

Fixed in https://github.com/status-im/nim-chronos/pull/563

> What's the rationale? Is there a discussion somewhere that you can point me to? One of the reasons why we are not revealing client version is: https://www.inmotionhosting.com/support/server/nginx/hide-nginx-server-version/

HTTP client do not need certificate either custom or not, it could just ignore any errors happen when certificate validation fails.

If you going to refactor configs it would be nice if you split all the configs between parts, because when VC builds it imports whole BN codebase just because of...

It would be nice to have, because we already have some time ago, and its why most of the low level primitives are actually accepts pointer/size pair instead of `seq[byte]`.

I have tried to fix it in https://github.com/status-im/nimbus-eth2/pull/6595 , but core of the problem is in `nim-libp2p` implementation https://github.com/vacp2p/nim-libp2p/issues/1210