Distributing burningman data to Bisq 2 in a resiliant way

[HenrikJannsen]

We need the Burningman addresses and receiver shares for the Musig fee payment and the delayed payout transaction (redirect tx in musig).

For the fee payment is smaller amounts and its not that critical if that data is missing or incorrect as damage is limited.

For the delayed payout transaction (DPT), though it is has severe security implications.

The (currently) 2 oracle nodes request those data from Bisq 1 and will publish it to Bisq 2 network. This data is signed and oracles are bonded roles. As long oracle operators are not malicious or hacked that part is safe.
If oracle nodes would be offline for an extended time it should not become a single point of failure for the trades.
So we want:

• Verification so that in case newly published oracle data is incorrect it is detected
• Resilience in case oracle nodes are offline for extended time (days up to 1-2 weeks).

We publish the BM data only at snapshot heights (as in Bisq 1 for the DPT use case).
The block height is the last mod(10) height from the range of the last 10-20 blocks (139 -> 120; 140 -> 130, 141 -> 130).

This ensure that we do not need to deal with re-orgs and we can be sure that both traders have the same snapshot height even if one has recently received a new block.

We still might have the issue that the traders have a different view on the network data, thus one might have a more recent snapshot block. To resolve that we can exchange in the trade protocol the past x blocks and the peer takes the most recent they have in common.

We will have about 14 such blocks per day as we have every 10 block a new snapshot (144 blocks per day at 10 min average confirmation time).

To solve both goals stated above we can use a time-machine like backup strategy for that data to thin out the data kept in the p2p network with the age of the data. This we will not use the simple TTL strategy but let the oracle nodes delete old data according to that strategy and use a long TTL to cover the oldest to be kept data.

Suggestion for deletion algorithm:

• Age < 1 day: We keep all data (about 14 blocks per day)
• Age 1 day - 10 days: Oracle nodes delete their data older than 1 day so that only one block per day is left: results in 9 blocks left
• Age 10 days - 100 days: Oracle nodes delete their data older than 10 day so that only one block per 10 days is left: results in 9 more blocks left
  TTL is 100 days, so older data are not present.

That way we have
14 blocks with 100 min interval (the 10 block snapshot)
9 blocks with 1 day interval
9 blocks with 10 days interval

We can use that data to verify new received blocks from the oracle if they are similar to the past blocks up to a certain tolerance level.
In case oracle nodes are offline for extended time, we still have up to 100 days of old data which traders can use.

The similarity check could be done by creating a metric for each detected change:
e.g. if same address but receiver share is different by 1 %: add change factor of the old receiver share * 0.01. receiver share is already a % value and all add up to 1.
If a new address is added, add the new receiver share.
If n old address is removed, add the receiver share of the previous block of that address.
This should ensure that bigger impacts are reflected in that change factor. We can see what are common change factors from our historical data and then decide what we put as tolerance level.

[HenrikJannsen]

I implemented that retention policy:
With that we never get more then 28 blocks. first 10 are 10 blocks distance, then next 9 with 100 blocks distance then next 1000 blocks distance. We have then data back to about 70 days.

 public static boolean includeBlock(int chainHeightTip, int blockHeight) {
        checkArgument(blockHeight <= chainHeightTip, "blockHeight must not be higher than chainHeightTip");
        int cutOffHeightMod10 = Math.max(0, chainHeightTip - 100);
        int cutOffHeightMod100 = Math.max(0, chainHeightTip - 1000);
        int cutOffHeightMod1000 = Math.max(0, chainHeightTip - 10000);
        if (blockHeight > cutOffHeightMod10) {
            return blockHeight % 10 == 0; // evey possible snapshot block of the past 100 blocks (about 16 hours);
        } else if (blockHeight > cutOffHeightMod100) {
            return blockHeight % 100 == 0;  // evey 10th possible snapshot block of the past 1000 blocks (about 7 days)
        } else if (blockHeight > cutOffHeightMod1000) {
            return blockHeight % 1000 == 0;  // evey 100th possible snapshot block of the past 10000 blocks (about 70 days or > 2 months)
        }
        return false;
    }
    
    ```

[HenrikJannsen]

This retention policy publishes that pattern at each start of an oracle node. As the start event is undefined and there are multiple oracle nodes, this pattern will get overlayed from other oracle nodes or from restarts. But this does not cause big issues as long the restarts are not happening too frequently and we can add some cleanup routing to delete old data which are too densely populated.

E.g. if the node restarts every 20 blocks, we get a new pattern overlays and have 12 messages with 10 blocks distance instead of 10. The next 100 block distance messages will not be affected. So in worst case we get lot of messages with 10 blocks distance and later also more then the expected 9 for 100 block distance. Data size of AuthorizedProofOfBurnData is about 100 bytes, so I think we can ignore those issues as with even 1000 messages it would be only 100 KB on network data.

[Swotboysandy]

`Thanks for implementing the retention logic - this matches the thinning strategy we discussed.

Retention Behavior Summary

The code keeps snapshot blocks with increasing spacing as they get older:

1. Last 100 blocks

   • Keeps every 10th block (blockHeight % 10 == 0)
   • ≈10 recent snapshots
   • (~16 hours of history)

2. Blocks 100–1000 blocks old

   • Keeps every 100th block (blockHeight % 100 == 0)
   • 9 additional snapshots
   • (~7 days total coverage)

3. Blocks 1000–10,000 blocks old

   • Keeps every 1000th block (blockHeight % 1000 == 0)
   • 9 more snapshots
   • (~70 days of long-range coverage)

Total Snapshots

This results in a maximum of ~28 retained snapshot blocks, which is exactly the intended "time-machine" thinning approach.

Why This Works

• Dense recent snapshots allow strong verification of newly published oracle data.
• Mid-range and long-range snapshots provide resilience for extended oracle downtime (up to ~2+ months).
• Retention stays compact and predictable.

Note

Only small difference from the earlier plan: retention extends ~70 days instead of ~100 days, which is still well within the resilience target.

Overall, the implementation looks correct and fully aligned with the design goals:
Compact storage, high resilience, and safe verification for BurningMan data used in fee and DPT transactions.
`