Our Socks5SeedOnionDiscovery contains deprecated Tor V2 onion addresses
that are not supported anymore. BitcoinCoreSeedListDiscovery contains
Tor V3 addresses that are shipped with Bitcoin Core.
- Update bitcoin core seed list to upstream version
- Use IpV4 and onion addresses from it
Our users are still protected because we connect to IpV4 addresses
through Tor. This improves connectivity because Bitcoin Core creates an
ephemeral onion service on each startup.
Removed *non-printable characters* that were accidentally added
during word analysis of the translations file:
... (например, «С днем \u200b\u200bрождения, Сьюзен!») ...
While apparently harmless and invisible, these do not belong
and a needle in the haystack later, so removing them now.
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.
Previously, about 1,585 out of 2,676 strings (59.23%) were
translated into Russian, the rest remained in English.
This meant a native Russian speaker with limited English
ability might have great difficulty using Bisq application
and might not understand or notice the way the system
works and the many important pop-ups that can appear.
Now there are about 2,103 strings in Russian (78.59%) and
most of the messages the end user normally would see are
displayed in Russian, making the application very usable.
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).
Users in most countries (see BankUtil.useValidation() ) can create a "Transfer Same Bank"
account with no BIC/SWIFT code. However, to create an offer using this account, it must
have a bankId or JAVA will throw a 'null pointer exception', and the app. will become
unhealthy and hang trying on exit. This fix adds a validation check for the condition and
throws a more "friendly" exception which explains the problem and keeps the app. healthy.
Offers match these payment method types only if bank names entered
in the maker and taker accounts are the same. However, if the maker
entered, for example, "BANK OF AMERICA" as bank name in their Bisq
account but the taker entered "Bank of America", the offer account
mismatches without this fix to make the match case-insensitive.
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.
The Bisq policy for displayStrings is stated in the comments
at the beginning of the primary (English) file that all string
keys should be present in all language files, even though
fallthrough would otherwise result. In reviewing how well
the language files actually comply with this rule, just 5
strings out 2,670 did not comply; these changes correct that
and restore all language files to have all strings.
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.
By default, JAVA sorts foreign characters below English characters.
However, the payment methods that are translated are also more
likely to be used by someone native to that language, so it makes
better sense to sort as two separate sets and put the foreign
language ones on top. This commit does that for payment methods.
Prevent 'KeyIsEncryptedException' from being thrown when signing with a
'LowRSigningKey'-wrapped, encrypted HD key, due to breakage of the
apparent invariant that the 'keyCrypter' field of 'ECKey' should be null
whenever the key isn't encrypted.
When signing with a wrapped, encrypted HD key, the original key is
decrypted and then re-wrapped as a 'LowRSigningKey' instance. This was
blindly copying the 'keyCrypter' property of the decrypted key. But
'DeterministicKey::getKeyCrypter' returns non-null if its parent does,
even if the actual field is null, and the decrypted HD key has the same
parent as the encrypted original. Thus, blindly copying the property
(rather than the field) breaks the above invariant.
Fixes issue #7241 with blind voting, caused by the earlier PR #7238
which introduced low-R nonce grinding.
