Distribute Burningman role to contributors who burned BSQ #390
Comments
I don't know if it's good to have a hard limit. What happens when this limit is broken, especially when multiple burns happen in the same block?
This could be rather inconvenient as time goes by. Maybe allowing for exporting the keys associated with the issuance would help older contributors. Although that could be done at any time and not related to the core of this proposal.
This makes it harder for the reimbursed traders to liquidate their BSQ. Overall I like this proposal. A consideration to keep in mind is that old and perhaps inactive contributors will have a larger share of the allotted burn as time goes. This might result in not enough BSQ being burnt if active BSQ holders aren't allowed to burn enough. |
Yes I am also not so sure about that part. Maybe the estimated BTC fee amount is enough for flexibility. If we want to allow more burn we could increase that value by DAO voting.
We would get a negative burn target, which is not a problem. Nobody can burn anything anymore until new reimbursement enter and with a new cycle the new fee estimation cuts in. For that cycle the burners will likely not make profit but when next cycle there are less burners it should level out.
Yes can be improved. But one can use anyway the normal Proof of burn as well. The allowed burn amount is shown in the table.
Yes true, as well as for the refund agent. That's why we should try to reduce the reimbursement requests from traders by getting rid of the large amount arbitration cases the RA cannot take. The extra work for the RA need to be compensated by higher payment. So there will be more costs for the DAO likely. By not giving the peers security deposit to the peer, though the DAO should get compensated by those extra costs.
Ah good point. If we would change the decay function to go to zero after some time we could avoid that. The genesis receivers still could get a static decay but that will not grow. So what about keeping the 10% for genesis receivers but decaying normal contribution requests over 2 years to 0 (now 1 year to 10%)? Beside the reasons given here there might be not so much argument why genesis receivers should get a preferred treatment compared to old contributions. But an argument could be that those took much more risks as it was not guaranteed that the DAO will ever come to life. Normal contributors got already compensated with BSQ for their work. |
|
Pardon my interruption. You say the BSQ model is not working for current contributors. Could you explain why that mode is not functioning? I understand wanting to get BTC from the trade fees. Can you sum up the action in the BSQ market? Has burningman been able to retrieve his funds? Does burningman have shit-tonnes of BSQ and cannot sell, or, what's the deal? How does this determine the fate and/or value of BSQ token? |
So, if it gets negative no more burningmen will be able to burn BSQ until next cycle? What if there's a sudden spike in Bisq trading volume? Isn't a little more flexibility needed in this case? On the other hand, if there's a sudden drop in trading volume, burned BSQ can't be unburned, so I guess that, specially considering that burned BSQ are valid for a year, market will have to adjust to volatility and remind that there will be good and bad cycles, but I still wonder if a bigger burn target or a formula that adds more weight to last cycles is desired.
Per year or per cycle? I don't like increasing the complexity of removing the burningman, but I wonder if donating a % to a project (i.e. Tor) would reduce the Gain from DPT payouts risk. @clearwater-trust BSQ model is not working because Bisq does not attract experienced developers, and one reason might be that being paid in BSQ is not very attractive. As an example, Bisq had to use a middle-contributor to pay in BTC to develop segwit. Burningman burns BSQ after selling BTC he got from trading fees and donations from delayed payout transactions. Getting rid of this single point of failure is the main goal of this proposal. |
|
I like this proposal. I think it aligns both contributors, burning men and BSQ holders incentives. In summary if BSQ increases it's fees in BTC terms year over year contributors, burning men and BSQ holders will all benefit.
I think the target amount of BSQ to be burned for given period should be as follows. BSQ reimbursements approved for Refund Agent + BSQ reimbursements approved for traders + (BTC trade fees ÷ Average BSQ/BTC price). To make this target dynamic you could then minus the Burned BSQ from the burningmen. Doing it this way means the BSQ amounts would be exact and it does not need to take into account legacy Burnt BSQ from the Burning Man. This would be:
I am assuming that the burn target can also go into the negative. This would happen when participation is oversubscribed, it would also make economic sense when there is more competition for BTC payouts in situations for example where trade volume have shot up for some reason. Would be nice if there was an easy way for all contributors to see the history of the:
This knowledge all being in one place, eg Bisq DAO section, would make it easier for users to choose whether or not to burn. Expanding on this it might be useful for contributors to be given the following information: Burn share x ((12 months past DPT) + (12 month past BTC trade fees)) = expected BTC return. This would be dynamic, and not forward looking, but maybe still nice to have a benchmark. Also, might be good to show the total of current accumulated payouts for all active and past participators of each burn amount? I am thinking it would be good for this to be transparent but maybe others would disagree.
I would worry that (BSQ compensation x 2) decaying over a year to zero + 10% of genesis BSQ issuance would require too high a participation percentage to achieve the Burn Target. For example the sum of BSQ reimbursements alone would be a multiple of total contributor compensation. Also might be good for contributors to be able to speculatively buy BSQ on the market with the intention to become a burning man. The proposal seems to imply this would only be possible for contributors that have been active in the last 12 months or receivers of the genesis output. Could contributors BSQ compensation instead be decayed over time to 10% rather than zero? This would allow past contributors to also contribute.
I think this will allow the measurement of participation as a percentage of issuance shares. I suppose as long as the burn target is reached it is not too much of a problem but if it was not reached knowing what percentage participation was would be useful. It could also be a target to achieve to maintain as much decentralization as possible.
I agree, it does seem a shame not to compensate traders that have been inconvenienced, but for this protocol to be secure, I do not see how it would be possible to refund the entirety of the non responsive peers security deposit.
Yes, this is how see it would work. I think this aspect adds healthy compensation for inclusion and will increase participation. I agree there should be no hard limit.
From the proposal I think all BTC output addresses should be known. So it will be a bit more work but as long as they are all know should not be an issue. Will also need a way to measure the additional BSQ burn as a result of users participating in the burning man. Could this be added to the DAO stats? |
I think letting people burn at any point regardless of if the target has been reached or not makes sense. Sometimes it will make economic sense to burn when the target has been achieved.
This is one of the reasons when I think it is best to use BSQ reimbursement rather than BTC reimbursed for the Burn Target. It will track 'costs' better. Same can be said for reimbursed BSQ traders. Maybe if it was difficult to sell the BSQ on the open market they can be given percentage or two more and the costs would be reflected.
Maybe decay it to 5% or another fixed amount. I think it would be good to keep the option for Burning Men to be buyers of BSQ to actively burn to address the above concerns about lower BSQ/BTC liquidity for RA, reimbursed traders and contributors. |
|
@MwithM
The genesis outputs would stay static at 10%. Only old contribution requests get decays over time to 0.
That was discussed also many times, but it still come with the risk that someone who want to give such a donation receiver a favor could take all sell offers and lete them fail to boost the donations to e.g. Tor. Also it might have legal implications if they receive BTC from a trade platform without their consent. And it would still be hard for Bisq to recover reimbursements only by trade fees. A trade fee increase by 30-50% would be required in that case. @pazza83
Yes, exactly.
Yes it would be nice to have the received amounts visible. But I have not found a way how to get that data. There will be many receivers and we do not separate it by addresses (the same address gets both DPT, BTC fees). To require the user to add 2 addresses would work but we need to support also those who have not setup an address and genesis outputs, there we derive the address from the tx data. A tool picking up all addresses and their inputs and detecting what king of input it was would be possible. But that would come with heavy block explorer requests...
Yes I guess that can be added to the table.
I fear thats like above out of scope as we cannot request 1000s of tx data from explorere in every Bisq app.
That was planned initially but @sqrrm pointed out a problem that over a longer period in the future the relative share of the active contributors who can be assumed that the more likely partizipate would shrink and then we would need to adjust parameters over time which would break consensus. Currently all is deterministic and based on DAO data. This allows verification in the trade protocol for the DPT distribution. Changing later parameters will be tricky. So we also need to be careful to choose the parameters right. The BTC fee estimation via DAO parameter voting is a good option to fine tune burn target if needed. So if real BTC fee estimation is 50k BSQ but for some reason we want to shrink or increase the target we can vote on a lower or higher amount to adjust the overall target.
Yes good point. Some of the current DAO charts might become irrelevant and it would be good to add new data then. Once I have the implementation completed I will play around more with different parameters to see how it behaves. |
Maybe the fallback should be to burn the BTC instead of having a controlled address. If it's really unlikely to happen it would just be a security issue to keep it. Main risk is that there is a bug or something causing a lot of burnt coin. |
Yes was thinking about it as well, but it would introduce more code changes as BTC burning should be done via opReturn and that would change tx creation. We could send it to an unspendable address as well but if there is a bug and we would get larger amounts burnt that way it might be very painful. On the other hand if the default address holder gets hacked and we have some vulnerability for the validation its painful as well. But I think only the self-trade and DAO reimbursement attack scenario is risky here as otherwise the peer would detect the fraud at take offer time. And for that case the arbitrator should also have some attention for such cases where the funds go to the default BM. We also will add transaction chain verification and we can add a warning in case there is a payment to the default BM as in reality it will not be expected. I guess the latter carries less risk at the end. And we can also not use the default value from the DAO param but the latest voted param entry and then change the BM receiver address to an unspendable address to achieve the same but without code change and more flexibility. |
|
Got some small improvements:
|
|
We should fight against making this system ANY MORE convoluted, complicated. Contributors need to understand HOW they are going to get paid, without reading through a million page wiki to see how the funds are allocated. Spell it out in simple terms for THE DAO's sake/stake. Also, be it known. We must understand how to make decentralized exchange a living, breathing, fact; else we get destroyed by CENTRAL WORLD BANK of DAMNATION and ETERNAL SLAVERY, Digital ID, KYC contact tracing, vaccine passport, MOTB carbon tax 666, fundamental element for all life on earth is carbon. Wake up. |
Contributors get paid in BSQ as now. Nothing changed. The only change is that any contributor can become a burningman if they want. |
Can you explain what would cause the instability if the allocated amounts to burn continued to grow over time? If the contributors are decayed to zero over a year I still think participation would need to be high to achieve the burn target. I think requiring high participation is a risk in itself. |
Assumption is that past contributors are less likely to be active and to partizipate in burning. But if their weight stays there forever the remaining share of the newer contributors gets lower over time and would lead to a point where the active contributors cannot burn enough to cover the burn target, thus creating inflation for the DAO. Easiest to understand if one tries out a simple example. Assume there are every year new 10 contributors each earning 1000 BSQ / month. Lets move to year 2: If we would go on, the tendency continues and new contributors weight goes lower and lower in an asymptote curve to zero (12k/∞). So that would create problems that the issuance weight used for deriving the allowed amount to burn would shrink over time for active contributors and at some point might not be enough to cover the burn target. If we cap the past contributions we escape that dynamic. The genesis amounts are a static value so it does not impact. |
|
Here are the current parameters I use. They might change and I will keep it updated here. The most important ones are:
|
|
Here the distribution with the current parameters (5% for genesis outputs):
|
|
I reduced genesis factor to 5%. I think that gives it a better balance. The weight for the total genesis outputs is 3.6M * 0.05 = 180k The average compensation request of the past 2 years was 30k/month. So the relation of genesis weight to contributor weight is 1:2. With 10% for genesis it would be 1:1. Not sure whats the better value here... But it feels that giving active contributors more relative weight is better for the project. |
|
Here the distribution with 10% for genesis outputs: |
|
For BTC fees the 1/100 of a percent will be the min. So if the burn share is 0.0099 % it will get ignored. 0.01% is the min. value. |
I understand there is not a blind process involved, so maybe the GUI could warn if/when the burned amount would be/become ignored, so the potential burner can decide whether to increase/add to the burned amount or desist altogether... while for the minimum payout, I guess that would be more of a game of chance. I'll need to get a clear picture to decide if becoming a BM would make sense for me, or not |
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
|
I added a new parameter for the max limit for the distribution share of 11%. This value is derived from the min. security deposit in a trade and ensures that an attack where a BM would take all sell offers cannot be economically profitable as they would lose their deposit and cannot gain more than 11% of the DPT payout. As the total amount in a trade is 2 times that deposit plus the trade amount the limiting factor here is 11% (0.15 / 1.3). |
|
I was working on the burn target calculations and display. It is a bit tricky so I want to share here the info to those who are interested or want to help testing. There is a recommended burn target and a max. burn target. Both the overall total and for individual BMs. Overall total:The recommended burn target is the sum of all reimbursements and BTC fee estimations of the past 12 cycles minus all burned BSQ 12 cycles back from the current block. Reimbursements are counted at the vote result block. We go back from there 12 cycles. The burn BSQ txs are counted from the current block back 12 cycles. They include the legacy BM BTC fees and DPT as well as new BM burn txs. The burn target can change at any block but usually gets a larger change at vote result block when new reimbursments come in and the oldes drops out of our time period frame and at the first block of a cycle when BTC fee estimations (from param change) get activated (param changes gets activated at next cycle after vote). There is a boost amount for the burn amount of 100k BSQ for more flexibility. This can be helpful for instance if there was a failed cycle and allows burners to burn more as the target suggests to avoid bigger fluctuations in profit/losses and burn events. It can also be used when there have been more as expected DPT payouts, which will get accounted for once the reimbursements happen in 1-2 cycles later. To soften those differences the burners could choose that they burn more when the DPT happen to lower the profits and do not need to burn that much once the reimbursements happen to loser the otherwise potential loss. All that is not required but gives flexibility for informed partizipants to flatten the spikes. Long term those spikes should also cancel itself out. In the below screenshot the overall burn target is: 12* 10k = 120k BSQ and 12* 10k + 10k for the max. burn target (using 100k as boost amount and 10k as estimated BTC fees, 12 cycles as period). No reimbursements and burn txs have occurred here. Burn targets of individual BM:To calculate the burn target of individual BM we use also a recommended value and a max. value. The max burn target is the max overall burn target (130k) multiplied by the boosted issuance share which is in our case here 2 times the issuance share. In the below screenshot it is: 130k * 0.11= 14.3k BSQ (again capped by the 11%). The BM can burn any amount above dust (5.46 BSQ) up to the max. burn amount.
So far it has been rather trivial. Now what happens when one starts to burn. Any amount (min. 5.46) will lead that the first burner gets all of the distribution up to their cap of 2 times the issuance share. Here Co-founder-1 has burned 1000 BSQ.
He would get 100% of the distribution, but it got capped of 11%. The remaining 89% from the DPT will go to legacy BM. For BTC fees we do not fill up with the legacy BM at the moment, but I consider to change that to use the same model to make it more consistent and make further accounting easier. Now let Co-founder-0 burn the recommened amount of 123.6 BSQ.
We can see now that Co-founder-0 reached a bit more than 11%. This is because with the next block the decayed burn amounts change and the previous calculation how much to burn to reach 11% is not exact anymore. We ignore that slight imprecision as it would be rather tricky to get the perfect and also conceptually impossible as we do not know if others burn as well at the same block. The over-burn will decrease usually at next blocks when the distribution from decay changes. Now as both have reached their max burn share of 11% they cannot burn more. We add Alice as contributor and let her get issued request 5000 BSQ from a compensation request.
She has a lower issuance share of 3.85% so thats more interesting for doing the calculations. We calculate that by using that method:
0.0385/(1-0.0385)*973.13= 38.96 (I used here rounded values so its not exact as the calculation in the app using exact double values). Let here burn the recommended 38.93 BSQ:
As we see her burn rate is very close to the intended 3.85%. Again the difference is due to the changes of distribution and shared with the decays at the new block. She sees now 0-41.27 BSQ as her range for burning. The 0 means that she reached her recommended share which is the issuance share. She can now burn more to boost her burn share up to the double of the issuance share.
After she done that, we see she reached her max burn rate of 7.64% (her issuance rate got adjusted due the decay so it has changed to earlier blocks). I hope that helps to understand the dynamics a bit better. As its a changing system with each new block its inherently complex. But the UI should give the BM enough help to manage the complexity. When we start it has to be expected that not enough BSQ gets burned to cover the overal target as BM will reach their limits with lower amounts to burn. But the more BSQ got burned the more those limits will get adjusted to allow higher amounts to burn. If the first BM will over-burn a large amount that process will get shortcut. But it might be a bit of a confusing phase until some stability in the process has been reached. I will add also the legacy BM to the table and change the BTC fee distribution to the same model as the DPT distribution. After that i will add some accounting features to see how much each BM has earned in BTC. PS: For anyone testing themself with regtest it is recommended to create 12 cycles of blocks (12*13) to avoid complexitities from dealing with the floor of the genesis block. Should work also but makes it harder to follow whats going on and for live we do not have to deal with that edge case anyway, so not much extra value for testing purposes. |
|
I added the legacy burningman: |
|
This proposal was approved in Cycle 41. |
|
Got the accounting support now implemented. Here the detail view, showing each transaction:
And the monthly summary view: The BSQ price is using the 30 day average of the past month. Technically it works a bit similar like the DAO blockchain data. I will make a extra pull request the next days. |
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… balance. This can be used for providing proof of ownership of a genesis output when attaching a custom BM receiver address. See: bisq-network/proposals#390 (comment) Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
|
💩 |
and others
Summary
We distribute the BTC trade fees and the funds from the delayed payout transactions to a group of burningmen and use the burned amounts for the distribution model.
The received BTC to burningmen should be the same value as the burned BSQ by the burningmen, so for the DAO it should be the same as with the legacy BM.
Only contributors and receivers of the genesis distribution can become a burningman.
The amount of earned BSQ will be used to determine the max. amount they can burn.
We calculate the target amount to be burned from all the reimbursement payments of the past 12 cycles and the estimated BTC trade fees in that period minus the burned BSQ from Burningmen.
The amount a Burningman can burn is derived from that burn target and from the Burningmans share of earned BSQ. The burned amounts will decay over a period of 2 years to zero.
Theres is a dedicated UI which shows all the relevant data.
Goals
The main goal is to remove the role fo the legacy burningman.
A secondary goal is to create better incentives for contributors to work on Bisq.
A tertiary goal is to make the BSQ market more natural by removing the BM as "market maker".
Overview
Burningman candidates
Any contributor who has made a contribution request or has received funds from the genesis transaction is a burningman candidate.
The earned BSQ by compensation requests will be accumulated and a decay function with the contribution age gets applied. The decay function is linearily going to zero when the age of the compensation requests reaches 1 year.
Earned BSQ from the genesis output will get reduced to 10% of its original amount.
From that decayed issuance amounts we calculate the issuance share by division with the total accumulated decayed issuances of all candidates (issuance share is in the range of 0-100%). [1]
Burn target
The target amount which should be burned is calculated from:
burnTarget = sumReimbursements + sumEstimatedBtcFees - legacyBurningmanBurndedBSq - burningmenBurndedBSqA positive result means there need to be burned more BSQ.
Burn BSQ
The max. amount to burn per contributor is calculated from the issuance share multiplied with the burn target. We allow a
issuance boost factorof2, so the contributor can burn double that value. This is done as it is expected that not all contributors will partizipate.Additionally we add a
boost burn target amountof100 000 BSQto the burn target to give more flexibility. [3]The burned amount will decay over 1 year [4]. The burn share of the contributor is the sum of all decayed burn amounts of 1 year in relation to all other BM.
If the contributor has either funds from genesis output(s) in their wallet or if they had made a compensation request with that application the UI will display the available contributor names in a combobox.
When a combobox entry is selected the max. allowed burn amount for that contributor is displayed. It is not possible to burn higher amounts. As genesis outputs are not assigned to a contributor we use "Co-founder-x" as name, where x is the output index. [5]
Burn share
All the contributors who have burned BSQ in the past year are taken into account for calculating the receiver share. It accumulates the burned BSQ with a decay function over 1 year and calculates the relative share to others.
This share will be used for the BTC fee payment selection and the delayed payout fund distribution.
Any burned BSQ older than 1 year will have no effect.
Receiver address
If the contributor has made compensation request with the new UI they can add a custom receiver address. It is recommended to use Bitcoin core wallet as there can be many BTC fee transactions and the Bisq wallet does not handle very well high numbers of transactions.
If this is not use (old compensation requests) we use the address used to fund the the first input of the compensation request tx, which is a BSQ address. The contributor will receive then BTC at their BSW wallet and can transfer it to any BTC wallet. If the genesis tx output is used the output address is used as receiver address. Also here the contributor will receives BTC at their BSW wallet.
Distribution of BTC trade fees
The BTC trade fee is distributed using a random number generator to pick one burningman candidate using their relative share as probability for the selection. [6] E.g. A 5% burn share gives 5% chance to receive the trade fees.
Delayed payout transaction (DPT) outputs
The spendable output of a DPT is distributed to all burningmen according to their burn share. E.g. A 5% burn share gives 5% of the spendable output of a DPT.
Both traders need to have exactly the same distribution as they verify the DPT in the trade protocol. To ensure that, we exchange at take offer time a "safe" block height to be used for calculating the data models, so both traders will use the same height even one trader might have received already a new block. [7]
Risks
Gain from DPT payouts
If there are very few partizipants they could get more than 15% of the DPT which would open a risk to take sell offers and let them fail to receive the output. If the burned BSQ was low due low partizipation of others that could lead to a profit to the attacker.
To avoid that we limit the burn share used for the DPT and BTC fees to the double of the issuance share. A partizipant who has an issuance share of 3% and would have gained a burn share of e.g. 30% will get capped their burn share to 6%. If that happens at a DPT we add the default BM as output receiver and apply the open spendable funds to that output. This would make that attack only possible for partizipants with more than 7.5% issuance share, which is a rather high bar and it can be assumed that such contributors have long term incentives in Bisq to not engage in such an attack.
We should not pay the winner in an arbitration case the peers security deposit anymore as otherwise the above described risk cannot be off-set by the 15% security deposit. See #386
One variation if that attack is that the trader makes a self trade being both parts of the trade and having manipulated the code to receive 100% of the DPT. We need to verify at arbitration that the distribution is correct. Otherwise they could manage to get refunded all the funds excluding only 15%.
Trade protocol issues
If there are implementation bugs with the DPT receiver selection it can lead to failed trades.
DAO consensus issues
The repurposing of a DAO parameter carries a theoretical risk for DAO consensus bugs, but I cannot see any real risk here. But we should test carefully.
Deployment
As this comes with changes in the trade protocol we need to deploy it with an activation date set to about 3 weeks after release date. Then after about 2 weeks we should enforce update to the latest version for traders via the filter. And then when activation date cuts in, the new protocol will be used.
The DAO will be mandatory for all users (remove feature to deactivate the DAO). There will be a separate PR for that covers that.
We should also consider to not allow new users to trade above a certain amount to avoid arbitration cases with high amounts. This can be done in the UI without requiring validation of peers. This is covered by an independent PR. This can be done at later releases to reduce risks.
Market impacts
The burningmen form a market for competing to receive the BTC fees and DPT funds. If they would burn too much they would suffer a loss. But as we use 1 year as time frame an initial loss can be compensated in follow up months when less BSQ get burned (BM who burned too much likely will not repeat that if it was not profitable). If not enough BSQ gets burned the partizipants will make some good profit which should attract other contributors to join.
There should be a slight profit over longer time and that might result in higher costs for the DAO compared to the legacy BM.
Contributors who participate in burning will sell less BSQ on the market as they have an alternative way how to convert their BSQ to BTC. This should compensate for the removal of the legacy BM as BSQ buyer.
Selling larger amounts of BSQ will be harder as traders will be the main buyers and they usually buy smaller amounts.
BSQ stakeholders who are not contributors or genesis output receivers might find it harder to sell larger amounts of BSQ.
We could try to increase BSQ trade fee share by increasing BTC fees so that the discount gets larger and motivates more traders to use BSQ.
At the vote result block new reimbursements gets added and thus the burn amount gets increased. There might be a race between BM to be the first to appreciate from the new increased target. If many would burn at the same block it could lead to over-burn as the data only gets updated at new blocks.
I guess it is unlikely that this happens to a large scale to cause distortions. In the worst case that cycle might be less profitable and next cycle there will get burned less and the revenue should balance out again.
As receiving BTC instead of BSQ might be attractive to some contributors and as more recent contributors get preferred weighting it should help to attract more contributors, which shoud lead to overall improvements and with that increased revenue.
UI
Burningmen candidates and reimbursement requests:
Burn transactions and issuances:
Compensation request has additional field for receiver address:
Details
[1] As discussed in #390 (comment) we decay old compensation requests to 0 but we keep genesis outputs at a static 10% reduction. The decay to 0 avoids that the share of past contributions will be an ever growing amount but it can be expected that many of those will not be active in burning, so the available share for active burners would decrease long term. The motivation to leave genesis outputs at 10% is because those who worked for Bisq before the DAO was implemneted took more risk and did not get compensated at the time when their contribution was made.
[2] The estimated BTC trade fee per cycle will be set by the average BTC fees of the past year. It can be adjusted by DAO voting by re-purposing a non-used parameter. That way the value can be adjusted to the BTC trade fee of the past cycle. To audit the BTC fees will become a bit more complicated now as there is not only one know fee receiver but we have now multiple receiver addresses and the received funds are mixed with DPT. From blockchain data though it is possible to derive the BTC fees with a high confidence. A dedicated tool for that task could be developed. A more simple method would be to use the trade volume and estimate the % share of BTC fees. Profit/losses of the burningmen would also inform if the BTC fees are very different to the estimated amount.
[3] The
issuance boost factorof2should ensure that enough BSQ can be burned as it is expected that many inactive contributors will not take part. This factor is the same as used for the max effective burn share. The100kBSQburn target boostershould give additional buffer. It still needs to be figured out what is the best value here. We could also derive if from the estimated BTC fee value.[4] 12 cycles is chosen to have the same period as with the issuance decay. But we could change that if there are reasons for that.
[5] Those restrictions in the UI should help to avoid mistakes, but a contributor could also burn BSQ in the
Burn BSQUI by using the contributor name as pre-image. Technically the hash of the pre-image is the linkage to the user name of the compensation request.At the
Burn BSQUI one could burn higher amounts as indicated, but as we use the cap of 2 times the issuance share for the burn share used in the distribution they would not benefit from trying to trick the system, rather burn too much without benefit. If a contributor wants to use another application as the one used for receiving the genesis output or used for a compensation request, they can do it as described above. They just should take care to not to burn too much.[6] In case a contributor got capped their burn share (double of issuance share), we use the capped amount and do not fill up that missing share with the legacy BM as we do not need a 100% sum in that algorithm. All other BM would have a slightly higher relative share if one BM got capped their share. Trade fees are not verified by the peer so no need for consensus here.
[7] The height used for the selection is calculated from a modulo 10 and selects one of the past 10-20 blocks. That way we are always 10-20 blocks in the past but can be sure that there is no race condition which would lead to failed trades. We also remove tiny outputs below 500 sat or the double of the costs for the output with the fee rate used if that would be > 500 sat. The lost amount will be used as mining fees. We use the miner fee rate from the deposit tx but use at least 10 sat/vbyte to reduce the risk that the DPT would not enter the blockchain if fee rate would have changed a lot between take offer time and opening arbitration.
Latest updates:
The text was updated successfully, but these errors were encountered: