It's hard for the seller to read the buyer's account details because the
string is long, e.g, "Account owner name (first, middle, and initial of
last name): Alice A., Mobile no. +71234567890, Bank name SBP Bank".
I shortened "Account owner name (first, middle, and initial of last
name)" to "Account owner name".
Recent changes broke reproducibility and the last release's JAR_HASH
file contains "Dummy file (needed for updater)". We need to keep
creating a dummy file because the updater fails without a dummy file.
This change fixes the bug.
We show the ARS blue rate popup whenever the user creates a payment
method and ARS is selected. Therefore, it makes sense to always show the
ARS blue rate popup.
At the moment, we show the ARS Blue Rate popup when the user saves a
single currency payment account (PR #7122). This misses many payment
accounts that support ARS. The new behaviour is to show the ARS Blue
Rate popup when ARS is selected during account generation (either
pre-selected or later selected by the user).
Payment accounts supporting ARS:
- CashByMail
- CashDeposit
- F2F
- MoneyGram
- National bank
- OKPayAccount (deprecated)
- Same bank
- Specific bank
- Transferwise
- Uphold
- Western Union
Code Review follow-up - Remove substition replacements for strings which
do not have any substition parameters, as these are causing confusion as
to whether apostrophes are required.
When clicking Create Buy/Sell Offer, or Edit/Duplicate/Clone an existing
offer, randomly the initial display of "Currency" associated with the
initially selected payment method was displayed as blank. This seems to
have been caused by scheduling the selection of the initial payment
method combobox selection to happen on a different thread rather than
immediately selecting it (apparently, sometimes the secondard event to
select the currency gets lost).
Added new displayStrings into other language files as a placeholder for
future translation, minor revision to order of payment method fields
in source code (cosmetic, no impact on functionality)
This is the standard P2P payment method in Russia to perform funds transfers and
payments between Russian bank accounts in Russian Rubles. There is no chargeback
risk. Recipient bank account is located using telephone number and bank name,
and sender receives recipients first name, middle name, and initial of last name
to confirm the phone number entered is correct before sending. Adding this new
payment method has been discussed at length on the GitHub 'growth' channel at:
https://github.com/bisq-network/growth/issues/288
Created new class PhoneNumberRequiredLengths.java with a Map lookup for the
requiredlength of phone numbers in select countries that are well-known to
have uniform fixed-length phone number throughout. Country codes missing
will continue to use just the previous length-range algorithms. Lookup
into this Map is integrated into PhoneNumberValidator.java, no longer
needed an overloaded constructor to provide this functionality.
[New .java file was accidentally omitted from previous commit]
Created new class PhoneNumberRequiredLengths.java with a Map lookup for the
requiredlength of phone numbers in select countries that are well-known to
have uniform fixed-length phone number throughout. Country codes missing
will continue to use just the previous length-range algorithms. Lookup
into this Map is integrated into PhoneNumberValidator.java, no longer
needed an overloaded constructor to provide this functionality.
Original commit omitted the new display string used by this new
feature. Additionally, added two unittests to verify the code
changes in this pull request work and do not break existing
functionality.
Until now, national phone numbers worldwide just had to be between
5-12 digits long to pass validation. However, many countries have a
specific number of of digits in all their phone numbers which is
very well known (EX: all USA numbers are 10 digits long). So this
change adds an optional parameter to specify how many digits must
be in the phone number for it to validate. Uncommited changes will
also use this new capability, provided this pull request is adopted.
To slightly save storage & bandwidth, create low-R signatures in places
besides tx ScriptSigs & witnesses, such as merit lists, proofs of burn,
filter, alert & accounting authentication data.
(Also, to make setup of mock keys a little easier, bypass wrapping of
keys that are already instances of 'LowRSigningKey' in the factory
method, 'LowRSigningKey.from(ECKey)'.)
