Use BurningManService.getBtcFeeReceiverAddress at createFeeTx tasks.
Verify takers burningManSelectionHeight if BurningManService.isActivated at MakerProcessesInputsForDepositTxRequest and OpenOfferManager.
Stores burningManSelectionHeight in ProcessModel.
Add BurningManService fields to OfferAvailabilityModel, PlaceOfferModel, OpenOfferManager and Provider
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
We cannot add a new field as that would break DAO consensus.
Add optional text field for burningManReceiverAddress to CompensationProposal UI.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
We will use that for the optional address field in compensation requests and interpret empty input as Optional.empty.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Use onDaoStateBlockCreated instead of onDaoStateHashesChanged to avoid multiple calls when we receive hashes from other nodes.
Add daoStateMonitoringService listener after blockchain parsing is completed
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Some commits were missed from the first implementation in #6431.
The user limit is applied to offer entry via AccountAgeWitnessService.
Offers are filtered according to limits in OfferFilterService.
If limit changed, the cache in OfferFilterServices must be cleared.
Previously the BSQ fee payment was determined by parsing a raw tx
without relying on the DAO. Unfortunately this turned out to be
problematic, so with this change the BSQ fee paid is obtained from
the DAO tx, as originally preferred by chimp1984.
Unconfirmed transactions will not be able to have their BSQ fees
checked so early requests for validation will skip the fee check.
This is not a problem since maker fee validation is done by the
taker and in the majority of cases will be already confirmed; taker
fee validation is done after the first confirm at trade step 2.
More restrictive limits will still apply based on payment method.
It is intended to avoid that a new users who do not fully understand
the process of a Bisq trade to cause an arbitration case with high
amounts and therefore higher risks and costs for the DAO.
It seems that a reorgs or if a new block arrives quickly after another, that bitcoind is not ready
for a request and throws an RPC error, also the blockhandler throws that if the new block came too fast.
We try to request again with increasing delays up to 1 min. If after 10 attempts its still failing we
do a reorg and start parting again.
We repeat with a quadratically increasing delay 5 times, then we give up.
In the previous code we repeated forever which could be risky in case that
code branch is called unexpectedly.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Rename to expectedInitialDataResponses as we compare with numInitialDataResponses.
Add comment to make it more clear how its used.
Let the LiteNode increment only if getBlocks get called (e.g. blocks are missing).
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
It is allowed that there are change outputs, for instance if taker
does not take full trade amount, there is a change output for maker.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
