This helps to avoid that the legacy BM would get the rest in case there are capped shares.
It still can be that a candidate exceeds the cap and by the adjustment becomes capped. We take that into account and the legacy BM would get some share in that case.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Left side is amount to burn to reach the max allowed receiver share based on the burned amount of all BM.
The right side is the amount to burn to reach the max allowed receiver share based the boosted max burn target.
Increase ISSUANCE_BOOST_FACTOR from 3 to 4.
Add help overlay to burn target table header.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
It is not included in BurningManCandidate candidate map as that would complicate things.
We only want to show it in the UI for informational purposes.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
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>
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>
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.
