It can be that one user opened a dispute but in the meantime the other
peer sent or received the funds. Atm after a dispute has been opened the
user cannot confirm anymore. This restriction forces all cases to be
resolved in arbitration. If we relax that restriction to allow users
to still confirm after they opened a dispute we might reduce work load
for arbitrators as the payout can be done by the users if both have
confirmed. The arbitrator still need to close the case to that the
open support cases get closed, but the payout tx was already created
by the users.
Arbitrators reported that there are some cases where the confirm
payment or receipt buttons are disabled and they cannot confirm it.
Another issue is that sometimes the confirm msg does not arrive and
after button click its disabled so the message cannot be resent but
clicking the button again.
The software should handle such case and there is some automatic resend
but it seems it does not cover all cases. By keeping the button active
the user can click again and there is higher chance that such cases
get resolved by itself.
I am aware that this is not a good solution but to find out what
exactly caused the issue and to build a more resilient resend
functionality requires much more work and this seems to be a easy fix
which might avoid many disputes.
There was missing the block notify port as well as the options have
not been applied correctly which led to the situation that when you
run the same application in full mode and later in lite mode that
data got persisted.
Added also to the footer a note if full mode is running.
When we request at startup the blocks from a seed which has not yet
received out capabilities or node address we will not get a response.
We do not want to depend on the state in the getData domain in the
p2p network by using only a seed which has already responded but we
prefer to make sure the seednode will get all the data by our request
to be able to respond.
The referralId support did not get any interest so we removed it from
the UI. It is still supported via prog argument and can be re-enabled
again once there are use cases (API?).
I left it commented out to make re-enabling easier.
Once we get a new block from BitcoinJ we start a timer and check in 10
seconds if we have received the block from the P2P network. If not we
request it from the seed nodes.
