If the user entered an invalid hostname for a custom BTC node, such as a
V3 onion address, after restarting Bisq they would be presented with an
error due to the node being unreachable and unable to continue nor
correct the config.
So now a warning message will be shown in this situation informing the
user of an invalid config and once they restart their client they will
connect to the provided BTC nodes.
Fixes#3137
The previous commit introduces the BisqGrpcServer as a proof of concept,
but it is not yet ready for production use. This commit removes the
`--desktopWithGrpcApi` option that starts the gRPC server until such
time that it is production-ready.
This change also removes the `--desktopWithHttpApi` option for starting
an HTTP API server. The option has been in place for some time, but it
was 'false advertising' in the sense that nothing actually happened if
the user specified it, because there is in fact no HTTP API
implementation to be started.
Note that when the gRPC API option is reintroduced, it will be renamed
to `--rpcserver` or similar, following the convention in Bitcoin Core.
This commit introduces a new `grpc` module including the following key
types:
- BisqGrpcServer: The API implementation itself, along with generated
gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto.
- BisqGrpcServerMain: A 'headless' / daemon-like entry point for
running a Bisq node without the JavaFX desktop UI.
- BisqGrpcClient: A simple, repl-style client for the API that allows
the user to exercise the various endpoints as seen in the example
below.
In the `desktop` module, the BisqAppMain class has been modified to
start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has
been set to `true`.
In the `core` module, a new `CoreApi` class has been introduced
providing a kind of comprehensive facade for all Bisq functionality to
be exposed via the RPC API.
How to explore the proof of concept:
1. Run the main() method in BisqAppMain providing
`--desktopWithGrpcApi=true` as a program argument or alternatively, run
the main() method in BisqGrpcServerMain, where no special option is
required. In either case, you'll notice the following entry in the log
output:
INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888
2. Now run the main() method in BisqGrpcClient. Once it has started up
you are connected to the gRPC server started in step 1 above. To
exercise the API, type `getVersion` via stdin and hit return. You
should see the following response:
INFO bisq.grpc.BisqGrpcClient - 1.2.4
Likewise, you can type `getBalance` and you'll see the following
response:
INFO bisq.grpc.BisqGrpcClient - 0.00 BTC
and so forth for each of the implemented endpoints. For a list of
implemented endpoints, see BisqGrpcServer.start().
Note once again that the code here is merely a proof of concept and
should not be considered complete or production-ready in any way. In a
subsequent commit, the `--desktopWithGrpcApi` option will be disabled in
order to avoid any potential production use.
The content of this commit is the result of squashing a number of
commits originally authored by chimp1984 in the `chimp1984` fork's `grpc`
branch.
Co-authored-by: Chris Beams <chris@beams.io>
* Add bsq.ninja BSQ explorer operated by @wiz
* Add bsq.bisq.services BSQ explorer
* Add bsq.sqrrm.net BSQ explorer operated by @sqrrm
* Add bsq.vante.me BSQ explorer operated by @mrosseel
* Add bsq.emzy.de BSQ explorer operated by @emzy
Co-authored-by: Devin Bileck <603793+devinbileck@users.noreply.github.com>
After further testing, I realized I introduced a bug in commit
4f4b0f6ce9 because apparently the
ArrayList.contains() method does not properly work for
BlockChainExplorer object - to fix this I implemented a new
contains() method that uses string comparison instead
After further testing, I realized I introduced a bug in commit
4f4b0f6ce9 because apparently the
ArrayList.contains() method does not properly work for
BlockChainExplorer object - to fix this I implemented a new
contains() method that uses string comparison instead
* Upgrade mempool.space to full block explorer functionality
* Add mempool.space Tor V2 block explorer
* If no valid Bitcoin block explorer is set, use the 1st block explorer
According to issue #3641, the label "Bankgiro number", as it was
hardcoded in BankUtil.java, should not be used in Sweden.
The label "Kontonummer" is the correct one to be used in Sweden and
Norway.
Account number validation is implemented to Norwegian accounts in
AccountNrValidator.java.
There is no validation implemented to Swedish accounts, so nothing
to change there.
If account validation for Sweden is needed, a different method would
be needed.
Fixes#3641
* Add 2 new columns to vote result
Add threshold and quorum column.
Combine name and link column.
Add sorting function for accepted column.
Adjust column width.
* Fix sorting functions
* Improve column sorting
We got a report where a "tx already known" message caused a failed
trade but the deposit tx was valid.
To avoid such false positives we only handle reject messages which
we consider clearly critical.
Use a LinkedHashMap in place of a List, for the caching CurrencyUtil
fields 'allSortedFiatCurrencies' & 'allSortedCryptoCurrencies', using
the same iteration order as before. In this way, we can avoid a linear
search in the lookup methods getFiatCurrency & getCryptoCurrency.
In particular, this speeds up the activation of TradesChartsView (and to
a lesser extent OfferBookChartView), which make a lot of calls to
CurrencyUtil.getTradeCurrency in the fillTradeCurrencies/updateChartData
methods respectively.
At mediation we require a min. payout to the losing party to keep
incentive for the trader to accept the mediated payout. For Refund
agent cases we do not have that restriction.
According to https://github.com/bisq-network/proposals/issues/155
For buyer:
Default: 15%
Min. 15% for Altcoin, 15% for Fiat
Max. 50% for Altcoin, 50% for Fiat
Absolute min. deposit in BTC: 0.006 BTC (currently 40 USD)
For Seller:
Fixed: 15%
Absolute min. deposit in BTC: 0.006 BTC (currently 40 USD)
These are mostly injected objects that are now redundant, such as some
CoinFormatter and Preferences fields.
Also do some additional minor tidying of TradesChartsViewModel.
In case we had an unconfirmed change output we reset the
unconfirmedBsqChangeOutputList so that after a SPV resync we do not
have any dangling BSQ utxos in that list which would cause an incorrect
BSQ balance state after the SPV resync.
If a trader has a pending trade with an unconfirmed tx and is doing a
spv resync, the deposit tx is not found. They get displayed a popup
asking to restart and if problem continues to move trade to failed
trades. In regtest testing the missing deposit tx was always received
from the network at a restart. So this commit adds another button as
default button to shut down Bisq so that the user do first that activity
instead of moving the trade to failed trades.
It is not guaranteed that the trader will receive the missing deposit tx
at restart, but at least it is better as the state before. We should
find a way how to distinguish a valid unconfirmed tx from an invalid one
but it is not clear yet how we can do that and if it is feasible with
doing that with BitcoinJ only. It might require a external service to
look up the tx if it is in the mem pool, but even that will never gie a
100% certainty.
* Remove unused parameters from assorted methods
Exclude abstract or default methods, as well as cases where the
parameter is currently unused but is probably intended to be used later.
* Actually use the injected Clock param of isDateInTolerance
Use 'clock.millis()' instead of "new Date().getTime()" in SignedWitness
& AccountAgeWitness, as the latter may have been left as an oversight.
Also tidy the date field of the toString() methods.
* Suppress warnings of unused method params which may be needed later
Also fix forwarding of telescoping method parameters in FormBuilder and
FormattingUtils.
Use 'clock.millis()' instead of "new Date().getTime()" in SignedWitness
& AccountAgeWitness, as the latter may have been left as an oversight.
Also tidy the date field of the toString() methods.
* Add user preference combobox for BSQ block explorer with random default
* Remove betanet and testnet BSQ block explorers
* Always check if a valid BSQ block explorer is set
* Remove short cut for legacy arbitrator registration
* Change shortcut for reRepublishAllGovernanceData
* Use isAltOrCtrlPressed for removeFailedTrade
* Remove showStatisticsPopup
This was useful for legacy arbitrators as they received the trade fee
* Cleanup
- Remove setColumnSpan for titledGroupBg
- Fix row length
* Add list of shortcuts
* Update comment
* Change "click" to "press"
This fixes the problem if the local bitcoin core node is not detected by our client,
but bitcoinj is able to connect to it because of the auto connect to localhost behavior.
In that case the minimum required nodes to broadcast a transaction will be 4 (provided nodes settings),
but bitcoinj will only connect to one node. The requirement of 4 nodes will be never fulfilled and
the transaction never broadcasted.
Avoid mutating the Block tx list or the DaoState tx cache/index via a
Lombok getter. Instead wrap each in an unmodifiable[List|Map] & provide
specific mutator methods for use by DaoStateService to add newly parsed
transactions or load a DAO snapshot.
Also rename txMap to txCache, replace remaining use of getTxStream() in
the JSON file exporter with getUnorderedTxStream() (as this is safe) and
swap the arguments of the txCache initialisation merge function, for
exact consistency with the pre-caching behaviour.
Finally, add a missing assertDaoStateChange() and remove a potentially
harmful assertion from DaoStateService.onNewTxForLastBlock.
This is based on a suggested patch by @chimp1984 in the PR #3773 review.
Add getUnorderedTxStream() method to DaoStateService to stream directly
from the txMap cache/index wherever it is obviously safe to do so,
instead of iterating through the entire block list via getTxStream().
Also make getTxs() return a view of the txMap values in place of a copy.
This should improve efficiency slightly.
Build a HashMap of all BSQ transactions found, when loading the DaoState
from disc, and store it in a transient field which is always kept in
sync with the associated list of blocks. (The latter is only modified in
a couple of places in DaoStateService, making this straightforward.)
This is to speed up daoStateService.getTx(id), which is called from many
places and appears to be a significant bottleneck. In particular, the
initial load of the results in VoteResultView.doFillCycleList was very
slow (taking nearly a minute on a Core i3 machine) and likely to suffer
a quadratic slowdown (#cycles * #tx's) over time.
isDataOwner is used when deciding how many peer nodes should receive
a BroadcastMessage. If the BroadcastMessage originated
on the local node it is sent to ALL peer nodes with a small delay.
If the node is only relaying the message (it originated on a different
node) it is sent to MAX(peers.size(), 7) peers with a delay that is
twice as long.
All the information needed to determine whether or not the
BroadcastMessage originated on the local node is available at the final
broadcast site and there is no reason to have callers pass it in.
In the event that the sender address is not known during broadcast (which
is only a remote possibility due to how early the local node address
is set during startup) we can default to relay mode.
This first patch just removes the deep parameters. The next will remove
everything else. There is one real change in LiteNodeNetworkService.java
where it was using the local node when it should have been using the
peer node. This was updated to the correct behavior.
* Fix language tags so script and regional variants work correctly
* Adjust update_translations.sh language tags for script/regional variants
ACKs for top commit:
@ripcurlx:
ACK 089232716d
Fixes https://github.com/bisq-network/bisq/issues/3721
(part of the problem was that the trade ended up in failed trade)
Refactor method and add comments.
We did not handle the case of a mediated payout. isPayoutPublished() is
only reflecting non-disputed trade payouts.
Fixes https://github.com/bisq-network/bisq/issues/3721
(part of the problem was that the trade ended up in failed trade)
Refactor method and add comments.
We did not handle the case of a mediated payout. isPayoutPublished() is
only reflecting non-disputed trade payouts.
With v1.2 we use 2of2 multisig for deposit tx. This commit changes the
manual payout window to reflect that.
- Remove unused code from legacy arbitration
- Fix comments
With v1.2 we use 2of2 multisig for deposit tx. This commit changes the
manual payout window to reflect that.
- Remove unused code from legacy arbitration
- Fix comments
* Use strict stubbing for ReceiptValidatorTest to avoid confusion
Remove redundant stubs from the MoneyGram and Western Union tests and
ensure that all such stubs result in failure. In particular, the 'offer'
mock is never accessed directly by ReceiptValidator.
* Prevent taking of offers with unequal bank account types
Use stricter criteria when deciding which of the taker's accounts (if
any) are valid for a given offer. Specifically, prevent National Bank
accounts from being used to take Same / Specific Bank(s) offers, so the
three payment method types can never being mixed.
This prevents an error on the trading peer when the trade starts, due to
enforcement of equal maker & taker payment method IDs (except for SEPA)
in the Contract payload constructor.
This partially addresses #3602, where the erroneous peer response causes
the taker to be presented with a confusing timeout.
* [PR COMMENTS] Make maxSequenceNumberBeforePurge final
Instead of using a subclass that overwrites a value, utilize Guice
to inject the real value of 10000 in the app and let the tests overwrite
it with their own.
* [TESTS] Clean up 'Analyze Code' warnings
Remove unused imports and clean up some access modifiers now that
the final test structure is complete
* [REFACTOR] HashMapListener::onAdded/onRemoved
Previously, this interface was called each time an item was changed. This
required listeners to understand performance implications of multiple
adds or removes in a short time span.
Instead, give each listener the ability to process a list of added or
removed entrys which can help them avoid performance issues.
This patch is just a refactor. Each listener is called once for each
ProtectedStorageEntry. Future patches will change this.
* [REFACTOR] removeFromMapAndDataStore can operate on Collections
Minor performance overhead for constructing MapEntry and Collections
of one element, but keeps the code cleaner and all removes can still
use the same logic to remove from map, delete from data store, signal
listeners, etc.
The MapEntry type is used instead of Pair since it will require less
operations when this is eventually used in the removeExpiredEntries path.
* Change removeFromMapAndDataStore to signal listeners at the end in a batch
All current users still call this one-at-a-time. But, it gives the ability
for the expire code path to remove in a batch.
* Update removeExpiredEntries to remove all items in a batch
This will cause HashMapChangedListeners to receive just one onRemoved()
call for the expire work instead of multiple onRemoved() calls for each
item.
This required a bit of updating for the remove validation in tests so
that it correctly compares onRemoved with multiple items.
* ProposalService::onProtectedDataRemoved signals listeners once on batch removes
#3143 identified an issue that tempProposals listeners were being
signaled once for each item that was removed during the P2PDataStore
operation that expired old TempProposal objects. Some of the listeners
are very expensive (ProposalListPresentation::updateLists()) which results
in large UI performance issues.
Now that the infrastructure is in place to receive updates from the
P2PDataStore in a batch, the ProposalService can apply all of the removes
received from the P2PDataStore at once. This results in only 1 onChanged()
callback for each listener.
The end result is that updateLists() is only called once and the performance
problems are reduced.
This removes the need for #3148 and those interfaces will be removed in
the next patch.
* Remove HashmapChangedListener::onBatch operations
Now that the only user of this interface has been removed, go ahead
and delete it. This is a partial revert of
f5d75c4f60 that includes the code that was
added into ProposalService that subscribed to the P2PDataStore.
* [TESTS] Regression test for #3629
Write a test that shows the incorrect behavior for #3629, the hashmap
is rebuilt from disk using the 20-byte key instead of the 32-byte key.
* [BUGFIX] Reconstruct HashMap using 32-byte key
Addresses the first half of #3629 by ensuring that the reconstructed
HashMap always has the 32-byte key for each payload.
It turns out, the TempProposalStore persists the ProtectedStorageEntrys
on-disk as a List and doesn't persist the key at all. Then, on
reconstruction, it creates the 20-byte key for its internal map.
The fix is to update the TempProposalStore to use the 32-byte key instead.
This means that all writes, reads, and reconstrution of the TempProposalStore
uses the 32-byte key which matches perfectly with the in-memory map
of the P2PDataStorage that expects 32-byte keys.
Important to note that until all seednodes receive this update, nodes
will continue to have both the 20-byte and 32-byte keys in their HashMap.
* [BUGFIX] Use 32-byte key in requestData path
Addresses the second half of #3629 by using the HashMap, not the
protectedDataStore to generate the known keys in the requestData path.
This won't have any bandwidth reduction until all seednodes have the
update and only have the 32-byte key in their HashMap.
fixes#3629
* [DEAD CODE] Remove getProtectedDataStoreMap
The only user has been migrated to getMap(). Delete it so future
development doesn't have the same 20-byte vs 32-byte key issue.
* [TESTS] Allow tests to validate SequenceNumberMap write separately
In order to implement remove-before-add behavior, we need a way to
verify that the SequenceNumberMap was the only item updated.
* Implement remove-before-add message sequence behavior
It is possible to receive a RemoveData or RemoveMailboxData message
before the relevant AddData, but the current code does not handle
it.
This results in internal state updates and signal handler's being called
when an Add is received with a lower sequence number than a previously
seen Remove.
Minor test validation changes to allow tests to specify that only the
SequenceNumberMap should be written during an operation.
* [TESTS] Allow remove() verification to be more flexible
Now that we have introduced remove-before-add, we need a way
to validate that the SequenceNumberMap was written, but nothing
else. Add this feature to the validation path.
* Broadcast remove-before-add messages to P2P network
In order to aid in propagation of remove() messages, broadcast them
in the event the remove is seen before the add.
* [TESTS] Clean up remove verification helpers
Now that there are cases where the SequenceNumberMap and Broadcast
are called, but no other internal state is updated, the existing helper
functions conflate too many decisions. Remove them in favor of explicitly
defining each state change expected.
* [BUGFIX] Fix duplicate sequence number use case (startup)
Fix a bug introduced in d484617385 that
did not properly handle a valid use case for duplicate sequence numbers.
For in-memory-only ProtectedStoragePayloads, the client nodes need a way
to reconstruct the Payloads after startup from peer and seed nodes. This
involves sending a ProtectedStorageEntry with a sequence number that
is equal to the last one the client had already seen.
This patch adds tests to confirm the bug and fix as well as the changes
necessary to allow adding of Payloads that were previously seen, but
removed during a restart.
* Clean up AtomicBoolean usage in FileManager
Although the code was correct, it was hard to understand the relationship
between the to-be-written object and the savePending flag.
Trade two dependent atomics for one and comment the code to make it more
clear for the next reader.
* [DEADCODE] Clean up FileManager.java
* [BUGFIX] Shorter delay values not taking precedence
Fix a bug in the FileManager where a saveLater called with a low delay
won't execute until the delay specified by a previous saveLater call.
The trade off here is the execution of a task that returns early vs.
losing the requested delay.
* [REFACTOR] Inline saveNowInternal
Only one caller after deadcode removal.
Use stricter criteria when deciding which of the taker's accounts (if
any) are valid for a given offer. Specifically, prevent National Bank
accounts from being used to take Same / Specific Bank(s) offers, so the
three payment method types can never being mixed.
This prevents an error on the trading peer when the trade starts, due to
enforcement of equal maker & taker payment method IDs (except for SEPA)
in the Contract payload constructor.
This partially addresses #3602, where the erroneous peer response causes
the taker to be presented with a confusing timeout.
Remove redundant stubs from the MoneyGram and Western Union tests and
ensure that all such stubs result in failure. In particular, the 'offer'
mock is never accessed directly by ReceiptValidator.
This prevents a scammer to use publicly known account details
(without being in control of the account) as a seller to get
signed by a buyer. The money received in the seller account might
not be detected by the legitimate owner and/or the money not sent back.
30 days later the scammer could use this signed account as seed to peer sign other stolen accounts.
Addresses the first half of #3629 by ensuring that the reconstructed
HashMap always has the 32-byte key for each payload.
It turns out, the TempProposalStore persists the ProtectedStorageEntrys
on-disk as a List and doesn't persist the key at all. Then, on
reconstruction, it creates the 20-byte key for its internal map.
The fix is to update the TempProposalStore to use the 32-byte key instead.
This means that all writes, reads, and reconstrution of the TempProposalStore
uses the 32-byte key which matches perfectly with the in-memory map
of the P2PDataStorage that expects 32-byte keys.
Important to note that until all seednodes receive this update, nodes
will continue to have both the 20-byte and 32-byte keys in their HashMap.
Now that the only user of this interface has been removed, go ahead
and delete it. This is a partial revert of
f5d75c4f60 that includes the code that was
added into ProposalService that subscribed to the P2PDataStore.
#3143 identified an issue that tempProposals listeners were being
signaled once for each item that was removed during the P2PDataStore
operation that expired old TempProposal objects. Some of the listeners
are very expensive (ProposalListPresentation::updateLists()) which results
in large UI performance issues.
Now that the infrastructure is in place to receive updates from the
P2PDataStore in a batch, the ProposalService can apply all of the removes
received from the P2PDataStore at once. This results in only 1 onChanged()
callback for each listener.
The end result is that updateLists() is only called once and the performance
problems are reduced.
This removes the need for #3148 and those interfaces will be removed in
the next patch.
Previously, this interface was called each time an item was changed. This
required listeners to understand performance implications of multiple
adds or removes in a short time span.
Instead, give each listener the ability to process a list of added or
removed entrys which can help them avoid performance issues.
This patch is just a refactor. Each listener is called once for each
ProtectedStorageEntry. Future patches will change this.
* Remove trailing spaces
* Add toProtoTradeStatistics2 method
API will use getTradeStatistics and expect TradeStatistics2 not
PersistableNetworkPayload
* Add CreateOfferService class
* Remove commented out code
* User weaker access, add final
* Add getRandomOfferId method
* Add getSellerSecurityDeposit method
* Add getEstimatedFeeAndTxSize method
- Rename estimateTxSize to updateEstimatedFeeAndTxSize
- Add getEstimatedFeeAndTxSize method to CreateOfferService
- Add dependent methods and fields
* Use methods from createOfferService
- Use getBuyerSecurityDepositAsCoin and getSellerSecurityDepositAsCoin
from CreateOfferService
* Use txFeeFromFeeService from createOfferService
- Use getEstimatedFeeAndTxSize from CreateOfferService for
txFeeFromFeeService
* Use getPriceAsLong from createOfferService
* Use marketPriceMarginParam from createOfferService
* Pass useMarketBasedPriceValue to getPriceAsLong
* Use getMaxTradeLimit from createOfferService
* Use createAndGetOffer from createOfferService
* Remove unused fields
* Add createOfferService, remove unused params
* Use weaker access
* Add null checks
* Add log of params, Cleanup
* Remove unused fields
* Use weaker access
* Remove trivial methods
* Remove trivial methods, rename methods
* Sort params for offer as they are used
* Use getReservedFundsForOffer from createOfferService
* Add MakerFeeProvider
* Adjust to new super class params
* Remove sellerSecurityDeposit field, refactor placeOffer
* Adjust tests to new params
* Don't extend ActivatableViewAndModel when the model is empty
Remove the no-arg constructor from ActivatableViewAndModel, which sets
a dummy Activatable singleton as the model. (Since the model type param
can't be checked at runtime, improper use of the constructor could cause
heap pollution.)
Instead, extend 'ActivatableView<R, Void>' consistently, as other views
without a model currently do.
* Improve type safety of the fluent interface of Overlay<T>
Refactor all the unchecked casts from Overlay<T> to T into a single
private cast() method. Also add a runtime type check to the constructor
to prevent creation of window objects of the form "A extends Overlay<B>"
for unrelated A & B, as such casts would then subvert the type system.
* Improve type safety of ProtoUtil.collectionToProto(Collection)
Add a Class<T> parameter to the method, in order to avoid an unchecked
cast to the Message type T. The cast was wrapped in a try-catch block,
which is useless due to erasure, so use Class.cast(..) instead.
* Avoid raw types to prevent unchecked casts in Log.java
Add missing ILoggingEvent type arg to local variable declarations.
* Avoid unchecked casts when deserializing JSON using Gson
* Fix unchecked casts in views due to raw chart point types
Add missing 'Number' coord type args to some XYChart.(Data|Series) &
AreaChart declarations, and avoid passing them as generic varargs, in
order to eliminate some more unchecked cast warnings.
Also simplify OfferBookChartView.updateChartData() by unboxing the x-
coordinate of each (buy & sell) datapoint.
* Avoid raw type bounds in class declarations to fix unchecked warnings
Make sure the generic classes MutableOfferView & AgentRegistrationView
don't use raw bounds for their associated view models, as that leads to
unchecked assignments from the model fields further down.
* Fix some remaining suppressed unchecked casts in the UI logic
(This still leaves a few more which are hard to avoid.)
* Fix a few remaining unsuppressed unchecked warnings
Fixes issues #3601 and #3537.
The bug only happens when the offer has MIN-MAX value range.
The new isAmountValidForOffer in PaymentAccountUtil.java consider only the MAX amount, but the button to take the offer is ungrayed considering the MIN amount, which causes the bug.
Add a Class<T> parameter to the method, in order to avoid an unchecked
cast to the Message type T. The cast was wrapped in a try-catch block,
which is useless due to erasure, so use Class.cast(..) instead.
* Updating trading instructions for XMR (Monero)
Prove payments:
- clarifying that the official wallets (Monero GUI or CLI) are NOT required to send XMR, since user can use some alternative wallets (desktop: MyMonero, Exodus / mobile: Cake Wallet, MyMonero, Monerujo) that provide the information required to prove a payment (transaction key, transaction ID and destination address). This information is not provided by the remaining desktop and mobile wallets that currently support Monero, but since they could provide it in the future, I kept the warning about using other wallets different from the previously mentioned.
- listing Monero GUI as first option (for most users), and CLI as second option (for advanced users)
- renaming "transaction hash" to "transaction ID", which is used in official wallets
- renaming "tx private key" to "transaction key", which is used in official wallets
- adding "Secret key" as synonymous for "transaction key" (used in MyMonero wallet)
- adding "destination address" and keeping "recipient's address" as synonymous
- renaming History tab to Transactions tab in Monero GUI
- adding "save recipient address" option must be enabled in Cake Wallet settings
Check payments:
- adding Monero GUI must be in Advanced mode
- adding Monero GUI verification must be done in Check Transaction section of Prove/check page
- adding parameters TXID TXKEY ADDRESS to the command check_tx_key in Monero CLI, as instructions in (https://www.getmonero.org/resources/user-guides/prove-payment.html)
- adding Explore Monero website (https://www.exploremonero.com/receipt) as alternative to verify payments
- removing payment ID instructions (it is being deprecated at the end of November in v0.15)
More info:
- directing to subreddit Monero support (https://www.reddit.com/r/monerosupport/), which is actively maintained, instead of Monero forum (https://forum.getmonero.org).
* Add max allowed message option to Popup and increase window size for Monero to improve readability
Switch from System.currentTimeMills() to
Clock.millis() so dependency injection can
be used for tests that need finer control of time.
This involves attaching a Clock to the resolver
so all fromProto methods have one available when they
reconstruct a message. This uses the Injector for the APP
and a default Clock.systemDefaultZone is used in the manual
instantiations.
Work was already done in #3037 to make this possible.
All tests still use the default system clock for now.
* Update MobileModel parseDescriptor to support iPhone 11
It was parsing only the first digit of the version and using that in a
comparison check to determine if the version is greater than 5.
This meant for the iPhone 11 it was comparing 1 > 5, returning an
incorrect result.
It now supports multi-digit version numbers (i.e. 11), including
support for a suffix in the version (i.e. 11S), just in case...
* Update to reflect isContentAvailable supports iPhone 6s and newer
Prove payments:
- clarifying that the official wallets (Monero GUI or CLI) are NOT required to send XMR, since user can use some alternative wallets (desktop: MyMonero, Exodus / mobile: Cake Wallet, MyMonero, Monerujo) that provide the information required to prove a payment (transaction key, transaction ID and destination address). This information is not provided by the remaining desktop and mobile wallets that currently support Monero, but since they could provide it in the future, I kept the warning about using other wallets different from the previously mentioned.
- listing Monero GUI as first option (for most users), and CLI as second option (for advanced users)
- renaming "transaction hash" to "transaction ID", which is used in official wallets
- renaming "tx private key" to "transaction key", which is used in official wallets
- adding "Secret key" as synonymous for "transaction key" (used in MyMonero wallet)
- adding "destination address" and keeping "recipient's address" as synonymous
- renaming History tab to Transactions tab in Monero GUI
- adding "save recipient address" option must be enabled in Cake Wallet settings
Check payments:
- adding Monero GUI must be in Advanced mode
- adding Monero GUI verification must be done in Check Transaction section of Prove/check page
- adding parameters TXID TXKEY ADDRESS to the command check_tx_key in Monero CLI, as instructions in (https://www.getmonero.org/resources/user-guides/prove-payment.html)
- adding Explore Monero website (https://www.exploremonero.com/receipt) as alternative to verify payments
- removing payment ID instructions (it is being deprecated at the end of November in v0.15)
More info:
- directing to subreddit Monero support (https://www.reddit.com/r/monerosupport/), which is actively maintained, instead of Monero forum (https://forum.getmonero.org).
