- Make all PaymentMethod constructors private
- Use PaymentMethod.getPaymentMethodById in Offer for getting the
PaymentMethod. This change a bit the context as now we always create the
PaymentMethod from the actual code base in contrast to the data which
have been used when creating the offer. As our fields as final and must
not change in software updates it should have no issues but we have to
keep that in mind to not alter the default values.
- Added a runtimeException in case the maxTradeLimit does not match one
of our default values.
- Use PaymentMethod.getDummyPaymentMethod(GUIUtil.SHOW_ALL_FLAG)
instead of new PaymentMethod(GUIUtil.SHOW_ALL_FLAG))
- We had an automate remove accounts for those payment methods for long
time, so we can assume that no traders have any of those accounts still
in their persisted user objects and it is safe to completely remove them.
Only part where we cannot remove it is the PB definitions (actually I
think we could remove those as well, but not 100% sure and it seems to
be more safe to mark those as deprecated and leave the entries).
- Assign paymentMethods in static final field
- Add static fields for default trade limits
- Remove deprecated payment methods
- Remove onAllServicesInitialized and use static initializer instead
- Re-purpose maxTradeLimit for indicating risk factor
- Calculate real trade limit in the getMaxTradeLimitAsCoin method
- Rename getActivePaymentMethods to getPaymentMethods
- Set max trade limit to 2 BTC (for altcoins)
- Add MAX_TRADE_LIMIT to Param
- Round first month trade limit to ensure we stick with precision 4 for
the btc amount
- Use risk factors to derive trade limits for different payment method
risk categories
Issue: If an IOException is raised when attempting to create
tor and the hidden service, the application will just quit without
any indication to the user. One particular scenario where this occurs
is mentioned in https://github.com/bisq-network/bisq/issues/2398.
Cause: There is an explicit statement to exit the application when an
IOException is raised.
Fix: Rather than just exit the application, show an error message
and inform the user what went wrong.
To avoid empty handlers I have set all methods to default so the client
code implements only the used one.
Move handler code from onNewBlockHeight to
onParseTxsCompleteAfterBatchProcessing to avoid too much UI updates
while parsing.
- If a proposal had a tx which is not in our BSQ state it was not removed
- If a tx was outdated (> 60 days old) it was only removed if we are
in proposal phase. We added check for past cycle to cover those as well.