Add burningman accounting #6423

HenrikJannsen · 2022-11-22T12:44:53Z

Implements bisq-network/proposals#390 (comment)

HenrikJannsen · 2022-11-25T21:31:20Z

We need to update https://bisq.wiki/Dispute_resolution as well.

desktop/src/main/java/bisq/desktop/main/dao/burnbsq/burningman/BalanceEntryItem.java

ghost · 2022-12-02T02:41:41Z

Regtest Testing notes:

Seed node requires a command line option isBmFullNode=true to enable accounting.
DAO genesis tx may need to be generated at block height 111, since the code assumes that.

.../main/java/bisq/core/dao/burningman/accounting/storage/BurningManAccountingStoreService.java

core/src/main/java/bisq/core/dao/burningman/accounting/BurningManAccountingService.java

core/src/main/java/bisq/core/dao/burningman/accounting/balance/BalanceModel.java

core/src/main/java/bisq/core/dao/burningman/accounting/node/AccountingNodeProvider.java

core/src/main/java/bisq/core/dao/burningman/accounting/node/full/AccountingBlockParser.java

core/src/main/java/bisq/core/dao/burningman/accounting/node/full/AccountingFullNode.java

pazza83 · 2022-12-04T21:09:51Z

We need to update https://bisq.wiki/Dispute_resolution as well.

I am happy to do this and also update:

Assuming bisq-network/proposals#397 will also be accepted? If so I can explain this in the wiki.

Also assuming this proposal bisq-network/proposals#386 is also accepted?

Also unsure as to how legacy trades will be managed?

Will trade placed before the implementation of the new burning men proposal still be able to be taken?

When will bisq-network/proposals#386 be actioned by the refund agent?

Will it apply to ALL trades from a specific date?

Will it apply to trades using the new protocol only or legacy trades?

Might be simpler to choose a cut off date that coincides with the new release. Ie trades taken after X date will not have peers trade deposit paid out.

pazza83 · 2022-12-06T08:00:10Z

Also need to update the mediation result text. Currently reads:

Mediation result for trade with ID: XXXXXXXXXX

The mediator has suggested the following payout:
You receive: X BTC
Your trading peer receives: X BTC

You can accept or reject this suggested payout.

By accepting, you sign the proposed payout transaction. If your trading peer also accepts and signs, the payout will be completed, and the trade will be closed.

If one or both of you reject the suggestion, you will have to wait until XX Month TIME (block XXX,XXX) to open a second-round dispute with an arbitrator who will investigate the case again and do a payout based on their findings.

