Split up into 4 service classes
- BurningManService: Common stuff
- BurningManInfoService: For displaying BurningMan data
- BtcFeeReceiverService: For getting btcFeeReceivers
- DelayedPayoutTxReceiverService: For getting delayedPayoutTxReceivers. This is the critical part where we need to have a deterministic data and which could break trade consensus.
WIP refactoring. More to come...
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Add getAverageDistributionPerCycle method to BurningManService.
Show receiver address when BM is selected.
Refactor code, cleanups, UI improvements.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Add burningManSelectionHeight and tradeTxFee in Dispute.
Call validateDonationAddressMatchesAnyPastParamValues and validateDonationAddress
only if legacy BM was used.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
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.
