* this class is not a clock but it watches the clock, detects standby
and runs periodic tasks.
* there is already a jdk method called clock
First i thought it should be called PeriodicTaskManager, now i find
ClockWatcher more fitting.
- Add communication messages to Trade protobuf message to be able to
save chat messages per trade
- Add Type enum and field to DisputeCommunicationMessage protobuf to
be able to dispatch Dispute and Trade chat messages properly
- Rename some function as isClient instead of isTrader to make it easier
to understand who is who when two traders are communicating with each
other
There was missing the block notify port as well as the options have
not been applied correctly which led to the situation that when you
run the same application in full mode and later in lite mode that
data got persisted.
Added also to the footer a note if full mode is running.
When we request at startup the blocks from a seed which has not yet
received out capabilities or node address we will not get a response.
We do not want to depend on the state in the getData domain in the
p2p network by using only a seed which has already responded but we
prefer to make sure the seednode will get all the data by our request
to be able to respond.
- Check if conflicting node is seed node or not. Show info in list entry
and only show resync button and red color in text if conflict is with
seed node.
- At resync move all p2p network data to a dedicated directory so they
will be reloaded from the seeds.
We don't want to break consensus and persisted data at current
dao_regtest by removing the date now. It is not used anywhere so it is
irrelevant but would break things as the hash would be different and
persisted data would not be readable anymore. So we delay that change
to the mainnet launch.
In case of an invalid tx we burn all available BSQ input. We only know
that at parsing time. We renamed the burntFee field to burntBsq to make
it more generic and use it for the burnt fee in case if a normal tx and
as invalidatedBsq in case of an invalid tx.
We don't want to burn BSQ in cases like that the tx was published too
late, which is a valid case if the tx does not make it in the next block.
We set such txs as IRREGULAR and allow spending of the BSQ, but there
function in the governance is invalidated.
We also add a check if the sum of all UTXO is the same as the sum of the
genesis + sum of issuance txs - burned fees.
We can evaluate the nonBsqTxOutputs without storing it.
Storing them in the map would have required to remove them as well
once withdrawn from the wallet.
To avoid the need to change the required bond in the BondedRoleType
if the BSQ price changes we use the BONDED_ROLE_FACTOR param where the
factor can be changed. In the BondedRoleType we use the requiredBondUnit
which will be multiplied with the BONDED_ROLE_FACTOR value to get the
required bond amount.
In some tests it seemed that SHA3-256 is 30% fast than SHA256 but later
with the data we used in dao testnet it was actually slower.
To avoid confusion which hash function to use and to avoid mixing them
without strong reason I prefer to remove it again.
- Move dao state monitor classes to other package structure
- Add support for proposal payload monitor (WIP)
- Use generics and sub classes for common functionality
- Add hashChain to snapshot
- Use TreeMap instead of Map to have deterministic order
- Use eventCoordinator to make correct order of execution transparent
- Fix missing applying of nonBsqTxOutputMap at applySnapshot
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).
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.
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.
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.
- 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.
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
Currently, the download update task will download the deb package for
any Linux distribution. Not only is this incorrect, but now that we are
able to provide an rpm package (see #2200), the download update task
needs to be able to differentiate Linux distributions and provide
the appropriate package.
The download update task will now differentiate between Debian and
RedHat based distributions (the two distributions for which we have an
install package) and download the appropriate package.
In addition, the isSupportedOS method was changed to exclusively check
for Debian and RedHat based distributions, as opposed to just Linux in
general. This means that any other distribution will encounter the
following error, which seems appropriate:
> Unable to determine the correct installer. Please download and verify
manually at https://bisq.network/downloads
- 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).
