As the normal maps are not using a ConcurrentHashMap it is
likely unnecessary as well that I am not aware of a
multi-threaded access.
But as it does not show any difference in performance
it is likely the bit more safe option.
directly and we did not remove the item from the cache)
- Add getSignedWitnessMapValues method for access to signedWitnessMap values
- Remove Getter for signedWitnessMap
- Add removeSignedWitness method (used in test only)
- Use addToMap in test instead of direct access to map
- Remove getSignedWitnessSetCache entry matching
signedWitness.getHashAsByteArray() as well.
See comment. @sqrrm: Can you cross check?
The getSignedWitnessSet is called very often and is a bit
expensive. We cache the result in that map but we
remove the cache entry if we get a matching SignedWitness
added to the signedWitnessMap.
The accountAgeWitnessMap is very large (70k items) and
access is a bit expensive. We usually only access less
than 100 items, those who have offers online. So we
use a cache for a fast lookup and only if
not found there we use the accountAgeWitnessMap and
put then the new item into our cache.
Change the specific sign window to sign an imported account in the form
of accountAgeWitnessString,pubKeyString. The SignSpecificWitness never
worked due to missing pubKey data and this is a way to import the missing data.
Redesign the UI
Add import/export of payout settings
Add ability to import from mediation ticket
Mediator does not need private key
User can sign using own wallet or private key
Validation of input fields
Calculate the tx fee based on inputs
Display of the generated txid & hex so it can be checked
The delay was too long. Some users have 100 - 200
offers and with the 700 ms delay it takes 70-140 sec.
This causes more stress for the network and UI due
permanent adding of offers. We decreased delay to 30 ms per offer.
So with 200 offers it would be about 6 sec. Maybe we could reduce
it even further but as it is hard to test in the live network with
so many offers it is better to not be too radical with the change.
This change was prompted by the recent changes in the main branch to
allow a tx memo field to be set from the UI and API.
This and the prior PR address the API's need to be able to fetch a
tx (with a memo). The API can now get a completed trade's withdrawal
txid and pass it as a gettransaction parameter.
See previous PR "Append nullable withdrawalTxId field to Trade".
https://github.com/bisq-network/bisq/pull/4937
A summary of changes by file:
grpc.proto
- Added withdrawalTxId field to existing TradeInfo proto & wrapper.
- Reordered fields in TradeInfo proto.
- Added new fields to be displayed by TxInfo proto in CLI.
- Fixed typo: unsetTxFeeRatePreference -> UnsetTxFeeRatePreference.
- Added new GetTransaction rpc.
GrpcWalletsService - Added new getTransaction gRPC boilerplate.
CoreWalletsService - Added new getTransaction implementation.
TxInfo - Added the new fields for displaying a tx summary from CLI.
This is not intended to be more than a brief summary; a block explorer
or bitcoin-core client should be used to see the complete definition.
TradeInfo - Added the new withdrawalTxId field defined in grpc.proto.
CliMain - Added new 'case gettransaction'.
TransactionFormat - Formats a TxInfo sent from the server to CLI.
ColumnHeaderConstants - Added console headers used by TransactionFormat.
TradeFormat - Displays a completed trade's WithdrawalTxId if present.
Apitest - Adjusted affected tests: assert tx memo is persisted and
test gettransaction.
