Distribute Burningman role to contributors who burned BSQ

[HenrikJannsen]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

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:

• Accumulated amounts from reimbursement requests over the past 12 cycles
• Estimated BTC trade fee per cycle [2] for the past 12 cycles
• Burned BSQ from legacy burningman of the past 12 cycles (from BTC fee + delayed payout txs)
• Burned BSQ from the burningmen of the past 12 cycles

burnTarget = sumReimbursements + sumEstimatedBtcFees - legacyBurningmanBurndedBSq - burningmenBurndedBSq

A 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 factor of 2, 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 amount of 100 000 BSQ to 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 https://github.com/bisq-network/proposals/issues/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 https://github.com/bisq-network/proposals/issues/390#issuecomment-1298541891 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 factor of 2 should 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. The 100k BSQ burn target booster should 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 BSQ UI 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 BSQ UI 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:

• Nov 1st 17:00 CET (change way how we decay comp. requests as discussed in https://github.com/bisq-network/proposals/issues/390#issuecomment-1298541891)
• Nov 4st (changed geneisis weight to 5% and added new UI elements. See UI and distribution at: https://github.com/bisq-network/proposals/issues/390#issuecomment-1304355951)

[sqrrm]

Additionally we add a boost burn target amount of 100 000 BSQ

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?

has either funds from genesis output(s) in their wallet or if they had made a compensation request with that application

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.

Selling larger amounts of BSQ will be harder

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.

[HenrikJannsen]

Additionally we add a boost burn target amount of 100 000 BSQ

I don't know if it's good to have a hard limit.

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.
The other factor for boosting the issuance will only allow to burn the double but if less then 50% of contributors partizipate we do not reach the burn target. By increasing that we add more risks for the abuse cases if one contributor can gain more then 15%. I guess we need to make a few examples with numbers to see what values should be chosen.

What happens when this limit is broken, especially when multiple burns happen in the same block?

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.

has either funds from genesis output(s) in their wallet or if they had made a compensation request with that application

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.

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.

Selling larger amounts of BSQ will be harder

This makes it harder for the reimbursed traders to liquidate their BSQ.

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.

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.

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. Fast forward 10 years, the growing inactive contribution amount would become much larger and would distort the share of the active contributors. With decaying the inactive to zero that problem would be gone.

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.

[clearwater-trust]

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?

[MwithM]

What happens when this limit is broken, especially when multiple burns happen in the same block?

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.

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.

Earned BSQ from the genesis output will get reduced to 10% of its original amount.

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. The arbitrator, or refund agent, who gets big reimbursements in BSQ after paying their own BTC, will have it harder to sell those BSQ, as they can be bought from the burningman at a fixed price currently now, but that won't be possible anymore.

[pazza83]

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.

burnTarget = sumReimbursements + sumEstimatedBtcFees - legacyBurningmanBurndedBSq - burningmenBurndedBSq

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:

burnTarget = sumReimbursements in BSQ + sumEstimatedBtcFees/Average BSQ/BTC price - burningmenBurndedBSq

A positive result means there need to be burned more BSQ.

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:

• DPT
• BTC trade fees

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.

The max. amount to burn per contributor is calculated from the issuance share multiplied with the burn target. We allow a issuance boost factor of 2, so the contributor can burn double that value. This is done as it is expected that not all contributors will partizipate.

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.

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%).

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.

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

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.

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.

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.

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 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?

[pazza83]

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.

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.

The extra work for the RA need to be compensated by higher payment. So there will be more costs for the DAO likely.

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.

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.

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.

[HenrikJannsen]

@MwithM There is currently a 100k BSQ headroom to burn more as the target. I guess that should cover some spikes.

Earned BSQ from the genesis output will get reduced to 10% of its original amount.

Per year or per cycle?

The genesis outputs would stay static at 10%. Only old contribution requests get decays over time to 0. The motivation is as discussed above. Without decaying old contribution requests to zero (leaving them at 10% as well as intended earlier) would lead to instability of the system, as that part will ever grow. The reason to still keep the genesis outputs at 10% is because it would be unfair to them to reduce them to 0 as well as they had risked more before the DAO was in place. Their work did not get compensated in time but they hoped that future BSQ will have some value, in contrast to normal contributors who get BSQ with a known market value. So I think its justifies to give them a chance to partizipate.

donating a % to a project

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 Regarding burnTarget: I guess I was not clear enough.

• The reimbursments are both RA and traders
• The BTC fees are defined as BSQ. We use a hard coded value from the average of the past year (about 60k BSQ) and it can be changed each cycle by voting, similar as fee amounts. We use a DAO parameter which was not used for that purpose. As we do not have the BTC fee amounts available in the application we need to feed it in via a "oracle".
• Legacy BM amounts will fade out once the new model is in place. Technically there is still a fallback for certain cases to the default BM but I expect it will not happen in reality.

I am assuming that the burn target can also go into the negative

Yes, exactly.

DPT, BTC trade fees

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...

Burn share x ((12 months past DPT) + (12 month past BTC trade fees)) = expected BTC return.

Yes I guess that can be added to the table.

total of current accumulated payouts for all active and past participators

I fear thats like above out of scope as we cannot request 1000s of tx data from explorere in every Bisq app. But the expected BTC return might be a good pointer. If one see how much % it deviated from the real profit that % can be applied to others as well.

Could contributors BSQ compensation instead be decayed over time to 10% rather than zero? This would allow past contributors to also contribute.

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.

From the proposal I think all BTC output addresses should be known. Yes.

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?

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.

[sqrrm]

fallback for certain cases to the default BM

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.

[HenrikJannsen]

fallback for certain cases to the default BM

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.

[HenrikJannsen]

Got some small improvements:

• If a contributor has not set up a custom address we can use the BTC address instead the BSQ address in most cases. The issuance tx has normally a BTC change output and that address will be used. Only if the miner fee was exact and no change created the BSQ issuance address would be used. But I guess that will never happen in reality.
• Genesis receivers could make a minimal comp. request using the exact name as Github user name in the comp request and add a custom address. After that gets accepted that custom address will be used as the receiver address instead of the BSQ genesis output address. For such a comp. request the requester need to provide some proof that they own the genesis output. Some signature of the comp request txId using the BTC key of that address should work.

[clearwater-trust]

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.

[HenrikJannsen]

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.

Contributors get paid in BSQ as now. Nothing changed. The only change is that any contributor can become a burningman if they want. The current BM signalled that they want to retire, so there is some urgent need to solve that old problem with the centralized BM role. This was since long a problem but no satisfying solution have been found in the past. This proposal is the best solution so far. I am aware that it has some complexity. So like the DAO and Bitcoin. But no need that every user/contributor dive into the complexity of the systems they use.

[pazza83]

The genesis outputs would stay static at 10%. Only old contribution requests get decays over time to 0. The motivation is as discussed above. Without decaying old contribution requests to zero (leaving them at 10% as well as intended earlier) would lead to instability of the system, as that part will ever grow.

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.

[HenrikJannsen]

Can you explain what would cause the instability if the allocated amounts to burn continued to grow over time?

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. Lets ignore genesis outputs as it does not effect the dynamics.

Assume there are every year new 10 contributors each earning 1000 BSQ / month. Each contributor has with the linear decay 12*1000/2 = 6k weight or 10% share of the total weigh of 60k.

Lets move to year 2: Assume there are new 10 contributors and the 10 from the first year have retired. Now as we decay over 2 years we get a higher total weight from the issuance of the 2. year. The 1st issuance in the start of the 2. year has 50% weight=500BSQ the last has 1000BSQ. Each contributor gets 12500+12500/2 = 9k weight. Total weigh of first year contributors is: 1012500/2= 30k. Total weigh of second year contributors is: 90k. Sum of both: 120k. The share of a new contributor is now 9k/120k=7.5% instead of 10% as it was in the first year. The share of a old contributor is now 3k/120k=2.5%. This decrease of the share is also the reason that the assumption that old contributors will likely fade out in partizipation is justified as the potential revenue goes lower over time and at some point the work to partizipate might not be worth it.

If we would go on, the tendency continues and new contributors weight goes lower and lower in an asymptote curve to zero (12k/∞). Imagine after 10 years and total weight might be very large but the contributors weight can become max. 12k BSQ (with no decay for infinite time).

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. Lets assume there are 2 years window of retiring and new contributors. The total share of that will always be the same, independent if at the first 2 years of in 10 years going back 2 years.

The genesis amounts are a static value so it does not impact.

[HenrikJannsen]

Here are the current parameters I use. They might change and I will keep it updated here.

    // Parameters 
    // Cannot be changed after release as it would break trade protocol verification of DPT receivers.

    // Prefix for generic names for the genesis outputs. Appended with output index.
    // Used as pre-image for burning.
    private static final String GENESIS_OUTPUT_PREFIX = "Bisq co-founder ";

    // Factor for weighting the genesis output amounts.
    private static final double GENESIS_OUTPUT_AMOUNT_FACTOR = 0.05;

    // The max. age in blocks for the decay function used for compensation request amounts.
    private static final int MAX_COMP_REQUEST_AGE = 2 * YEAR_AS_BLOCKS;

    // The max. age in blocks for the decay function used for burned amounts.
    private static final int MAX_BURN_AMOUNT_AGE = YEAR_AS_BLOCKS;

    // Number of cycles for accumulating reimbursement amounts. Used for the burn target.
    private static final int NUM_REIMBURSEMENT_CYCLES = 12;

    // Default value for the estimated BTC trade fees per month as BSQ sat value (100 sat = 1 BSQ).
    // Default is roughly average of last 12 months at Nov 2022.
    // Can be changed with DAO parameter voting.
    private static final long DEFAULT_ESTIMATED_BTC_FEES = 6200000;

    // Factor for boosting the issuance share (issuance is compensation requests + genesis output).
    // This will be used for increasing the allowed burn amount. The factor gives more flexibility
    // and compensates for those who do not burn. The burn share is capped by that factor as well.
    // E.g. a contributor with 10% issuance share will be able to receive max 20% of the BTC fees or DPT output 
    // even if they would have burned more and had a higher burn share than 20%.
    static final double ISSUANCE_BOOST_FACTOR = 2;

    // Burn target gets increased by that amount to give more flexibility.
    // Burn target is calculated from reimbursements + estimated BTC fees - burned amounts.
    static final long BURN_TARGET_BOOST_AMOUNT = 10000000;

    // One part of the limit for the min. amount to be included in the DPT outputs.
    // The miner fee rate multiplied by 2 times the output size is the other factor. 
    // The higher one of both is used. 1000 sat is about 2 USD @ 20k price.
    private static final long DPT_MIN_OUTPUT_AMOUNT = 1000;

    // If at DPT there is some leftover amount due to capping of some receivers (burn share is
    // max. ISSUANCE_BOOST_FACTOR times the issuance share) we send it to legacy BM if it is larger
    // than DPT_MIN_REMAINDER_TO_LEGACY_BM, otherwise we spend it as miner fee.
    // 50000 sat is about 10 USD @ 20k price. We use a rather high value as we want to avoid that the legacy BM
    // gets still payouts. 
    private static final long DPT_MIN_REMAINDER_TO_LEGACY_BM = 50000;

    // Min. fee rate for DPT. If fee rate used at take offer time was higher we use that.
    // We prefer a rather high fee rate to not risk that the DPT gets stuck if required fee rate would 
    // spike when opening arbitration.
    private static final long DPT_MIN_TX_FEE_RATE = 10;

The most important ones are:

• GENESIS_OUTPUT_AMOUNT_FACTOR
• MAX_COMP_REQUEST_AGE
• MAX_BURN_AMOUNT_AGE
• ISSUANCE_BOOST_FACTOR
• BURN_TARGET_BOOST_AMOUNT

[HenrikJannsen]

Here the distribution with the current parameters (5% for genesis outputs):

[HenrikJannsen]

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. That generates a total weight of: 24*30/2=360k

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.

[HenrikJannsen]

Here the distribution with 10% for genesis outputs:

[HenrikJannsen]

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.

I think the market will set here the costs for the DAO.

Assume there is 100k target but only 50k got burned by a couple of contrbutors. They will make 50k profit and the DAO make 50k loss. But anyone observing wants to join the profitable game. So there should be reached an equilibrium to make a small profit long term. Due volatility of reimbursements there is some risk involved and those who partizipate long term can average out that risk.

I added the 3 months average expected monthly distribution and using that and the contributors burn share they get the expected revenue. So that can help to find the amount to burn to stay in the profitable range.

The 3 months average expected monthly distribution is the sum of the average reimbursments and the average estimated BTC fees.

[HenrikJannsen]

Ah there is more...

If one has 10% issuance share and would be the only burner we limit that max receiver share to 2 times the issuance share -> 20% for protecing against abuse risks. So we need at least 50% issuance share so that they do not get capped. If so, the legacy BM would receive the rest (of the DPT outputs). In that case the legacy BM would still need to sell the BTC for BSQ and burn it, so no problem for the DAO, but we want to avoid that he still is used.

The top 15 contributors in the above screenshot would account for about 60% issuance share. So if most of them partizipate it should be ok. But I agree that this might be a bit tight. Maybe we need to increase that ISSUANCE_BOOST_FACTOR value to 3, so then only about 33% of contribution share is needed to partizipate without sending funds to the legacy BM. It would though increase the risks that anyone with >5% could gain from the mentioned attack. Now it would require >7.5%. Though as there are only 4 contributors > 5% I guess we could accept that increased risk.

[HenrikJannsen]

Here the numbers of the accumulated top contributors issuance shares:

Top 5: 34% Top 10: 50% Top 15: 60% Top 20: 68% Top 30: 75% Top 40: 80%

[HenrikJannsen]

The goal of the proposal (next to removing the BM) is to increase incentives for active contributors by receiving a stream of BTC payments. But what if it does not play out that way? What would happen in a scenario where active contributors do not partizipate and the model is used only by past contributors and genesis output receivers? Maybe because they burn with taking a loss into account as they have a lot of BSQ stake which they cannot sell on the market without crashing the price and by that they make it not attractive to active contributors who are not willing to trade they BSQ for less as the USD equivalent when they earned it.

The active contributors might have it harder to sell their earned BSQ on the market as there is no BM anymore, only traders who buy usually smaller amounts. This might lead to a decrease of the BSQ price. This will have impact on the BSQ fee rate as it should maintain the discount to the BTC fee rate, so BSQ fee will become higher in nominal BSQ, thus traders need to buy more BSQ on the market, which creates higher demand for BSQ and therefor acts as counter force for the sinking price.

The past contributors and genesis output receivers might burn their BSQ stake but watching the BSQ price goind down is also negative for them and the amount needed to burn per months will rise with lower BSQ price (burn target is derived from BTC values). So they have an incentive to keep the BSQ high. They also might run out of their BSQ investment and need to buy BSQ on the market if they want continue to partizipate in burning, thus creating demand for BSQ pushing the price up.

So I think the risk that large BSQ stakeholder play such an aggressive role would be counter productive and if they do, it should level out itself over time. At some point they run out of their BSQ as well. Also they could crash the market anyway already now if they would not care about Bisq, so there is no reason to assume they would act in a negative manner with the new model.

[HenrikJannsen]

I created a DAO proposal. TxId: 0816f629e5b89b2a07596ec1671e123cc0271d646eae1e1b4576b6a6ec529d32 As this proposal change the economic model of the DAO I think it is necessary to put it up for DAO voting. Some details of the parameters might still change after the voting. If there would be strong disagreement about changed parameters we can repeat voting next cycle.

[HenrikJannsen]

More thoughts about the new model...

It it similar as if the current BM is only allowed to trade with contributors (+genesis output receivers) and the max. amount of each is limited by the decayed issuance amount in relation to the others who want to trade. If there are only few who want to trade one can get as much as the double of the issuance share. E.g. If I have 10% I can get max. 20% of the total sum the BM has available for trading.

And another thought about the economics: The partizipants for burning are actually doing the work to bring the revenue from BTC fees back into the BSQ ecosystem by competing to reach the equilibrium that just enough BSQ is burned to cover the BTC fee value + the reimbursement amounts. The reimbursement part can be ignored because its not part of the revenue. So lets assume there is no extra BSQ burned for the BTC fee part. The partizipants would earn the BTC fees in that case. As that profit will attract more it will not stay long like that. Once the optimum is reached, all value from BTC fees goes into burned BSQ and the DAO gets the revenue represented as deflation just as it is now. As due volatility, unkown future distribution, etc. there are risks and work involved which will be costs for the DAO. Lets assume that from BTC fees in the value of 50k BSQ only 45k gets burned, thus 10% is profit for the partizipants. In that case 5K BSQ would be the cost to the DAO. As the partizipants are a sub group of the DAO this is less problematic and more fair as if it would be if one role only is causing that cost. The real costs for the legacy BM would be also much higher but it is difficult to estimate due the uncalculable risks (the 50k bond would not cover the potential loss and the BM does not charge for the risk to lose the bond). Current costs is I guess 1000 USD (lets assume 1000 BSQ for simplicity) + loss/profit from volatility and trades. Market makers or BSQ stakeholders (incl. non contributors) can benefit from market conditions and are the beneficiaries of those costs. As those are more flexible they are less likely to make loss. The BM on the other hand need to sell each month even if market price is temporarily very bad, thus he is more at risk for losses from market conditions.

In the new model those costs go to the partizipants, and if anyone consider the costs too high they can partizipate to bring the costs down.

I think it also stabilized the BSQ price as the burning is a from of secondary market limited to contributors and therfor less at risk for market distortions (e.g. as if one big stake holder who do not care about Bisq crashes the price with a fast sell-off).

So with all that I think the model is much more aligned with the goal that the DAO should serve the contributors.

Non-contributing BSQ stakeholders and market makers are the group which will lose benefits/opportunities in the new model as the legacy BM will not be there anymore for them to benefit from market conditions and trades with a restricted trader (BM sells all the available BTC for BSQ at trade event independent of BSQ price). Those effects have never been a goal but are unintended side effects of the current BM model.

Contributors who did not want to invest the work and time to observe the market (BM trade events) will have an easier option to convert their BSQ to BTC by partizipating in the new scheme.

[sqrrm]

This is looking quite reasonable. I don't worry too much about the economics of it, it might cause some distortions, but the end effect should be the same in the aggregate demand as with the current model, as you mentioned.

// The max. age in blocks for the decay function used for compensation request amounts. private static final int MAX_COMP_REQUEST_AGE = 2 * YEAR_AS_BLOCKS; // The max. age in blocks for the decay function used for burned amounts. private static final int MAX_BURN_AMOUNT_AGE = YEAR_AS_BLOCKS;

These parameters should use the same time span as NUM_REIMBURSEMENT_CYCLES I would think. Better to use blocks_per_cycle * NUM_REIMBURSEMENT_CYCLES instead of YEAR_AS_BLOCKS. If they don't use the same timing there might be some odd timing issues if YEAR_AS_BLOCKS and the cycles don't match for a few blocks.

I think the 5% for genesis looks reasonable. Another thought is also reduce the allowed burn with the amount actually burnt. That would balance the burn over time, but sounds much more complex. Probably better avoided.

[HenrikJannsen]

These parameters should use the same time span as NUM_REIMBURSEMENT_CYCLES I would think. Better to use blocks_per_cycle * NUM_REIMBURSEMENT_CYCLES instead of YEAR_AS_BLOCKS. If they don't use the same timing there might be some odd timing issues if YEAR_AS_BLOCKS and the cycles don't match for a few blocks.

Yes I agree. Will consolidate that to use only one.

[HenrikJannsen]

I think a key to ensure there is minimal profit/loss by the distribution in relation to what one has burned is to reduce volatility of the reimbursements. In the past there have been some really high spikes. If for instance 100k goes into DPT it would result in a short-term profit spike. Burn target also goes up after reimbursement. More burners might join in expectation of profit and more BSQ gets burned due higher target, but as it was a one time spike they will make a loss. New burners not fully understanding the concept and risks might be disappointed and leave again quickly, reducing their chance to recover the short term loss with a new spike in the future (the 1 year decay still gives them some chance). So that might have negative overall impact and only partizipants who fully understand the complexity and have a long term view with a high tolerance for losses might stay in the burner group, which might become a smaller group as intended.

One way to improve that is to use a weighted average for the reimbursements, so that a spike is more correlated with burn weights. But that will not avoid the problem mentioned. The key is to reduce volatility from reimbursements, which should be partly reached by #391. Maybe we still should reduce the max. trade amounts if that alone does not help to avoid those spikes. There will be also volatility from BTC fees, but that is less severe.

Partizipants need to be aware that there can be short term losses and short term gains. The uncertainty of future DPT events and BTC trade fees cannot be avoided as they are burning before the future is known.

Reimbursement volatility.

BTC trade fees volatility:

Trade volume volatility:

[HenrikJannsen]

More thoughts...

Actually to figure out the optimum amount of BSQ to burn is likely easier as it seems from above discussions.

It is similar to a shop-owner who buys inventory. He does not know how much he will sell how fast. He need to keep enough in stock to serve his clients. He does not know the future. If he buys too much he risks that ppl dont buy the products and he makes a loss. If he buys too few he risks that ppl would like to buy but he has not enough in stock and lose out some profit opportunities. A practical solution is to start with a informed guesstimate and then adjust regularily to find the optimum.

For burners it would work similar: They start with a decent amount which feels safe. If in one month the revenue from BTC did not cover the burned BSQ they will wait with further burning until it becomes profitable to them. If they made profit, they might burn more BSQ to get a bigger share. If volatility from reimbursments or BTC fees will surprise they can act accordingly, either wait longer with next burn until their burned BSQ generated profit or burn more BSQ to boost profit.

[pazza83]

Thanks for all the info.

So using the numbers above from comment:

Total weight = Total genesis outputs 180k + Compensation Requests from contributors 360k Total weight = 540k

My sums for Burn Target, prior to any new burning:

Estimated BTC trade fees + Estimated DPT Last 12 months BTC trade fees: 13.68300047 + Last 12 months DPT: 24.86569398 BTC = 38.54869445 BTC

38.54869445 BTC in BSQ is approx: 1,020,346 BSQ

That is before you add on a 100k burn target boost.

Have I misinterpreted the figures or would this be a significant shortfall?

[pazza83]

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.

I agree with the assumption is that past contributors are less likely to be active.

I do think however that the assumptions do not take into account that having a larger total potential burn weight also has advantages. More people that can burn is better than fewer people that can burn.

To incentivize current contributors to be burners maybe the issuance boost factorcould be a DAO parameter that is can be voted on at semi regular intervals. Could even be based on:

Maintaining (genesis weight + past contributor weight) to current contributor weight to a 1:2 ratio.

[HenrikJannsen]

Here the data from the app (sat values). Those data are from the DAO and the EstimatedBtcTradeFees are hard coded as 62k/month.

accumulatedReimbursements: 67540047
+ accumulatedEstimatedBtcTradeFees: 74400000
- burnedAmountFromLegacyBurningManDPT: 50766621
- burnedAmountFromLegacyBurningMansBtcFees: 70231200
- burnedAmountFromBurningMen: 0
= Total: 20942226

I guess we are in the same range, but with changing BTC and BSQ prices it is difficult to get exact numbers. BTC trade fees: 62k/month -> 744k/year Reimbursements last 12 cycles: 675.4k Total: 1.419M BSQ

The 62k/month is hard coded and taken from the average BTC fees in BSQ value over the past 9 months (i guess it was 9). The burnedAmountFromLegacyBurningMansBtcFees divided by 12 is 58526 BSQ so thats a bit lower. I would need to check again the data, but taking 12 months was less accurate as far I remember as it was the time when address tagging at burn txs started. Also the accumulatedReimbursements and burnedAmountFromLegacyBurningManDPT have quite some gap using 12 months, but as there can be 1-3 months delay that hardly levels out.

The total weight is correct. That will limit the burn weight and allowed amount to burn per BM. If we would have 1.4M burn target / year that would be 118k/months.

If a BM has 10% issuance weight, they can burn (with boost factor of 2): 0.1 * 2 * (118k + 100k) = 43.6k

Formula:

boostedIssuanceShare= issuanceShare * ISSUANCE_BOOST_FACTOR;
maxBurnAmount = burnTarget + BURN_TARGET_BOOST_AMOUNT;
allowedBurnAmount = boostedIssuanceShare * maxBurnAmount - accumulatedDecayedBurnAmount

If they have already burned something that will get subtracted (accumulatedDecayedBurnAmount).

Note, that the legacy BM amounts get reduced as well, so there might be lower burn targets. But the BURN_TARGET_BOOST_AMOUNT will give some flexibility to burn a bit more as estimated.

With current app I get 209422 burn target. Seems a bit high probably caused by BM having open DPT not burned yet (https://mempool.space/address/34VLFgtFKAtwTdZ5rengTT2g2zC99sWQLC - 3.68 open there thats about 100k BSQ so once thats burned burntarget would drop to about 100k).

[HenrikJannsen]

I do think however that the assumptions do not take into account that having a larger total potential burn weight also has advantages. More people that can burn is better than fewer people that can burn.

Yes I agree but inactive contributors might pose higher risks as well. But more importantly the more we add the lower the relative issuance share gets for active contributors. Then we need to increase the boost factor even higher to ensure there is enough burn volume which increases the overall risk when burn share gets > the 15% security deposit. By being more aggressive with the decay more recent contributors get a relative higher share. By including more many of the included will likely not be active (they dont follow Bisq probably anymore), so we do not gain more burners, but the active burners get lower share and the difference between them gets lower as well.

To incentivize current contributors to be burners maybe the issuance boost factor could be a DAO parameter that is can be voted on at semi regular intervals. Could even be based on: Maintaining (genesis weight + past contributor weight) to current contributor weight to a 1:2 ratio.

We do not have many not-used parameters (I guess there was one more). So I would prefer to not use them if not absolutely needed. Also prefer to not add more complexity if not needed as its already quite complex. But maybe we can derive the factor from past burn behaviour. If we see that not enough is getting burned and that burners hitting their cap limit we might increase the factor. Will have a look into that.

[HenrikJannsen]

Another option is to limit the burn share not based on the issuance share but by the 15% (of the sec. deposit). Then burners with 2% issuance share could burn still much higher amounts and it would help to get more decentralisation in the burn share.

[HenrikJannsen]

Also take into account that in case there is not much partizipation in burning (bad for decentralization - in the worst case there is only 1 burner or none) that those who partizipate can make a profit by burning less then the target. This should attract then others to partizipate as well. It is a service to Bisq, so those who do that work should earn something. And the open market of potential burners should find the right cost for that service.

[HenrikJannsen]

But there is another risk if we let contributors to easily burn too much. Then a small group could burn the BSQ needed for the target or even above and others will have no incentives to join as they would cause for themself and others a loss if too much gets burned.

[pazza83]

Thanks for explaining. The maths is getting complex for me so I might be missing something.

I think I was viewing the burning men as burning a target for a year which was getting updated each cycle.

In your model you have the Burning Men burning a yearly target divided by 12 to give a total for a cycle. I am assuming this is how it will end up being.

If we take 118k BSQ as the the burning target for a cycle then over the year the total amount burnt will be approximately a quarter of the BSQ supply. Whilst this will likely work initially do you think it will require future Burning Men to go into the BSQ/BTC market to buy BSQ to burn? Likely the sum of compensation requests will be significantly under the Burn Target. Genesis contributors can help but even long term they cannot continue to burn without replenishing?

If a BM has 10% issuance weight, they can burn (with boost factor of 2): 0.1 * 2 * (118k + 100k) = 43.6k

Using this analogy:

If 10 Burning Men have a 10% issuance weight then the total amount of BSQ they can burn is 436k.

Target for the first cycle is 118k

(118/436) x 100 = 27

Therefore, participation required to reach the burn target for the first cycle is 27%.

Extrapolating this out for subsequent cycles wont the accumulatedDecayedBurnAmount become a factor that means each cycle participation has to be higher? and also the DAO will be relying on potential burning men that did not participate.

Worst case scenario is that all the Burning Men that want to participate have reached their issuance weight limits and, therefore, future cycle Burn Targets will not be achieved even if there is an obvious profit incentive to do so due to issuance limits.

[HenrikJannsen]

I think I was viewing the burning men as burning a target for a year which was getting updated each cycle.

It is a continuous process but gets some up-ticks at the vote result block as there new reimbursements might drop in as well as the estimated BSQ trade fee will gets added (vote on DAO param).

Any BM can burn any amount (inside their limits) at any time. But the burned amounts decay over one year. Your burn share (your accumulated decayed burn amounts / total accumulated decayed burned abounts of all BM) will determine your share of the payouts. Data gets updated with each block. Every time one BM burns BSQ it also changes the burn share of each BM as the total changes.

If we take 118k BSQ as the the burning target for a cycle then over the year the total amount burnt will be approximately a quarter of the BSQ supply. Whilst this will likely work initially do you think it will require future Burning Men to go into the BSQ/BTC market to buy BSQ to burn?

The 118K carries about 50% reimbursements, so that part will get issued and has no effect on the BSQ supply. The BTC fee part gets burned and creates deflation. Yes I think it should lead to the situation that burners might run out of their BSQ and need to buy up BSQ on the market and therefore create a price pressure upwards. Then the BTC fee estimation need to be adjusted with the higher BSQ price and by that less burn target will be calculated. If BSQ would be 1 times the price the 62k for the BTC fees would be 31k if all other data stay the same beside the BSQ/BTC price being double as high. So by that there will be less BSQ burned and deflation pressure goes down.

For the reimbursement part, it would be good when BM would become BSQ buyers on the market to help the refund agent to convert their BSQ they got back to BTC they spent to traders.

I think reimbursement amounts should be much lower over time. If #391 does not help we need to lower max trade amounts. So that part should have less impact in future.

Therefore, participation required to reach the burn target for the first cycle is 27%.

Yes, correct.

Extrapolating this out for subsequent cycles wont the accumulatedDecayedBurnAmount become a factor that means each cycle participation has to be higher? and also the DAO will be relying on potential burning men that did not participate.

Worst case scenario is that all the Burning Men that want to participate have reached their issuance weight limits and, therefore, future cycle Burn Targets will not be achieved even if there is an obvious profit incentive to do so due to issuance limits.

Ah I guess there is a misunderstanding (or I mentioned it wrong). The calculation for the burn target use the accumulated burned amounts of the past year, not the decayed amounts. So if no old burn txs falls out of that 1 year window there is no change with a new block because decay is not be used for that. The decay is only used for the BMs burn share calculation, so more recent burns have higher impact for him.

Assume we reached the burn target by 27% of contributors weight partizipated. So burn target is 0. Total burned BSQ is 118k.

Next block we update the data. If no new burns happen and it is not a vote result block the target stays at 0. The distribution factor stays the same as well as all BM gets decayed the same way and the relative % stays the same.

When a new burn happens then the target would go negative. Lets say 1000 BSQ got burned. So we have target -1000. Now burn share gets updated as the total accum. decayed value is 1000BSQ higher and other burned gets slightly lower share.

When the vote result block happens we get a bigger update. Lets say there have been 20k on reimbursements and the BTC fee estimation param was changed to 50k. So burn target goes from -1000 up to 69k. As long nobody burns nothing changes in burn share. But BM should try to get the target to zero again. So lets assume 6 BM burns each 10k BSQ. The target goes to 9k and the share of those have increased in relation to other BM who did not burn. Maybe 1 week later 2 other BM burn 5k each and we get again to -1k target and now again the burn share gets updated for each.

So the time when BM want to burn is independent of cycles, but at vote result we get a big target increase usually and there is more headroom to burn. If target would be -100k then nobody is allowed to burn anymore. Also if a BM reach a burn rate of 2 times his issuance rate he is not allowed to burn more as it would not benefit him, as for distribution we cap by that factor.

If my reply does not clearify your comment please explain more in detail what you meant. I do not see why there would be that instability. But maybe I miss something.

[MwithM]

How would a failed cycle impact to burningmen? Is there a scenario where some burningmen would benefit from a failed cycle?

[HenrikJannsen]

How would a failed cycle impact to burningmen? Is there a scenario where some burningmen would benefit from a failed cycle?

Then there would be no increase of the burn target at the expected cycle but even more increase at the next cycle. It might cause larger gain after the failed cycle of BM do no burn more (they might because new ones might get in to compete for the profit) and after the consolidated cycle there will be larger target which might lead to a loss for BM when they burn up to the target. But if the over-burn a bit at failing cycle and under-burn at next cycle they can smooth it out.

[ghost]

Voicing my support for this proposal.

This proposal increases the DAO's utility, in addition to decentralizing the BM role. It is a bold experiment in how to decentralize compensation in this space and if it works could light the way for others.

• BSQ gets issued for contributors who have performed work.
• BSQ gets burned by contributors (BMs) who choose to participate in this scheme.
• BTC revenue gets distributed proportional to each BM's share of burned BSQ at the point in time the revenue is received.

It is not possible for an individual BM to predict their BTC income based on the BSQ they burn. Other participants burns will change the individual's share. It is very different to what people are used to when earning.

I think a typical participant would:

• have high risk tolerance.
• have low time preference.
• not depend on their earnings for subsistence.

The existing BSQ/BTC market is still there for people requiring predictability and/or instant settlement.

I do not pretend to fully understand how the dynamics of this system will play out, but having tried the proposed implementation think it is an exciting and worthwhile thing to adopt.

[HenrikJannsen]

Thanks @jmacxx for your feedback! Yes the risks/effort are not for everyone and should be compensated by a small profit. How big that profit of the BMs is depends on the other potential BMs partizipation. All contributors who do not want to partizipate can ignore it and just sell they BSQ to BTC on the market. The removed BM might make the selling a bit harder but the BM was anyway an artificial "regulated" market actor - a flaw in the system.

[HenrikJannsen]

A receiver of a genesis output can also attach a custom receiver address by creating a special compensation request and verifying the data with a BTC transaction from his genesis output address. This helps to avoid to receive lots of transactions in the BSQ wallet. Of course that is optional, if not set up a custom address the receiver address from the genesis output is used (BSQ address which will receive BTC amounts then).

The custom address could also be updated be a new compensation request. We take the latest one if one is available.

Here are the steps how to do that:

1. Select your co-founder entries in the table (you find your in the combobox). At selection the address is displayed below.

2. Send any BTC amount to this address. After a confirmation you will see that balance as non-BSQ balance in the BSQ wallet
3. Go to BSQ Wallet/Send BSQ and click the "Add Optional Data" button. Enter the custom receiver address you want to use for receiving BM payments as pre-image. Check with input controls if there are multiple inputs to select and if so make sure the genesis output is part of the tx.

4. Send out the funds to any BTC wallet.
5. Copy the Tx ID and the Hex encoded opReturn.
6. Burn 10 BSQ and use the Tx ID as pre-image.
7. Create a Github account with your generic name for that genesis output ("Bisq co-founder-x"). If it would not be available choose any GH name.
8. Create a compensation request with following text:

Compensation request for attaching a custom Burningman address to a genesis output receiver.

Dummy request amount: 10 BSQ

Requester name: "Bisq co-founder-[insert genesis output index]"

Transaction ID for proving that I own that genesis output address: [...]

Burn BSQ transaction ID for proving that I burned 10 BSQ: [...]
The pre-image used at the Burn BSQ transaction is transaction ID from above.

Custom Burningman address: [...]

OpReturn data as hex: [...]

How to verify?
- Check the transaction at a block-explorer and see if the input is from the output of the genesis tx. The output index need to match the index in the "Bisq co-founder-x" name.
- Copy the opReturn data of that transaction from the transaction details and use a hex converter tool [1] to get the custom receiver address. Check if the receiver address matches the one in the compensation request.
- Check that the burn BSQ transaction was made and that the opReturn data matches the hash of the transaction ID.

Please only vote on the proposal if you have verified all the data.

[1] https://www.online-toolz.com/tools/decode-hex.php

[w0000000t]

With the previous model, there was a 500BSQ limit to reduce risks, and 5000satoshi (if I remember correctly) for payments to reduce outputs... are there any such limits in place in this setup? Burning one's BSQ only to see it "rounded to zero" and/or receiving no BTC because share is too small, would really be disappointing.

[HenrikJannsen]

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. For DPT outputs its 1000 sat (about 2 USD) or the double of the miner fee for the output using 10 sat min as fee rate.

private static final long DPT_MIN_OUTPUT_AMOUNT = 1000;
private static final long DPT_MIN_TX_FEE_RATE = 10;
double txSize = 278;
long txFeePerVbyte = Math.max(DPT_MIN_TX_FEE_RATE, Math.round(tradeTxFee / txSize));
long minOutputAmount = Math.max(DPT_MIN_OUTPUT_AMOUNT, txFeePerVbyte * 32 * 2);

[w0000000t]

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. For DPT outputs its 1000 sat (about 2 USD) or the double of the miner fee for the output using 10 sat min as fee rate.

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

[HenrikJannsen]

I added a new parameter for the max limit for the distribution share of 11%. static final double MAX_BURN_SHARE = 0.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).

[HenrikJannsen]

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. BTC fee estimations are counted at the first block of the next cycle after voting. We go back from there 12 cycles. So both have different ranges of the period.

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 recommended value is calculated by using the recommended overall burn target multiplied with the capped issuance share of the BM (max 11%). In the below screenshot it is: 120k * 0.11 = 13.2k BSQ (capped by the 11%).

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%). A BM with 1% issuance share would have 120k 0.01 = 1200 BSQ for the recommended burn amount and 130k*0.02 = 2600 BSQ for the max. burn amount as they would stay below the 11% cap.

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. If she burns 38.93 BSQ she would get about 3.85% of the burn share. If she burns 81.09 BSQ she would get the boosted burn share of 7.7% (2 times her issuance share).