The arbitrator may charge a small fee (fee maximum: the trader's security deposit) as compensation for their work. Both traders agreeing to the mediator's suggestion is the happy path—requesting arbitration is meant for exceptional circumstances, such as if a trader is sure the mediator did not make a fair payout suggestion (or if the other peer is unresponsive).

More details about the new arbitration model: [1]
[https://bisq.wiki/Dispute_resolution#Level_3:_Arbitration]

Suggested change:

Replace penultimate paragraph with:

Mediation is expected to be the optimal resolution for both traders. If the trade goes to arbitration the arbitrator will payout out the trade amount plus one peer's security deposit. This means the total arbitration payout will be less than the mediation payout. Both traders agreeing to the mediator's suggestion is the happy path. Requesting arbitration is meant for exceptional circumstances, such as one peer not responding, or if a trader is sure the mediator did not make a fair payout suggestion.

HenrikJannsen · 2022-12-09T21:29:53Z

Here are some notes for testing with some explainations about certain behaviour:

It is expected that genesis tx is at block 111. If your setup has it different change the value in BurningManAccountingService.EARLIEST_BLOCK_HEIGHT
We go back 12 cycles for burn target calculations. To make testing more consistant start by creating 156 blocks (13*12)
Compensation requests go back 24 cycles until they decay to 0
For burn target we go back 12 cycles
At trades we need to ensure that both traders have same block. To guarantee that we use a past snapshot block which is always the same for both traders even one has a newer block or there is fork or reorg.
The block height is the last mod(10) height from the range of the last 10-20 blocks (139 -> 120; 140 -> 130, 141 -> 130)
To test the legacy BM one need to burn some BSQ with pre-image fee for the fee receiver BM and dpt for the delayed payout tx BM.
For BTC distribution only the DPT BM is used (that use the default address from the DAO voting)
Receiver address for legacy BM is 2MzBNTJDjjXgViKBGnatDU3yWkJ8pJkEg9w, defined in Para.RECIPIENT_BTC_ADDRESS. If you do not use the default setup which comes with the wallet containing that address, you can either edit the code or do a DAO voting to change the address.
When testing a DPT case you need to create 5 blocks after take offer to show the open dispute button and to make the lock time valid.
If you create multiple blocks the lite client might get out of sync. Also a full client could get issues sometimes. For testing a full client is better as it gets the block immediately, the lite client has a few seconds delay which cause problems when creating fast blocks.

Program artuments for localhost/regtest seed node in full BM mode:

--useLocalhostForP2P=true
--useDevPrivilegeKeys=true
--isBmFullNode=true
--useDevMode=true
--baseCurrencyNetwork=BTC_REGTEST
--nodePort=2002
--appName=bisq-BTC_REGTEST_Seed_2002
--fullDaoNode=true
--rpcUser=...
--rpcPassword=...
--rpcPort=18443
--rpcBlockNotificationPort=5120

The important ones are:
--useDevPrivilegeKeys=true - we use dev privileged keys for broadcasting the data. With that flag it use the hard coded dev keys.

--isBmFullNode=true - makes the node a full BM node. Publishes new AccountingBlock data and respond to GetAccountingBlocksRequests.

--useDevMode=true - Enables testing with DPT.

Parameters:
ISSUANCE_BOOST_FACTOR= 3;
MAX_BURN_SHARE = 0.11
BURN_TARGET_BOOST_AMOUNT = 10 000 BSQ
DEFAULT_ESTIMATED_BTC_TRADE_FEE_REVENUE_PER_CYCLE= 10 000 BSQ

Initial state:
Block 298
Nothing burned

Expected: Legacy DPT BM get 100% of receiver share

Legacy BM and DPT and fee burn BSQ:
Burn BSQ in the Proof of Burn view (not BM view) for with fee and dpt pre-image and check if after a new block the 2 legacy BM in the UI have the burned amounts shown.
As no BSQ got burned so far from contributors, the legacy DPT BM get 100% of receiver share. Legacy BM for fee does not get anything.

Create an offer and after new block check if legacy BM got the trade fee.

Take the offer and check if legacy BM got the del. payout tx after letting the trade go to arbitration.

Burn BSQ as co-founder.
Burn target: 120 000 - 130 000 BSQ
Allowed for a 40% co-founder: 13200 - 14300 BSQ (capped to 11% of 120k-130k)
Burn 13200 BSQ
After a block:
Burn target: 106800.00 - 116800.00 BSQ (120000-13200)
Receiver share 11%; my new burn target: 0;
Co-founder 0 (60%) burn target: 1631.46

Why 1631.46?
We have 13200 BSQ burned. Co-founder 0 could get max 11%. If he burns 1631.46 he has 11% of the distribution. Burning more would not gain him more.
13200 + 1631.46 = 14831.46 -> 11% of 14831 = 1631.46 (see getMissingAmountToReachTargetShare method in code)

Let Co-founder 0 burn 1631.46 BSQ.

Both Co-founder 1 and Co-founder 2 have burn target 0 as thye have reached their 11% cap it would not make sense to burn more.

Alice makes comp request for 20 000 BSQ. She use the address from her Bisq btc wallet as receiver address.
Bob makes comp request for 40 000 BSQ. He does not use a custom receiver address.

After voting Alice can burn 1649.32 - 1693.39 BSQ and Bob: 1693.39 - 1693.39 BSQ .
Burn target is: 105168.54 - 115168.54
Co-founder 0 decayed burn amount: 1516.42
Co-founder 1 decayed burn amount: 12184.62
Alice issuance share: 10.74%
Bob issuance share: 21.49%

Burn target are calculated as follows:
Sum of all decayed burn amounts:
12184.62+1516.42=13701.04
0.11/0.89*13701.04=1693.38 -> If I burn 1693.38 I get 11% of burn share.

Why has Alice less:
Because her issuance share is < 11%

Alice burn 1649.32
new block
Bob burns 1873.73
new block

Bob has now close to 11% receiver share, Alice about 10%. Due to the dynamic behaviour with burn amount decay at each block it is never exactly as it was targeted (11%).

To test receivers for fees we can create an offer and Alice and Bob have 10/11% chance to get the fee. For DPT we need to create 20 blocks to be sure that the snapshot height used for the calculation is higher then the burn tx height.

Create 10 compensation requests for 10 new contributors with 9k BSQ and after voting burn max amount each.
After that we have only the co-founder1 with 11% capped share. all others have lower share and can burn more BSQ.
Legacy BM still gets some % as the sum of all burn shares does not reach 100% yet.
Let everyone burn their max amount and repeat that with new blocks until the legacy BM does not get anymore and until the burn target gets below 0.
It will take some iterations as the max amount is always capped to the amount which makes sense for the individual BM (11% cap).
This situation is only expected at bootstrapping until the BM market is saturated.
When creating new block and entering a new cycle we do not expect much change beside the decay because the total burned BSQ is decaying slowly and the added estimated fee revenue of 10k is not triggering a sudden change. This will change once the oldest burn tx falls out of the decay window of 12 cycles. As we likely have created most burn tx in the same cycle we will see a sudden change. Lets repeat to create 13 blocks until we get to that point.

When getting there the oldest burn txs will get decayed value 0 and the legacy BM might get a share again as we might not reach the 100%. In real life situation it is expected that each cycle new burn txs gets added so that effect will likely not happen.
Also the sudden increase of burn target would be avoided then.
In this test scenario it can be also that the individual burn target gets very low, because the sum of all decayed burn amounts get low as well if we do not burn each cycle...

If the sum of all decayed burned BSQ is very low the individual BM might get values below 5.46 BSQ and then its set to 0.
I will make a change to avoid that by allowing always 1000 BSQ to get burned if on has issuance share and change the UI a bit to show only the suggested value but allow up to 1000 BSQ even if the suggested value is 0 because the BM has already reached its cap.

HenrikJannsen · 2022-12-09T23:27:06Z

We need to update https://bisq.wiki/Dispute_resolution as well.

I am happy to do this and also update:
* https://bisq.wiki/Donation_Address_Owner

* https://bisq.wiki/Arbitrator

Great thanks!

Assuming bisq-network/proposals#397 will also be accepted? If so I can explain this in the wiki.

Seems it got enough support.

Also assuming this proposal bisq-network/proposals#386 is also accepted?

Seems it got enough support.

Also unsure as to how legacy trades will be managed?

The update will happen like that:

Release of 1.9.7 with new BM feature deactivated.
After 1 week after release we set required trade version to 1.9.7. in filter, so anyone who trades need to updated. Pending trades are not affected only new ones.
At activation date (currently planned 1.1.2023) the new BM code gets used. Users who trade have both the new version due the enforcement by the filter.

Pending trades with old version will be treated like before. The Arbitrator UI has still the custom payout option to follow the past rules. Only trades started after activation date are following new rule. Still Arbitrator has flexibility with custom payouts.

Legacy BM will get BTC until activation date. After that it will take a while until new BM have burned BSQ and legacy BM will not receive anything anymore.

Will trade placed before the implementation of the new burning men proposal still be able to be taken?

Offers they are not affected. Trades started before are treated as old trades. The new BM distribution is set at take-offer time.

When will bisq-network/proposals#386 be actioned by the refund agent?

For trades which started after activation date.

Will it apply to ALL trades from a specific date?

Yes.

HenrikJannsen · 2022-12-09T23:31:56Z

Also need to update the mediation result text. Currently reads:
Mediation result for trade with ID: XXXXXXXXXX

The mediator has suggested the following payout:
You receive: X BTC
Your trading peer receives: X BTC

You can accept or reject this suggested payout.

By accepting, you sign the proposed payout transaction. If your trading peer also accepts and signs, the payout will be completed, and the trade will be closed.

If one or both of you reject the suggestion, you will have to wait until XX Month TIME (block XXX,XXX) to open a second-round dispute with an arbitrator who will investigate the case again and do a payout based on their findings.

The arbitrator may charge a small fee (fee maximum: the trader's security deposit) as compensation for their work. Both traders agreeing to the mediator's suggestion is the happy path—requesting arbitration is meant for exceptional circumstances, such as if a trader is sure the mediator did not make a fair payout suggestion (or if the other peer is unresponsive).

More details about the new arbitration model: [1]
[https://bisq.wiki/Dispute_resolution#Level_3:_Arbitration]
Suggested change:

Replace penultimate paragraph with:

Mediation is expected to be the optimal resolution for both traders. If the trade goes to arbitration the arbitrator will payout out the trade amount plus one peer's security deposit. This means the total arbitration payout will be less than the mediation payout. Both traders agreeing to the mediator's suggestion is the happy path. Requesting arbitration is meant for exceptional circumstances, such as one peer not responding, or if a trader is sure the mediator did not make a fair payout suggestion.

Could you use the full text as here for your suggestion? Was not totally sure where to insert it.

portfolio.pending.mediationResult.popup.info=The mediator has suggested the following payout:\n\
  You receive: {0}\n\
  Your trading peer receives: {1}\n\n\
  You can accept or reject this suggested payout.\n\n\
  By accepting, you sign the proposed payout transaction. \
  If your trading peer also accepts and signs, the payout will be completed, and the trade will be closed.\n\n\
  If one or both of you reject the suggestion, you will have to wait until {2} (block {3}) to open a \
  second-round dispute with an arbitrator who will investigate the case again and do a payout based on their findings.\n\n\
  The arbitrator may charge a small fee (fee maximum: the trader''s security deposit) as compensation for their work. \
  Both traders agreeing to the mediator''s suggestion is the happy pathâ��requesting arbitration is meant for \
  exceptional circumstances, such as if a trader is sure the mediator did not make a fair payout suggestion \
  (or if the other peer is unresponsive).\n\n\
  More details about the new arbitration model: [HYPERLINK:https://bisq.wiki/Dispute_resolution#Level_3:_Arbitration]

pazza83 · 2022-12-10T00:25:02Z

Could you use the full text as here for your suggestion? Was not totally sure where to insert it.

No problems:

portfolio.pending.mediationResult.popup.info=The mediator has suggested the following payout:\n\
  You receive: {0}\n\
  Your trading peer receives: {1}\n\n\
  You can accept or reject this suggested payout.\n\n\
  By accepting, you sign the proposed payout transaction. \
  Mediation is expected to be the optimal resolution for both traders. \
  If your trading peer also accepts and signs, the payout will be completed, and the trade will be closed.\n\n\
  If one or both of you reject the suggestion, you will have to wait until {2} (block {3}) to reject mediation suggestion, \
  which will open a second-round dispute with an arbitrator who will investigate the case again and do a payout based on their findings.\n\n\
  Mediation is expected to be the optimal resolution for both traders. \
  If the trade goes to arbitration the arbitrator will payout out the trade amount plus one peer's security deposit. \
  This means the total arbitration payout will be less than the mediation payout. \
  Requesting arbitration is meant for exceptional circumstances. such as; \
  one peer not responding, or disputing the mediator made a fair payout suggestion. \n\n\
  More details about the arbitration model: [HYPERLINK:https://bisq.wiki/Dispute_resolution#Level_3:_Arbitration]

edited to include @MwithM's feedback.

ghost · 2022-12-11T16:13:06Z

desktop/src/main/java/bisq/desktop/main/dao/burnbsq/burningman/BurningManView.java

+                    .map(balanceEntry -> new BalanceEntryItem(balanceEntry, averageBsqPriceByMonth, bsqFormatter, btcFormatter))
+                    .collect(Collectors.toList()));
+            // 108869: 617 - 1878, 640-1531
+            log.error("balanceEntryObservableList setAll took {} ms size={}", System.currentTimeMillis() - ts, balanceEntryObservableList.size());


Debugging statement accidentally logged as an error?

Ups, will remove...

We will use that for the optional address field in compensation requests and interpret empty input as Optional.empty. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

We cannot add a new field as that would break DAO consensus. Add optional text field for burningManReceiverAddress to CompensationProposal UI. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Will be used later by BurningMan domain. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>