Refactor dao state monitor domain.
Add support for requesting all hashed from genesis from a peer which is
in conflict (can help to find at which block the issue started).
Use addCoinsReceivedEventListener and addCoinsSentEventListener instead
of addTransactionConfidenceEventListener as
addTransactionConfidenceEventListener has much more overhead.
I could not reproduce anymore the balance issues I had when I used that
approach during development earlier.
At Capabilities I got an exception after going back from a new dev
branch to master and getting p2p network data from nodes still running
on the dev branch as that newly added capability was outside of the
existing scope.
I found another potential issue with DaoPhase.Phase and added a check
there as well.
Add parseBlockchainComplete check for onParseBlockChainComplete
before calling onParseBlockChainComplete to avoid duplicated calls of
onParseBlockChainComplete. Happened if there was only one seed node.
We create a chain of hashes of the dao state starting from the genesis
block height and using the previous hash in the hash. This ensures that
the history need to be correct if a particular hash at a block height is
correct. We request from seed nodes the last 10 hashes and broadcast to
our peers our hash at each new block. We build our list in memory and
listen on the new onSnapShotApplied event to start building our chain
from the genesis height up to the last snapshot block and after that
from each parsed block.
If we detect a mismatch we store it in a collection and the UI can show
a warning to the user.
We added also the onDaoStateChanged handler to the DaoStateListener.
This event is called after all parsing is completed and listeners have
completed their work. We must not use time based delays in the listener
code otherwise we would get changed our dao state after that event.
To detect such we added a assert method to throw an exception if the
dao state gets changed after the allowDaoStateChange is set to false.
We want to have a deterministic dao state. The PubKeyScript in the
TxOutput was the only optional field which was only set in the
dumpBlockchainData program argument was set as it was only required for
the json dump for the explorer. It has 50 bytes of data which is about
20% of the txOutput data size. We prefer atm to avoid additional
complexity which would be created if we would handle that optional
field (e.g. exclude from hash creation).
The property might be useful as well for other use cases in future.
trade history
We got some reports that the trade history was gone and it turned out
the removal of the deprecated payment methods caused an exception when
reading the persisted closed trades. So we have to keep that code to not
break old db files.
Florian reported that they consume quite a bit of performance.As
they have not been used for development testing since long we should
better remove those.
Use percentage based value of trade amount for buyer and seller
security deposit.
To ensure that the BTC value is not getting too low, we apply a min.
value for both.
- We get about 300 refresh msg / min. That causes quite a bit of load
for the network. I think it is safe to increase TTL from 7 to 9 minutes
and change REFRESH_INTERVAL from 5 to 6 min. and
REPUBLISH_INTERVAL from 30 to 40 min.
- Add program args: msgThrottlePerSec, msgThrottlePer10Sec,
sendMsgThrottleTrigger and sendMsgThrottleSleep
- Add ConnectionConfig class with static injected field in Connection
- Cleanups
We got reports that offers got removed and re-added even if the maker
had good network connections. Seems the network did not propagate the
refresh msg in time or get too crowded. Increasing the TTl should help
to make those cases more rare. To decrease the refresh rate from 5 min
to 4 min. might be more risky as it would create much more traffic.
- We had it initially at 60 sec. and increased it as attempt to fight
those timeout errors, but it did not help. So letting the user wait
longer as needed does not make sense.
- To ensure the balance is updated in case we have a comp. request we
need to ensure that the vote result is completed before our balance
update is called.
- Remove updateBsqWalletTransactions call at constructor as nothing is
ready anyway here
- Refactor: Rename addBsqStateListener to addDaoStateListener
and removeBsqStateListener to removeDaoStateListener
- Add LiveAsset account, payment method, AccountPayload
- Extract super classes for normal CryptoCurrenyAccount and payload and
LiveAssetAccount and payload
- Add isAsset method
- Add button for creating a live asset account
As it is a bit tricky to use the AccountForm for both methods and add a
checkbox there so defined which payment method to use I added a button
to add an AccountForm with the LiveAssets passed. This is just
temporary to be able to test a bit more and see if there are any
critical issues. We should unify that form but that might require a bit
of refactoring of the CryptoCurrencyForm.
To avoid the issue with lost taker fees if the take-offer attempt fails,
we delay the publishing of the taker fee tx just before the deposit tx
gets published.
The taker fee tx must not be committed to the wallet to avoid that the
wallet would require a resync in case the tx is not published.
If the tx is not committed the addresses used there are not considered
as used and that would cause issues with the address entry context
assignment for the deposit tx. To avoid those issues we need to force
the creation of new addresses used for the multisig and payout address
entries. To be sure that happens before any of the following tasks make
use of those address entries we do that already in the createTakerFee
task.
For BSQ fee tx it behaves similar but needs separate testing.
- Changed display string from "lockup time" to "unlock time"
otherwise it may be confused with how long it takes to lock
up the bond.
- Included estimated time duration (e.g. days) for the unlock time.
When creating a BSQ transaction (actually at commit time as we can create a tx and then
cancel it in the confirmation popup) we store the change output (only that not the other
possible BSQ output) in a persisted list. The BsqCoinSelector will take that list to
allow spending those coins. We use the txType to find the index of the cahnge output.
We only have one change output in the transactions created in Bisq. Multiple change
outputs would be valid but our goal is only increased usability in the Bisq app and it is
not related to validation rules.
We update out list at each new block confirmation.
With that approach we avoid too much dependencies to the BitcoinJ side.
- Add UnconfirmedBsqChangeOutputListService and persisted UnconfirmedBsqChangeOutputList
for storing unconfirmed outputs
- Add lookup for unconfirmed BSQ change outputs at BsqCoinSelector and allow spending if
found
- Pass TxType for walletsManager.publishAndCommitBsqTx calls
- Add TxType to bsqWalletService.commitTx
- Refactor getPreparedSendTx methods for BSQ and BTC sending to one common method with a
coinselector parameter.
- Add getChangeAddress method to BsqWalletService to make change outputs more explicit
- Add unconfirmedChangeBalance to onUpdateBalances handlers
- Rename availableBalance to availableConfirmedBalance in onUpdateBalances
- Unify onUpdateBalances parameter names
Official project URL: https://qwertycoin.org
Official block explorer URL: https://explorer.qwertycoin.org
Included is a pop up message to let QWC senders know what is required of them in the event a trade goes to arbitration.
- As teh network is used for filtering asset types BSQ has 3 asset
types, one per network we need to use REGTEST as network. The methods
for checking which BaseCurrencyNetwork are using name() now instead of
network as we have 2 times REGTEST.
- Fix bug with not calling showFeeInfoAndPublishMyProposal for bonded
role proposals.
Use the defined unlock time on mainnet, an arbitrarily low value on
regtest for dev testing, and a relatively short time on testnet for
testing purposes.
- Set BTC_DAO_TESTNET as last enum to not break existing regtest port
convention which is derived from enum order
- Remove BaseCurrencyNetwork.isBitcoin as always true
-
- Make all PaymentMethod constructors private
- Use PaymentMethod.getPaymentMethodById in Offer for getting the
PaymentMethod. This change a bit the context as now we always create the
PaymentMethod from the actual code base in contrast to the data which
have been used when creating the offer. As our fields as final and must
not change in software updates it should have no issues but we have to
keep that in mind to not alter the default values.
- Added a runtimeException in case the maxTradeLimit does not match one
of our default values.
- Use PaymentMethod.getDummyPaymentMethod(GUIUtil.SHOW_ALL_FLAG)
instead of new PaymentMethod(GUIUtil.SHOW_ALL_FLAG))
- We had an automate remove accounts for those payment methods for long
time, so we can assume that no traders have any of those accounts still
in their persisted user objects and it is safe to completely remove them.
Only part where we cannot remove it is the PB definitions (actually I
think we could remove those as well, but not 100% sure and it seems to
be more safe to mark those as deprecated and leave the entries).
- Assign paymentMethods in static final field
- Add static fields for default trade limits
- Remove deprecated payment methods
- Remove onAllServicesInitialized and use static initializer instead
- Re-purpose maxTradeLimit for indicating risk factor
- Calculate real trade limit in the getMaxTradeLimitAsCoin method
- Rename getActivePaymentMethods to getPaymentMethods
- Set max trade limit to 2 BTC (for altcoins)
- Add MAX_TRADE_LIMIT to Param
- Round first month trade limit to ensure we stick with precision 4 for
the btc amount
- Use risk factors to derive trade limits for different payment method
risk categories
Issue: If an IOException is raised when attempting to create
tor and the hidden service, the application will just quit without
any indication to the user. One particular scenario where this occurs
is mentioned in https://github.com/bisq-network/bisq/issues/2398.
Cause: There is an explicit statement to exit the application when an
IOException is raised.
Fix: Rather than just exit the application, show an error message
and inform the user what went wrong.
To avoid empty handlers I have set all methods to default so the client
code implements only the used one.
Move handler code from onNewBlockHeight to
onParseTxsCompleteAfterBatchProcessing to avoid too much UI updates
while parsing.
- If a proposal had a tx which is not in our BSQ state it was not removed
- If a tx was outdated (> 60 days old) it was only removed if we are
in proposal phase. We added check for past cycle to cover those as well.
We need to add any valid vote reveal tx / blind vote tx pair for the
majority hash calculation even if the blind vote payload is missing as
that could be relevant for the majority hash calculation. We add an
empty ballotList and meritList in such cases.
In case that the users blind vote list does not match the hash of the
majority we want to find if any variation of our list leads to a match
so we can still calculate the vote result.
This allows for a tor .onion address to be specified as the
bitcoinRegtestHost parameter and, as long as the --useTorForBtc=true
parameter is included, it will use tor when on regtest.
We get sometimes Tor startup problems which is related to some tor
files in the tor directory. It happens more often if the application
got killed (not graceful shutdown).
Creating all tor files newly takes about 3-4 sec. longer and it does
not benefit from cache files.
TODO: We should fix those startup problems in the netlayer library,
once fixed there we can remove that call at the
Bisq startup again.
If a updated client makes a param change request old client do not
recognize that enum. To avoid exceptions ro null pointers we fall back
to the UNDEFINED enum entry if available. As param value we show an empty
string.
Beside that issue no problems have been found so far with adding a new
param entry.
