BurningMan – What Bisq Users Should Know

Support
1

BurningMan – What Bisq Users Should Know

What is claimed?

Bisq says: “Coins are sent to BurningMan addresses and are burned.”

What actually happens?

The coins go to regular Bitcoin addresses controlled by real people. There is no proof-of-burn (no OP_RETURN, no provably-unspendable transaction).

Two types of addresses:

  1. Legacy BurningMan address – hardcoded in DAO parameters (Param.RECIPIENT_BTC_ADDRESS). Whoever has the private key can spend the coins.

  2. Candidate addresses – come from Compensation Proposals in the DAO. These are BSQ holders who provide their BTC address and are voted in by the community. These people definitely have the private keys.

Why is this a problem?

When a buyer doesn’t pay and the seller broadcasts the Delayed Payout TX:

Multisig → Delayed Payout TX → BurningMan addresses
                                (Coins NOT burned!)

The coins are not gone – they went to addresses that could be controlled by anyone. The seller loses their security deposit without receiving anything in return.

How does voting work?

  • You need BSQ to vote
  • Your vote counts proportional to your BSQ stake
  • Voting is “blind” (encrypted)
  • After the voting period, votes are revealed

Recommendations for Bisq Users

  1. NEVER broadcast the Delayed Payout TX directly
  2. Always try Mediation first – but beware: mediators don’t always respond!
  3. Then Arbitration if mediation fails
  4. Only as a last resort use the Delayed Payout TX – knowing that coins go to BurningMan

Important: Delayed Payout TX hex

The Delayed Payout TX (hex) is in the Bisq log (bisq.log). But beware:

  • The TX sends to BurningMan – not back to you!
  • After broadcast: coins are at BurningMan addresses
  • No way back!

Our opinion: The TX should not be in the log at all. It tempts users to broadcast it – which always leads to loss. If mediators respond, the case can be resolved properly. If not (e.g., mediator is sick), the case should be automatically forwarded to another mediator. Coins stay safe in multisig until a solution is found.

Improvement suggestion: Users should see a visible deadline (e.g., 7 days). When it expires and the mediator hasn’t responded → automatically forward to the next mediator. Repeat until the case is resolved.

Technical Details (for developers)

  • DelayedPayoutTxReceiverService.java – selects BurningMan addresses
  • BurningManService.java:204 – legacy address from DAO parameters
  • SellerProtocol.java:161 – setState() allows backward transitions (State-Loop bug)
  • Trade.java:825-839 – setState() warns on backward transitions but applies them anyway

Based on code analysis of Bisq 1.10.4 (July 2026)

BurningMan – Was Bisq-Nutzer wissen sollten

Was wird behauptet?

Bisq sagt: “Coins werden an BurningMan-Adressen gesendet und sind verbrannt.”

Was passiert tatsaechlich?

Die Coins gehen an normale Bitcoin-Adressen, die von echten Menschen kontrolliert werden. Es gibt keinen Proof-of-Burn (kein OP_RETURN, keine provably-unspendable Transaktion).

Zwei Arten von Adressen:

  1. Legacy-BurningMan-Adresse – hardcoded in den DAO-Parametern (Param.RECIPIENT_BTC_ADDRESS). Wer den Private Key hat, kann die Coins ausgeben.

  2. Candidate-Adressen – kommen von Compensation-Proposals im DAO. Das sind BSQ-Halter die ihre BTC-Adresse angeben und von der Community gewaehlt werden. Diese Personen haben definitiv die Private Keys.

Warum ist das ein Problem?

Wenn ein Kaeufer nicht zahlt und der Verkaefer die Delayed Payout TX broadcastet:

Multisig → Delayed Payout TX → BurningMan-Adressen
                                (Coins nicht verbrannt!)

Die Coins sind nicht weg – sie sind an Adressen gegangen, die von wem auch immer kontrolliert werden koennten. Der Verkaefer verliert seine Sicherheitsleistung ohne Gegenleistung.

Wie funktioniert die Wahl?

  • Man braucht BSQ um abzustimmen
  • Deine Stimme zaehlt proportional zu deinem BSQ-Stake
  • Abstimmung ist “blind” (verschluesselt)
  • Nach der Waehlerperiode werden Stimmen entschluesselt

Empfehlung fuer Bisq-Nutzer

  1. Delayed Payout TX NIEMALS direkt broadcasten
  2. Immer zuerst Mediation versuchen – aber Achtung: Mediatoren melden sich nicht immer!
  3. Dann Arbitration wenn Mediation scheitert
  4. Erst als letzten Ausweg Delayed Payout TX nutzen – mit dem Wissen, dass die Coins an BurningMan gehen

Wichtig: Delayed Payout TX hex

Die Delayed Payout TX (hex) steht im Bisq-Log (bisq.log). Aber Achtung:

  • Die TX sendet an BurningMan – nicht zurueck an dich!
  • Nach Broadcast: Coins sind bei den BurningMan-Adressen
  • Kein Rueckweg!

Unsere Meinung: Die TX sollte gar nicht im Log stehen. Sie verleitet dazu, sie zu broadcasten – was immer zum Verlust fuehrt. Wenn Mediatoren antworten, kann der Fall korrekt gelöst werden. Wenn nicht (z.B. Mediator krank), sollte der Fall automatisch an einen anderen Mediatoren weitergegeben werden. Coins bleiben sicher im Multisig bis eine Loesung gefunden ist.

Verbesserungsvorschlag: Nutzer sollten eine sichtbare Frist sehen (z.B. 7 Tage). Wenn diese abgelaufen ist und der Mediator nicht geantwortet hat → automatisch weiter zum naechsten Mediator. So lange bis der Fall gelöst ist.

Technische Details (fuer Entwickler)

  • DelayedPayoutTxReceiverService.java – waehlt BurningMan-Adressen aus
  • BurningManService.java:204 – Legacy-Adresse aus DAO-Parametern
  • SellerProtocol.java:161 – setState() erlaubt Rueckwaerts-Transitions (State-Loop-Bug)
  • Trade.java:825-839 – setState() warnt bei Rueckwaerts-Wechsel, setzt ihn aber trotzdem

Basierend auf Code-Analyse von Bisq 1.10.4 ( Juli 2026)