Karl Bartel

The blocking issue is done. How would we set the new fee components? Can we do that reasonably without some kind of [fee oracle](https://github.com/ethereum/web3.py/issues/2054)?

We should remove the `gas_price_strategy`, since the web3py docs say > Gas price strategy is only supported for legacy transactions. The London fork introduced `maxFeePerGas` and `maxPriorityFeePerGas` transaction parameters which...

We check that the eth client is up to date when starting the Raiden node. Checks at run time are not implemented yet, but there is nothing specific blocking us...

We are strictly following the route returned by the PFS, which does know about the reveal_timeouts. So the problem case should never occur when using a PFS. The only problem...

Is the described case actually problematic, or is it just the check that is overly strict? Maybe we should just check that `lock_timeout > REVEAL_TIMEOUT_MIN` to discard obviously failing payments?...

> I think this would be equivalent to making the reveal_timeout a chain-dependent constant as determined by the node implementation, since the user defined `reveal_timeout` is not used anywhere else?...

Since we are asking the target anyway, couldn't we block on that request until the payment succeeds? Something like `GET /api/(version)/payments/(token_address)/(partner_address)/(payment_id)?wait_for_success=5`

We could change the request to `GET api/v1/notifications?since=NOTIFICATION_ID` (and limit maximum amount of returned messages).

We could also return 404 *and* an empty list at the same time.

I'm afraid this could introduce more confusion than it solves. Is there a different way to avoid this problem?