The date check would not add real protection as the attacker could just
use a new date and we do not cross check the date with the tx date.
We could do that but it would add complexity and we have another
strategy which does not require that.
When attempting to submit a compensation request or reimbursement
request with insufficient BTC, the warning message only indicated that
BTC is required for mining fees. It did not indicate that BTC is also
required for the BSQ issuance.
So another display string was added and displayed when submitting an
issuance proposal with insufficient BTC funds available.
When submitting a proposal with insufficient BSQ balance, the warning
message showed an incorrect required BSQ amount. The amount needed to be
divided by 100 (1 BSQ = 100 satoshis).
Fixes https://github.com/bisq-network/bisq/issues/2613
If the user has the exact fee in his wallet no BSQ change output would
be created but that violates our requirement for compensation or
reimbursement txs.
Beside that the error message for dust outputs was not clear.
- It is more safe to separate the BTC_DAO_TESTNET and BTC_DAO_REGTEST
by the network ID as that prevents on the P2P network layer that the
network could interconnect. We would have risked that we receive network
data from the other network as users would use the persisted peers for
connections.
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.
When using onParseBlockChainComplete and
onParseBlockCompleteAfterBatchProcessing the
onParseBlockCompleteAfterBatchProcessing is called earlier as
onParseBlockChainComplete which caused incorrect state update in the UI.
- We add a filter to the getMeritStake method to avoid an exception at
getWeightedMeritAmount which would set merits to 0 in case the issuance
height blind would be larger than the vote height. I saw that error log
but could not reproduce it afterwards. It basically protects that we do
not add the issuance of the current cycle to the merit used in the
blind vote of that cycle.
- We add 1 block in the getCurrentlyAvailableMerit method to get the
same merit value if the blind vote was included in the next block.
