Use new burningman accounting file recreated from scratch.

[HenrikJannsen]

Use new burningman accounting file recreated from scratch.
Remove old file.

The current accounting data are missing about 10% of transactions due to threading issues at processing the transactions in earlier versions.

[alvasw]

ACK
The numbers are close to the values from my full node.

[ghost]

The BM BTC received amount shown is slightly higher than the real amount received. Any ideas why?

[HenrikJannsen]

The BM BTC received amount shown is slightly higher than the real amount received. Any ideas why?

Have you checked if there was payments to the Bisq internal addresses (either BTC or BSQ wallet).
Another reason can be that false positives interpret a transaction wrongly if there have been other transaction related to the address. The DPT has less risk to get false positives but the fee tx has as its has less metadata we can check, only amount range and some other properties.

[ghost]

Have you checked if there was payments to the Bisq internal addresses (either BTC or BSQ wallet).

It seems to be this. A BMs receiver address is sometimes chosen from a seemingly random DAO comp cycle. In my case from cycle 36 and 41. Only 2 transactions out of several thousand, all the rest went to the specified custom address. I checked some other BM and they exhibit the same quirk.

Not related to this particular PR though.

[HenrikJannsen]

Have you checked if there was payments to the Bisq internal addresses (either BTC or BSQ wallet).

It seems to be this. A BMs receiver address is sometimes chosen from a seemingly random DAO comp cycle. In my case from cycle 36 and 41. Only 2 transactions out of several thousand, all the rest went to the specified custom address. I checked some other BM and they exhibit the same quirk.

Not related to this particular PR though.

I guess that can happen for trade fees if users do not have the correct DAO data (comp request with the external address).

[alejandrogarcia83]

utACK