is not exceeding TOLERATED_SMALL_TRADE_AMOUNT (0.01 BTC) we
return true for verifyPeersTradeAmount.
Before such offers could not be taken even the witness
check would be irrelevant as the trade amount is below the
threshold where we require account age witness.
Outlier data filter used for the Market Offer Book chart, now accounts
for the switching display position of Buy, Sell data depending on
currency type (Crypto or Fiat).
The api is going to need this method, so it was moved from desktop to core.
- Moved the method from WithdrawalView to WalletService.
- Removed an unused initilizer in WithdrawalView.
Users need to be able to preserve their acct age when moving a
payment account to a new client.
Also adjusted affected tests, and did some minor refactoring
of the custom gson type adaptor.
This change fixes the blocking problem in the fee rate request api.
Also redefined the TxFeeRateInfo.
- Redefined grpc.proto message TxFeeRateInfo, added
lastFeeServiceRequestTs field. (CLI user may want to know
TS of last fee request.)
- Adjusted TxFeeRateInfo proto wrapper.
- Adjusted CurrencyFormat and BtcTxFeeRateTest to new TxFeeRateInfo.
- Added @Getter annotation to FeeService. (CLI user may want to know
TS of last fee request).
- Pass resultHandler from GrpcWalletsService through CoreApi, to
CoreWalletsService's tx fee rate api methods.
These do not buy enough in the way of performance, at the cost of
so many additional lines. Buy these checks should be done for
debug log statements that have expensive parameters.
Widen payment account dropdown in create & edit offer screens
Sort payment account dropdown by name in create & edit offer screens
Sort account listview by name in manage fiat accounts screen
Sort account listview by name in manage altcoin accounts screen
Bug fix: do not adjust BTC amount in edit offer screen
There was a bug where editing an existing offer could have its payment
account changed to one with more restrictive limits and the offer
would still be allowed (although not take-able).
It should not be allowed to be saved in this case. This change takes
proper heed of the "allowAmountUpdate" flag which is false for offer
edits. e.g. edit an F2F buy for 0.25, change to Zelle unsigned, the
offer will prevent saving.
Make sure the taker checks the value of the 2-of-2 multisig output of
the deposit tx created by the maker, before signing it. This avoids a
potential security hole, where the maker attempts to steal most of the
deposit by using the wrong output value and adding an extra 'change'
output to himself.
Note that there's no actual vulnerability at present, as the output
value is indirectly checked via the validation of the delayed payout tx.
In particular, the extra checks added in 345426f as part of #4789 (Fix
remaining blackmail vulnerabilities) place a lower bound on the delayed
payout tx input value and with it the deposit tx output value. However,
explicitly checking the amount is more robust.
