hubiinetwork / nahmii-challenge-bot Goto Github PK

This does likely require updates of the test framework where settlements are initiated.

Given the challenge bot is restarting after a crash
when the challenge-bot is starting
then it must be able to check last block it has processes
in order to capture all contract events that were sent during downtime.

Given a settlement is disputable
then the challenge-bot should select the receipt that shows the larges overrun
in order to increase the odds of winning a dispute.

Given challenge-bot is running
when processing challenges
then metric statistics should be generated.
The metrics should include progress notifications and current L0 balance.

Message: 'Receipt has wrong nonce.'

Code checks that payments nonces are in sequence.
This is wrong since the list only contains sender receipts.
It is enough to check that nonce sequence is increasing.
Otherwise all receipts have to be part of the payment list.

Settlement workflow must also work for Bob.
i.e. Settlement must work for an initiator for which the last event before/at settlement was an incoming event.

Tests for this is missing and must be made.

Given a contract provider
when the challenge handler needs contracts
then it should get the contracts from the contract provider.

Currently, the app is creating contracts and handling them to the challenge handler as arguments.
An alternative is to let the challenge handler get the contracts from a contract provider.
This issue is about doing the necessary re factorization

When the challenge bot handles a contract event,
then register the current ETH balance of the bot as a metric
in order to be able to track and ensure that the challenge bot has enough funds.

As a component of the nahmii solution
I want to get my dependency to nahmii-sdk updated
In order to support NII2 token on ropsten.

'Property is null'
ProofCandidate contains null values when no payment is found.
Logic does not handle that particular situation.

Given a dispute has been successful
when the notifications that confirms this arrives
the challenge but must seize the balance of the offending wallet.

Given the challenge-bot has detected an overdraw and initiates a call
when this dispute fails because of technical issues
a notification should be sent to a human operator
in order to raise awareness that a fraud may be going on.

When a dispute causes a VM revert
then the challenge bot fails to detect it as an error.

To detect real error, the challenge bot should check for all proposal conditions that may
make dispute rejectable and handle all VM reverts as fatal errors.

In particular DSC proposalDisqualificationNonce() should be checked before dispute is attempted.

Given the challenge-bot has disputed a payment
when the associated locked wallet is released
then seize the balance.

The challenge bot should at startup make a cache of wallets it has locked by the latest 1000 blocks.
Every time a relevant wallet-lock event occurs it should add it to the cache.
With the interval of (e.g.) one hour it should check if any visible time has been reached and then seize the associated balance.

Given payments wallets to be queried
when those are queried
then all payments that falls into the selection must be received
in order to not loose any payment information.

There is a bug in the current implementation that fails to download all needed payments.
It only download one page of results.