Hackathon challenge: Fee Payment in the MuSig Trade Protocol

[HenrikJannsen]

The MuSig trade protocol offers significant privacy enhancements by ensuring transactions are indistinguishable from others. Maintaining this attribute is desirable when incorporating fee payments into the protocol.

Current State in Bisq 1

Bisq 1 provides two methods for users to pay trade fees:

• Burning BSQ.
• Paying in Bitcoin, which is sent to a randomly selected Burningman who has previously burned BSQ to qualify as a fee recipient.

In the Bisq 1 trade protocol, fee payments occur in a separate transaction that also reserves the UTXO for the trade. For makers, a data structure ensures the UTXO required for the deposit transaction remains unspent, preventing unintended use that would invalidate a take-offer attempt. The wallet uses this structure to select UTXOs appropriately.

However, fee payments in Bisq 1 leave a traceable on-chain signature:

• Burning BSQ allows observers tracking BSQ transactions to identify them as Bisq trade transactions.
• Bitcoin payments go to Burningmen, whose public addresses enable inputs to be recognized as Bisq trade transactions.

Additionally, on-chain fee payments may become cost-prohibitive as miner fees increase. Furthermore, the protocol seeks to minimize blockchain clutter from small transactions or UTXOs.

Goals for Fee Payment in the MuSig Protocol

The objectives for fee payment integration in the MuSig protocol are:

• User-friendly and accessible, without requiring BSQ acquisition, though supporting BSQ if the user has already BSQ.
• Avoid reduction in privacy.
• Avoid reliance on external wallets or infrastructure, such as Lightning Network (LN) wallets.
• Avoid need for additional infrastructure or integrated wallets, such as an LN wallet.
• Avoid per-fee blockchain footprint, though batched payments or off-chain methods are permissible.
• No centralized fee recipient to preserve decentralization.
• Optional use of the Burningman concept, though not mandatory.
• Verification of fee payment, potentially by the trade peer.
• Minimal burden on the P2P network if employed.

Meeting all these criteria simultaneously may not be feasible.

Currently Discussed Ideas

Silent Payments

Silent payments obscure the Burningman’s role as a fee recipient by using non-publicly known addresses. However, the transaction structure provides observers with subtle clues, slightly reducing privacy—an acceptable compromise in some views. Periodic consolidation by Burningmen, often via CoinJoin, aggregates unidentified inputs, allowing observers to infer these originate from Bisq transactions, thus weakening considerable Silent payments’s privacy benefits.

This approach adds a UTXO to the transaction, incurring lower miner fees and blockchain impact than Bisq 1’s separate transaction. It supports only Bitcoin payments; BSQ payments retain Bisq 1’s privacy issues, as BSQ tracking reveals Bisq trades. No production-ready wallets currently meet Burningmen’s needs for handling numerous small transactions. An open pull request for Bitcoin Core integration exists, potentially available by deployment time of MuSig. Alternatively, Burningmen could use a custom Bitcoin Core build from that branch.

Lightning Network

Requiring Lightning Network (LN) use poses accessibility challenges, as not all users have LN Bitcoin or wallets. Integration is a significant obstacle, as Bisq lacks an embedded LN wallet and faces difficulties in offering a self-custodial LN node (e.g., managing channels, liquidity, watchtowers). Bisq avoids semi-custodial models or dependencies on external providers.

Using an external LN wallet degrades user experience. Payment verification is also problematic; Keysend avoids invoice handling but provides no receipt. Burningmen could share P2P network data for peers to verify receipt, though direct sharing risks exposing onion addresses and leaks trade frequency and amounts to the Burningman. Each Burningman would need an LN node, potentially reducing their numbers, decentralization, and competition, thus raising DAO costs.

E-Cash Systems (e.g., Cashu)

E-cash systems enhance privacy but introduce substantial integration and dependency challenges. These drawbacks halted further exploration.

Coconut (Used by Nym)

Coconut, utilized by Nym for privacy-preserving VPN fee payments, is a potential option. It requires further analysis to determine integration effort and specifics, particularly how users would acquire credentials with Bitcoin.
See: Nym Credentials Overview.

Ticket Model

The ticket model establishes a fee ticket shop where users purchase tickets (via on-chain BTC, LN-BTC, XMR, etc.) as off-chain fee tokens. Users can buy single tickets or batches for multiple trades. It leverages the Oracle node and P2P system, with peers verifying payments, and introduces two new infrastructure components:

• Burn Certificate Issuer.
• Ticket Emitter Service.

These could succeed Burningmen, converting BTC (or other payments) into burned BSQ, with burn proofs transformed into fee credentials. The system remains incomplete, with potential unresolved issues. It adds infrastructure and complexity similar to the Burningman model. To hide the complexities from the user will be challenging but probably doable.
See: #2922 (comment)

Pay for Network Usage

This concept was considered for charging external services for using Bisq’s P2P network. Bisq 2’s proof-of-work (PoW) system already requires minimal PoW per message. Higher PoW for external messages could encourage users to pay a fee (e.g., burning BSQ) to avoid performance degradation.

This could apply to trade fees: users trade for free with significant PoW or pay to bypass delays. Costs, encoded in the trade messages, could scale with trade amounts. However, this unfamiliar approach may confuse users, who might view the network as a public resource, not a DAO revenue source. Addressing this perception requires careful communication.

That idea may need further refinement and creative adjustments to reach the right balance.

Other Options

Sidechains (Liquid, RSK), Statechains, and altcoins with atomic swaps were not pursued due to complexity or lack of atomic swap support.

Alternative Fee Payment Concepts

Alternative models include:

• One-sided fee payment hidden in the price: Used in BSQ swaps, where the seller pays both fees and adjusts the price. This reduces transparency, though UX improvements could address it. In Bisq Easy, sellers indirectly pay via reputation investment, but the question of the fee payment method remains unresolved.
• Subscription model: Similar to batch BSQ purchases in Bisq 1.
• Reputation via burned BSQ.
• Reputation via post-trade donations: Reflected in reputation, though privacy-preserving verification and on-chain payment issues persist.

[HenrikJannsen]

@ChrisSon15 came up at yesterdays MuSig dev meeting with a promising idea: To use unidirectional payment channels between the trader and a Burningman.

Details have to be worked out but so far that seems to be the best solution.
If anyone is interested to work on that please get in touch.

Devs should have experience with:

• MuSig
• P2SH MultiSig
• Silent payment
• Payment channels

Bonus:

• Lightning