Unconfirmed blocks #502
Unconfirmed blocks #502
Conversation
Add test for ActionMonitoringTriggeredEvent rescheduling. One TODO intentionally left for later.
karlb
force-pushed
the
unconfirmed-blocks
branch
from
c985754
to
fc0c80b
Compare
Codecov Report
@@ Coverage Diff @@
## master #502 +/- ##
==========================================
- Coverage 91.26% 91.13% -0.13%
==========================================
Files 35 36 +1
Lines 2220 2233 +13
Branches 282 283 +1
==========================================
+ Hits 2026 2035 +9
- Misses 146 148 +2
- Partials 48 50 +2
Continue to review full report at Codecov.
|
| monitor_request.reward_proof_signature, | ||
| ).transact({"from": context.ms_state.address}) | ||
| ) | ||
| ), "This MS already monitored this channel. Should be impossible." |
There was a problem hiding this comment.
Could this be triggered somehow? Like:
- MS has a BP, and call
monitorwith it, thusclosing_tx_hashis set - We receive a new
MonitorRequest - Monitoring is triggered again
It's quite constructed because the client would need to be online...
There was a problem hiding this comment.
If we receive a new MR after calling monitor, should we call monitor again with the updated BP? That would increase our gas cost. But otherwise a different MS might do that and we will get no reward, although we already have spent gas.
There was a problem hiding this comment.
I guess in general this scenario is not likely.
And what you describe sounds like a loose/loose situation, not sure how we get out of that.
...and use UDC_SECURITY_MARGIN_FACTOR, instead.
for consistency with `monitoring_service/constants.py` and `raiden/constants.py`
This is the main work for #239.
Todos left for other PRs:
closing_tx_hash