A service address can be filtered out using the admin key. This would
be useful if a federated server failed, it could be filtered out so
that the auto-confirmation operates with the remaining services. If
all federated service addresses were filtered out the user would have to
either confirm manually or use their own explorer service.
These refactoring changes are for reducing existing and potential
duplication coming with the addition of new trading protocol support
in the gRPC API. Some minor styling and logic simplification changes
are also include.
- Convert OfferUtil to injected singleton, and move various offer related
utility methods into it.
- Delete both MakerFeeProvider classes, which were wrappers around the same
static old OfferUtil method.
- Inject OfferUtil into CreateOfferDataModel, CreateOfferViewModel,
TakeOfferDataModel, TakeOfferViewModel, MutableOfferDataModel,
MutableOfferViewModel, OfferDataModel, EditOfferDataModel,
EditOfferViewModel
- Refactor TakeOfferViewModel
Use OfferUtil, remove unused fields & methods.
Made minor logic simplification, style and formatting changes.
- MutableOfferDataModel
Made minor logic simplification, style and formatting changes.
- MutableOfferView uses new paymentAccount.isHalCashAccount().
- MutableOfferViewModel
Refactored to use new VolumeUtil, CoinUtil, OfferUtil.
Removed unused fields & accessors.
Made minor style change.
- Refactored OfferDataModel to use new OfferUtil
- Refactor CreateOfferService
Inject and use OfferUtil
Move some utility methods to OfferUtil
Remove unused fields
- Offer
Refactored to use new VolumeUtil for volume calculations.
Made stateProperty and errorMessageProperty fields private.
- PaymentAccount
Moved isHalCashAccount type check to this class.
Moved getTradeCurrency logic to this class.
- Contract, radeStatistics2, TradeStatistics3
Refactored to use new VolumeUtil for volume calculations.
- Trade
Refactored to use new VolumeUtil for volume calculations.
Made minor logic simplification, style and formatting changes.
- CoinUtil
Moved some coin utility methods into this class
- CoinUtilTest
Moved (coin related) tests from CoinCryptoUtilsTest and OfferUtilTest
into CoinUtilTest, and deleted OfferUtilTest, CoinCryptoUtilsTest.
- Adjust create and edit offer tests to model refactoring
Add signed witness to PayoutTxPublishedMessage
Remove usage of RefreshTradeStateRequest but leave it for backward compatibility
Move removeMailboxMessageAfterProcessing calls in finally branch
Rename methods
The 'arePeersPaymentAccountDataBanned' method in filterManager had a
parameter 'PaymentAccountFilter[] appliedPaymentAccountFilter' which
was used to pass over the PaymentAccountFilter which matched a banned
account. The result was only used at the fault handler (log) in the
ApplyFilter task. I think this was not needed to display and if it
should be done in a different way, e..g using a Consumer to pass back
the value, but as the method is a validation method returning a boolean
we should avoid to add side-effects like writing some property.
This allows the user to change required confirmation and it has impact
on open requests. Will be read at parsing the result.
Changed also the text field to not listen on text change but on focus
out so that the values are only updated once the user has left the
field and the value is valid. Otherwise small numbers like 1 might be
written during typing. The other values are only read at request start
and changes will have no impact on already started requests.
Also applies previous value in case the user added an invalid value at
focus out.
- Made display text shorter and added a tooltip.
- Allow very high numbers in devmode as max conf value
Remove testKey test (tested uid of model)
Refactor:
- Rename uid to id (we do not have a strict guarantee for uniqueness)
- Move id from model to request (its the id of the request)
to add auto confirm for other currencies in the future. The generic part
is only used where we would have issues with backward compatibility like
in the protobuf objects. Most of the current classes are kept XMR
specific and could be generalized once we add other assets, but that
would be an internal refactoring without breaking any network or
storage data. I think it would be premature to go further here as we
don't know the details of other use cases. I added the methods used from
clients to AutoConfirmResult, not sure if the API is well defined by
that, but as said that could become subject of a future refactoring once
another auto confirm feature gets added. Goal of that refactoring was
to avoid that we need more fields for trade and the the UI would have to
deal with lots of switch cases based on currency.
Sorry that is a larger commit, would have been hard to break up...
Use now the complete object data for signature creation. We use the protobuf data for creating the signature with DER encoding. We restict ourself more regarding backward compatibility but I think it is not a big problem.
If a new field is added to Filter and deployed the maintainer needs to publishes a new filter object. By using the new version he cannot remove the old filter from the network as the protobuf data is different and sig verification on the P2P datastorage level will fail. This is intended to keep the old filter alive for some time to support not updated users. We do not remove invalid filters anymore from our local storage to enable seed nodes to support also old filter objects.
For not updated users the new filter will fail at sig verification because the protobuf data is different. So they ignore the new filter and still use the old filter. For updated users the old filter will fail and the new filter is accepted. As it has a newer date it would also replace the old filter anyway. If the maintainer wants to delete the old filter from the network he can use the old app version and remove the filter. It is recommended to keep a copy of the data directory before the update so that the removal of the older filter is possible.
Refacorings:
- Rename isPeersPaymentAccountDataAreBanned to arePeersPaymentAccountDataBanned
- Rename isSignerPubKeyBanned to isWitnessSignerPubKeyBanned
* XMR seller is prompted to enter txId and viewkey.
* looks up the XMR transaction to verify that it has confirmed
* user can run their own validating service, or use the ones provided
* 100% agreement of all chosen services is necessary for confirmation
* feature can be configured and turned on/off from settings screen
* feature can be globally turned off via admin filter
* two code review passes from chimp1984
* one text review from m52go