We calculate that by using that method:

 static long getMissingAmountToReachTargetShare(long total, long myAmount, double myTargetShare) {
        long others = total - myAmount;
        double shareTargetOthers = 1 - myTargetShare;
        double targetAmount = shareTargetOthers > 0 ? myTargetShare / shareTargetOthers * others : 0;
        return Math.round(targetAmount) - myAmount;
    }

total is: 107.75 + 865.38 = 973.13 myAmount is: 0 myTargetShare is: 0.0385 and 0.077 for the upper limit

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.

[HenrikJannsen]

I added the legacy burningman:

[pazza83]

This proposal was approved in Cycle 41.

[HenrikJannsen]

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. A full node (seed node) requests the blocks from Bitcoin core and parses them into our data model which is designed for min. storage size. I guess it will be about 2 MB / year. Lite nodes (normal users) will request the missing blocks from the seeds. This happens after the DAO sync is done to not interfere with higher prio tasks. So we can get all blockchain data from the receiver addresses and detect if its a fee tx or a DPT. For DPT the check is pretty stict and there should be no false positives. For fee txs its a bit less stict and if BM sends funds to themself there might be false positives, but its just screwing up their accounting, so they should not do that. The data published from the seeds is signed and treated as trusted oracle data.

I will make a extra pull request the next days.