Move some potentially sharable utility code from desktop's ClosedTrade
models to core's new ClosedTradeUtil.
The API's `gettrades --category=<open|closed|failed>` method will need
some of this logic on the server side, but the scope of this refactoring
is larger in the interest of a more complete refactor, and avoiding
duplication in the future.
In practice, presentation/display logic should be kept in UIs, but the core
api will need to duplicate a very small part of the code in DisplayUtils if
a very small part of this refactoring is not done. Instead of moving a tiny
bit of the volume formatting methods, all of them are moved to core.
This is a bug fix for the CLI's displayed fiat trade cost
value, which should be trade.volume, not offer.volume. Offer volume
varies with BTC volatility, and the CLI should be showing the trade.volume
value instead, frozen when the contract is made.
Method was added on the false assumption `PaymentAccount#hasMultipleCurrencies()`
would not always return a correct value when a `PaymentAccount` instance is created
via reflection. But `hasMultipleCurrencies()` will work as long as appropriate
PaymentAccount subclasses continue setting their `tradeCurrencies` fields within
their default constructors.
Several payment methods support multiple trade currencies and a selected
trade currency, but the api's payment account creation has not let CLI
users specify them in the json form passed to the `createpaymentacct`
command.
This change adds `tradeCurrencies` and `selectedTradeCurrency` fields
to the appropriate json forms.
Some i18n property values can be used by the API if long strings are
wrapped before written as commments to json payment account forms, or
written to the CLI console.
This change anticipates the addition of the more complex Swift payment
method (PR 5672). PR 5672's i18n property value for key "payment.swift.info"
will be wrapped and appended to the comments of the Swift payment account's
json form.
We can cache an offer payload hash as soon as its `offerFeePaymentTxId`
is set. (The payload hash cannot be calculated until the object can
be transformed into a protobuf message, which requires a non-null
offerFeePaymentTxId.)
Another benefit is removal of the payload hash argument from the
`OfferBookListItem` constructor.
Changes include
- `OfferPayload` Added `transient byte[] hash` field + getter method
(where hash is calculated and cached).
- `OfferBookService` Removed `P2PDataStorage.ByteArray hashOfPayload`
parameter from `OfferBookChangedListener` listener methods
`onAdded` & `onRemoved`. (Hash is cached in `OfferPayload`.)
- `P2PDataStorage` Added null check to `ByteArray` class constructor.
- `OfferBook` Adjusted for change to `OfferBookChangedListener`.
Also removed redundant payload hash null checks.
- `TakeOfferDataModel` and `MarketAlerts` Adjusted for change to
`OfferBookChangedListener`.
- `OfferBookListItem` Removed overloaded constructor with
`@Nullable P2PDataStorage.ByteArray hashOfPayload` parameter.
(Field value is set from cached offer payload hash.)
- `OfferBookViewModelTest` and `OfferMaker` Adjusted test and test fixture:
do not attempt to create offer payloads without an `offerFeePaymentTxId`.
Checking offer payload hashes in OfferBook's onAdded and onRemove methods
is sufficient to prevent incorrect removal of offer list items from the
UI OfferBook view (where api 'editoffer' causes onRemoved to be called
after onAdded on peers).
Hash of protectedStorageEntry (should be offerPayload) was sometimes
resulting in incorrect hash being sent to OfferBook listener methods
onAdded(offer, hashOfPayload, sequenceNumber), and
onRemoved(offer, hashOfPayload, sequenceNumber).
Hash of OfferPayload is correctly passed to listener with this change.
Sending the correct hash allows removal of a dubious code block that
removed a book view list item when hash compare failed, and no matching
offer existed in the OfferBookService.
See https://github.com/bisq-network/bisq/pull/5659#discussion_r689634240
A newly created offer has no OpenOffer+State (AVAILABLE || DEACTIVATED)
when displayed in the CLI's console. This change adds a 'bool isMyPendingOffer'
to the OfferInfo proto + wrapper, and the CLI's console offer output formatter
uses it to determine if it should display a new offer's Enabled column value
as PENDING, instead of an ambiguous NO value.
Using the API's CLI to edit offers can sometimes result in add/remove messages
being received on peers in the same batch of envolopes, and these messages
are sometimes passed to the UI in (1) add, (2) remove order. This can result in
a newly edited offer being removed immediately after being added to the OfferBook
list. This change uses storage entry sequence number and storage entry payload
hash comparisons to avoid the problem.
- OfferBookListItem Added new constructor taking P2PDataStorage.ByteArray hashOfPayload,
and int sequenceNumber params. Added a new toString() method.
- OfferBook Added new checks on OfferBookListItem hashOfPayload and sequenceNumber while
determining if offer candidates should be added or removed from the UI's OfferBook List.
See OfferBook contructor's implementation of OfferBookChangedListener#onAdded and
OfferBookChangedListener#onRemoved. Added many comments explaining the add/remove rules,
and plenty of debug statements to help trace the add/remove event process.
- OfferBookService#OfferBookChangedListener Added new P2PDataStorage.ByteArray hashOfPayload,
and int sequenceNumber params to listener's onAdded and onRemoved method signatures.
Added these two new paramater values to listener.onAdded and listener.onRemoved calls.
- TakeOfferDataModel Replaced unused, old tradeManager param in offerBook.removeOffer()
with (null) P2PDataStorage.ByteArray hashOfPayload, and (-1) int sequenceNumber params.
OfferBook will remove the candidate offer as before.
- MarketAlerts Adjusted onAdded() & onRemoved listener method signatures, even though
new P2PDataStorage.ByteArray hashOfPayload, int sequenceNumber params are not used
by the implementations.
Double clicking the close ticketbutton creates two payout transactions.
This fix makes sure only one payout transaction is created for the
dispute.
Restarting the client allows for creating another refund transaction
for the dispute if needed.
Add it also before and after daoState monitor checks.
When letting the app run over night I saw that a lot of memory was not
released if System.gc() was not called.
By calling System.gc() it got to the expected state. Tested with the
G1 GC but saw similar behaviour with master with default GC version (parallel).
We could also run it periodically every 10 minutes or so, but I guess the block
interval covers that pretty good as well and those are the moment where load is
added and risk to run out of memory is higher.
We add a bit of delay to take into account that listeners might
react on the state change and to apply the gc after the event is processed completely.
- Run persistence call in thread instead of user thread (serialisation
is very slow and had blocked user thread)
- Create new snapshot only after persistence is completed to avoid to
have 3 daoState objects in memory
- Set DaoState in store to null to let gc remove the old reference (was
left there before so we had 3 instances of daoStates in memory)
Optionally displaying an ENABLED column in CLI side getoffer output
depends on the value of offer.isMyOffer, which is passed via new
boolean arguments to the trade & offer pojo builders.
- Add editOffer to GrpcOffersService, CoreApi, CoreOffersService.
- Set editOffer call rate meter to 1 / minute.
- Use new EditOfferValidator to verify editOffer params OK.
- Adust getMyOffer(s) rpc impl and OfferInfo model to use OpenOffer
for accessing activation state and trigger price.
This fix guarantees a callback if there is a pending request rather than just
dropping the fee request.
When requestFee() is called the callbacks are added to a list of callBacks.
Once the next fee request completes all callbacks in the list are called
and the list cleared.
Update the two new indices on every known write to the list, namely addBlock() and addBlocks(). Restrict ability to modify the blocks list outside of these methods by overwriting the getBlocks() getter such that it returns an unmodifiable list.
In the process of migrating the server to a new instance, my secret key
for the onion address seems to have become corrupted. Therefore, I
needed to generate a new onion address.
There have been 1 tx in cycle 17 and 2 txs in cycle 23 which have been confirmed outside of the phase.
The vote result had excluded it correctly but for the hash calculation for the blind vote monitor the
phase check was missing which results in an incorrect hash.
By fixing that the past hashes back to cycle 17 are all invalid. Once all seed nodes are running that
patch nodes should be in sync again. As it did not affect consensus but only the monitoring it is not
critical.
Move consecutive maybeAddSegwitKeychain(..) calls for the BTC & BSQ
wallets from BisqSetup to WalletsManager, as the latter class is used
for operations which should be applied to both wallets and this moves
the logic closer to the wallet domain.
Also migrate a BSQ address validator in one of the test mock classes
from Base58AddressValidator to BitcoinAddressValidator (missed earlier).
Uncomment & enable the m/44'/142'/1' native segwit BSQ account path and
add code to migrate the user's BSQ wallet to segwit upon startup, along
the same lines as the existing BTC wallet segwit migration logic. That
is, set P2WPKH as the default output type, add a native segwit key chain
(set to active) to the BSQ wallet and back up the old 'bisq_BSQ.wallet'
file to 'pre_segwit_bisq_BSQ.wallet.backup'.
Also filter out legacy addresses coming from the original keychain from
BsqWalletService.get(Unused|Change)Address.
Remove the restriction to base58 (P2SH & P2PKH) addresses when parsing,
formatting & validating BSQ addresses, by replacing o.b.c.LegacyAddress
with its superclass o.b.c.Address throughout. Also remove restriction to
LegacyAddress in BsqTxListItem and BsqTransfer(Service|Model).
The bech32 BSQ addresses follow the same format as the old base58 BSQ
addresses, namely 'B' + <btc-address>.
Use flatMap(Optional::stream) instead of filter(..isPresent).map(..get)
and avoid a redundantly nested Optional in OpReturnType.
Also replace some unnecessary stream().forEach(..) invocations on lists
in BtcWalletService, as forEach is already part of the List interface.
- Finished API server's verify bsq payment impl.
- Added verifybsqsenttoaddress method to CLI.
- Added verifybsqsenttoaddress-help.txt to server.
- Fixed client getoffers, getmyoffers to work with BSQ offers.
- Added bool tradeInstant field to proto message def.
- Adjusted core createcryptopaymentacct impl to new tradeInstant request param.
- Adjusted cli side createcryptopaymentacct impl to new tradeInstant request param.
- Fixed CliMain's takeoffer help text (was missing the --payment-account opt).
This change adds offer and trade contract detail to the API's Offer
and Trade protos, and improves CLI output formatting.
- Appended missing fields to OfferInfo proto message:
uint64 sellerSecurityDeposit = 20;
string offerFeePaymentTxId = 21;
uint64 txFee = 22;
uint64 makerFee = 23;
- Added new api proto messages ContractInfo and PaymentAccountPayloadInfo.
Lighterweight protos are needed because core Trade/Contract classes are
not visible to CLI.
- Appended ContractInfo field to api proto message TradeInfo.
- Added proto / model converters for ContractInfo and PaymentAccountPayloadInfo,
and adjusted OfferInfo & TradeInfo.
- Improved CLI output formatting. Added more trade detail to CLI's gettrade output,
and prepared to support BTC/BSQ trading pair. Note a reviewer is advised to
look at the CLI outout formatting class files instead getting bogged down in the
many commit changes.
This change supports creation of BSQ BLOCKCHAIN payment method accounts.
- Added proto message defs to grpc.proto.
- Added grpc server boilerplate to GrpcPaymentAccountsService.
- Added server impl to CoreApi, CorePaymentAccountsService.
- Added createcryptopaymentacct-help.txt.
- Added CLI side support for new api method.
- Added opt parsing unit tests to OptionParsersTest.
This is the 1st PR in a series, with the goal of supporting the BTC/BSQ trading
pair. Support for other crypto currency payment accounts will be added later.
