Bisq2 MuSig protocol

[HenrikJannsen]

The proposal for the Multisig-based trade protocol for Bisq2 looks very promising. Assuming no major showstoppers arise, we can anticipate this will be the path for the protocol implementation in Bisq2.

This document aims to discuss open conceptual questions and outline the next steps.

Open Conceptual Questions

Trade Fee Payment

We would like to avoid direct trade fee payments from traders to the DAO (via distributed Burningmen) to mitigate friction in the protocol and prevent privacy degradation (since BM receivers are known addresses that can be traced back to the trade transactions). Possible alternative options include:

• Using LN: This has the drawback of creating a dependency on LN both technically and from a user perspective.
• Using burned BSQ (or paying bitcoin to BM who issue "BSQ tickets") to pay for network usage (makers).
• Donation at completed trade: This could potentially serve as a form of reputation if implemented in a privacy-protecting way.

Avoiding the Requirement for Makers to Be Online

We aim to eliminate the need for makers to be online. Once the protocol is more refined, we can better analyze alternatives to the interactive process that requires both parties to be online at the offer-taking time. One possibility is for a maker to prepare all non-security relevant data and delegate the interactive process to a relay node, though the feasibility of this is uncertain.

Managing/Reserving UTXOs for Deposit Transactions of Makers

In Bisq1, the trade fee transaction prepares the required amount for the trade as a UTXO, which is reserved in the wallet. This approach has liquidity issues as makers with many offers need to have those funds blocked. Since we aim to reduce the number of transactions and avoid the trade fee payment, this option is unlikely for Bisq2.

Managing the wallet to always fulfill any open trade could be challenging, considering the uncertainties of miner fees and input UTXO fragmentation. We could adopt a "negotiation" phase where required funds are checked and temporarily reserved for a potential trade, which might also offer flexibility with payment methods and price.

Alternative Options to Sending Funds in Arbitration Cases to the DAO

In Bisq1, most arbitration cases result from non-responsive sellers. This issue will be resolved by the atomic swap in the new protocol and the new staged payout protocol update in Bisq1. Assuming real arbitration cases are rare, we could consider donating traders' funds to organizations beneficial to Bisq, such as Tor, I2P, and Bitcoin donation funds.

While there is a risk of abuse by those interested in increasing donations to these receivers, the security deposit loss and potential measures (e.g., letting the seller select the receiver or splitting donations among many) should mitigate this risk. An open question is whether these donation receivers are okay with receiving funds from a trade platform, but this should generally not be an issue due to the improved privacy.

Alternatively, we could flag if funds should go to the DAO via the distributed BM or to donation receivers. In case of unexpectedly high arbitration loads and costs to the DAO, we might need to fall back to avoid excessive financial loss. A more radical option would be to not reimburse users at all, clearly stating that if a trade fails in arbitration, the funds are donated. Lower trade amounts could make this more acceptable, and repeated trades can address the need for higher transaction volumes.

Next Steps

Refine, Analyze, Develop Protocol

We invite anyone with experience in protocol development and cryptography to review, analyze, and help implement the proposed protocol. This protocol is more complex than Bisq1's and uses cutting-edge cryptography. Alongside conceptual and cryptographic challenges, we must ensure a robust and secure engineering pattern for implementing the protocol. While our FSM-based framework has worked well for Bisq Easy, its limitations make it uncertain if this approach suits a more complex protocol, especially with alternative path handling.

Define Requirements for Wallet Library and Integration

We have support for bitcoind and Electrum, though Electrum may not meet our requirements. The MuSig protocol will require extra libraries, available with JVM bindings. Managing secret keys in a non-typical wallet manner (non-HD wallet keys) for security reasons necessitates checking for wallet library support for custom key management.

For flexibility and higher security, we should run the wallet in an independent process, a model we already use for Tor, I2P, bitcoind, Electrum, Elements, and the new Webcam app. This approach allows us to use any non-JVM wallet and reduces security risks if the main Bisq app is compromised. We need to ensure the wallet is clearly separated into key-management/storage and blockchain interaction layers. BDK seems a promising candidate for this. Initially, we could use public Electrum servers supported by BDK for blockchain interaction and later improve with using Compact Block Filters and custom solutions for retrieving mempool transactions of interest.

Decide on Payment Accounts Model

This depends on some previous open questions. In Bisq1, the requirement to reserve funds in the wallet limits liquidity for power traders wishing to create many offers in different currencies without locking up too much funds. We added support for reusing UTXOs and maker fees for multiple offers in Bisq1. Another approach might be making payment account handling more flexible, though it increases code and UX complexity.

If we do not have a maker trade fee and do not require UTXO reservation for an offer, this problem might be resolved, eliminating the need for a complex account model. We want to make Bisq MuSig as "easy" as possible.

Develop Basic UX for Offer Book and Trade Protocol

We should start integrating the new protocol into Bisq2 from a UX perspective, addressing UI elements in parallel to protocol work to identify and resolve potential issues early. We can build on elements from Bisq Easy, like the trader process, and adopt an offer book style similar to Bisq1. Completing the wallet UI independently of the wallet library implementation, based on existing bitcoind or Electrum wallets, should also be a priority.

[stejbac]

It isn't entirely clear to me how the proposed single tx protocol solves the problem of the seller going AWOL, at least after the buyer starts payment but before the atomic swap at the end. If my understanding is correct, the main purpose of the swap txs is to deal with the impossibility of an atomic information swap (in this case, of the private keys at the trade close), and thus one has to have an on-chain fallback. (Though, I think only one swap tx is required, not two, as I commented on bisq-network/proposals#456.)

I believe that if the aim is to punish the counterparty (without third party involvement) for going AWOL, and not just simply claim your own payout, you have to have some kind of warning txs, like those in the Bisq 1 v5 trade protocol. This is because there is no way to tell the difference between the buyer or the seller having gone AWOL just from the information on the blockchain, and it is the sending rather than the receipt of information (that is, the buyer confirming payment start) which shifts the culpability to the counterparty. But you cannot ever benefit from the sending of information, unless it takes the form of a transaction broadcast, which would probably end up being some kind of warning tx.

[ChrisSon15]

It isn't entirely clear to me how the proposed single tx protocol solves the problem of the seller going AWOL, at least after the buyer starts payment but before the atomic swap at the end.

In my recent post In tried to merge the ideas from #421 into Single Tx protocol. Please have a look. Also on a downside of the merge, If Alice is knowingly unresponsive Bob can steal the funds, becuase the protocol cant distinguish between pre-key-exchange and after-key-exchange.

[stejbac]

Yes, sorry, I was just a bit confused because it seemed to be claimed above that the atomic swap (without merging the ideas for the Bisq 1 v5 trade protocol) would mitigate the problem of a trader going AWOL before trade close and wanting to receive payout without going though arbitration, but I couldn't follow that.

Regarding the danger that both the warning tx and the claim tx could be used under the nose of the peer after the trade has closed and been forgotten about, requiring continual post-trade observance of the blockchain (much like in lightning), I suppose one could set up lightning-style watchtowers to automatically punish such abuse. I can't really think of any other solution to the problem, if one wants a third-party-free means to claim payout in the event of unresponsiveness. You could send the necessary encrypted data to the watchtowers at the trade close, which is off-chain in the happy path, so it couldn't be correlated with any on-chain activity, giving hopefully reasonably good privacy.

[ChrisSon15]

Good idea with the watchtowers. Every Bisq node could be a watchtower. After Key exchange Bob and Alice would encrypt send their ClaimTx to the bisq network, where each node acts as a watchtower. The 'Watch-message' would have the Warning Tx -id as unencrypted data. The ClaimTx would be decryptable by the pubkey U_{A or B}. That pubkey U_{A or B} will appear in the Warning transaction itself. So the watchtower looks for a txid once a day, if found can decrpyt with the public key found in the WarningTX itself. And then post the ClaimTx. Will produce some network traffic. may be not every node needs to check all messages. Also needs some cool logic of purging old message, which are not relevant any more. But would be pretty privacy preserving, as the Warning txid doesnt reveal interesting information and the probability that a WarnngTx real appears is close to zero.

[stejbac]

There's a concern, I guess, with DoS attacks if we use watchtowers, as the warning txIds to watch for wouldn't be tied to any particular UTXO, for privacy. So they couldn't be automatically purged, except with a (presumably very long) timeout. I suppose it could be mitigated to an extent by using PoW (or some other kind of rate limiting).

If there are assumed to be at least N honest watchtowers in the network, then each would have to store roughly one Nth of the entire dataset of txIds and associated encrypted claim/punishment txs, I think, regardless of the number of Sybils in the network. So even if the network was almost entirely Sybils but there were 100 honest nodes, then each node could store something around 100th of the entire dataset (which could be mostly spam), and then maybe that wouldn't be too bad.

[HenrikJannsen]

Yes, sorry, I was just a bit confused because it seemed to be claimed above that the atomic swap (without merging the ideas for the Bisq 1 v5 trade protocol) would mitigate the problem of a trader going AWOL before trade close and wanting to receive payout without going though arbitration, but I couldn't follow that.

Sorry was my initial misunderstanding... Yes, we need a Bisq1 like stage payout scheme as well, as you suggested at the proposal.

There's a concern, I guess, with DoS attacks if we use watchtowers, as the warning txIds to watch for wouldn't be tied to any particular UTXO, for privacy. So they couldn't be automatically purged, except with a (presumably very long) timeout. I suppose it could be mitigated to an extent by using PoW (or some other kind of rate limiting).

In Bisq2 each message requires proof of work where the difficulty is calculated by the cost factor of the message and the load factor or the receiving peer. Under ddos the load factor goes up and with that the required pow cost. We could try to design a similar model here so that the pow cost goes up with the number of txs, making spam more expensive when intensifying.
not the solution for all kind of ddos attacks but should mitigate some at least.

[ChrisSon15]

@HenrikJannsen regarding nexts Steps.

refinement of the protocol:

I am looking detailing / exploring the protocol more. next steps here include

• finding suitable libraries (also in regards to their maturity)
• and deciding on which ones to use.
• finding project which use them
• write some test code to actually get to know the API.
• Playground to test
• verification of protocol by others

re wallet integration

Probably dependent in the refinement of the protocol, then we know exactly what we need and how to integrate.

re Fee Payment

For the maker we could also introduce a listing fee, he has to pay a fee to get the offer listed, that prevents spam and needs to be validated by other Nodes.
for the payment itself, this needs to be thought through in an own thread, I guess. There are a lot of possibilities as you mentioned and more (LN, Liquid, unidirectional payment channels,..)

UX for Offer Book and Trade Protocol

can / should be developed asap. But detailed protocol and fee payment need to be finalised.

[HenrikJannsen]

Here is an additional idea regarding Trade Fee Payment which also would add additional security properties:

We could reuse the reputation model of Bisq Easy where burned BSQ is the main revenue source.
To create enough incentives for traders to invest in reputation we could map it to max. allowed trade amounts (as done for Bisq Easy v2.1.1). Buyers and sellers would have the same incentives here as the security model is not based on sellers reputation, though reputation adds some extra level of security to both. Creating a model where both sides require reputation doubles the potential revenue from "fees".

Both buyers and seller could have a free tier where they can trade say, up to 100 USD. There might be some warnings that reputation is absent and therefore lower amount limits are applied.

For higher amounts, both traders require a certain reputation score.
The metrics and algorithm how we apply reputation score to trade limits need to be figured out to find a good balance.

The reputation score should be usable for both protocols (and maybe more in future).

The benefits of that model are:

• No need to add fee payment to the trade protocol
• No need for Burningmen
• Burned BSQ are the most direct revenue source for the DAO

The drawbacks are:

• User need Bisq 1 for acquiring BSQ and burn BSQ [1]
• Reputation is bound to a profile. Users who prefer to have multiple profiles for better privacy would need multiple investments in reputation.
• BSQ is potentially less private as Bitcoin
• If Burningman do not receive BTC fee payment but only payments from trades ending up in arbitration, their profitability is reduced. But as those changes are not happening fast, they can adopt and start to invest less once the decision and timeline is more clear.

[1] There might be a BSQ "shop" to mitigate that requirement. E.g. user send BTC to a shop to get reputation added to their profile.

[pazza83]

I have reservations with this approach.

I think some of the drawbacks are:

• Decrease in revenue from trades (currently we aim for 0.8% of the total traded).
• Forcing people to use BSQ for trading does not seem like a good idea.
• I like the simple approach of a fee per trade. Not having this decouples trade revenue from trade volume which I think will result in reduced revenue.
• I do not see why a user should have reputation to trade when they have funds in a multisig securing the trade. Bitcoin multisigs are an amazing way to allow two strangers to trade with each other safely. I do not think BSQ reputation is needed to improve this. If anything it just makes it worse from a privacy and accessibility perspective.
• I do not like the idea of investing in purchasing BSQ to use the platform to sell larger amounts, when those amounts are already secured by a multisig.

I also do not see why there would there be no need for burning men in the model. What happens to trades where both peers want to go to arbitration? This model removes 95% of the arbitration cases where there are non-responsive peers. But what about the 5% where there is an issue. This bitcoin in the multsig presumably needs to be sent somewhere?

I think my preference would be to separate the bitcoin trade fees from the delayed payout transactions (DPTs).

We could then open up the burning men protocol to any BSQ holder to burn BSQ to participate in the fee lottery. The 11% cap could also be removed. Once the new protocol is in place the trade fees would make up >90% of the revenue.

What to do with the trades that do go to arbitration is a little bit harder to open up due to the risk of users self trading. Maybe the DPTs could still go only go to contributors that burnt BSQ and the 11% cap remains in place. Once the trade protocol has changed however this indirect 'revenue' source will be a lot less significant than it currently is.

[HenrikJannsen]

* Decrease in revenue from trades (currently we aim for 0.8% of the total traded).

Goal would be to tune the system so that we arrive at similar revenue. But I agree it is harder to predict and harder to control.

* Forcing people to use BSQ for trading does not seem like a good idea.

I agree that requiring Bisq 1 for buying and burning BSQ is a point of friction, but as mentioned I guess that can be mitigated by a kind of "shop" system where users can buy reputation with BTC/LN or whatever the shop accepts. This is purely optional for those who don't want to use Bisq 1.

* I do not see why a user should have reputation to trade when they have funds in a multisig securing the trade. Bitcoin multisigs are an amazing way to allow two strangers to trade with each other safely. I do not think BSQ reputation is needed to improve this. If anything it just makes it worse from a privacy and accessibility perspective.

Yes it is not needed for security, but it adds extra security. The security deposit is important part next to MuSig and that could be coupled with the reputation and lowers capital requirements for pro-traders who have high reputation. E.g. a 5000 USD trade which would normally require say, 15% of deposit (750 USD) could have reduced 5% deposit (250 USD) if the user has say 100k rep score (1000 BSQ burned/1800 USD invested). It cannot replace deposit as that is per trade and with reputation we dont know number of parallel trades, but it can be reduced. I think pro traders, specially those who already trade on Bisq Easy would greatly benefit from that.
It would also incentivize traders to become also sellers on BE if they have anyway reputation built up for higher limits on MS.

* I do not like the idea of investing in purchasing BSQ to use the platform to sell larger amounts, when those amounts are already secured by a multisig.

As said its also the deposit.
Its a common model in e-commerce to limit features (like ChatGPT limits num of prompts in free tier) and allows usage without financial barrier and makes it more attractive to try out. Once a real value has been generated for the user they might be ok to invest how much they like. And in that model they are totally free about the pace and scale if their investment. They could increase with each trade their score/limit by the fee amount they would usually pay in bisq 1.

I also do not see why there would there be no need for burning men in the model. What happens to trades where both peers want to go to arbitration? This model removes 95% of the arbitration cases where there are non-responsive peers. But what about the 5% where there is an issue. This bitcoin in the multsig presumably needs to be sent somewhere?

Sorry I was not clear about that above. I referred only to the fee part for the BM. Yes the BM model is still needed for DPTs.

The motivation for this proposal is de-couple the trade fee from the protocol as it would reduce a lot the privacy gains of the new MuSig protocol. The trade tx would become very easy detectable as the fee receivers are known addresses.

For the DAO its more profitable as the BM need to make a profit to incentivize them for their upfront risk of investment. It would make it also more decentralized as no BM is needed to convert BTC into BSQ but traders do it themself, and in case they use the "shop" - they can batch their fee payments which improves privacy and lowers overall friction.

Do you have any other idea how we could deal with the fee payment issue? Using the same model as Bisq 1 will come with several drawbacks as discussed:

• trade tx become easily detectable
• depending on impl. it might add a new tx or at least extra costs for miner fee
• BM are more expensive for DAO, + BM has miner fee and costs for CJ for consolidating many small inputs.
• Smaller group of BM compared to DAO stakeholders

[HenrikJannsen]

Discussion about the fee model is delegated to #2922

Lets stick here to the higher level discussions.

One missing part not mentioned yet is the support for:

• Account age
• Signed account age witness

Both have dependency on the account and the relevant fields used there. When we design the payment account model for Bisq 2 we need to take that into account.
The data for Bisq 1 account age is currently about 9 MB and for Signed account age witness about 20 MB. This is quite large and we need to figure out how to can avoid to overload Bisq 2 network with those data. One way could be to only transform those data to Bisq 2 via the oracle node on demand for active users. Assuming that a high percentage are stalled that should reduce the load by quite a bit. If this is enough have to be seen.

To avoid the scaling issues we should consider a different storage model, e.g. to add a TTL to data which do not have dependencies, but it has to be seen if that is feasible (its a multi-tree-like structure and for verification the root nodes are needed even if those are from inactive users). Maybe some cut-through approach can be applied to reduce the depth of the structure.
Alternatively we could start form a new data structure and use imported signed account age witness as new root nodes. This would add some trust to the oracle nodes but should not be a security risk as fraud is detectable.

Furthermore the Signed account age witness implementation need to be re-implemented in Bisq 2. This is a large and complex code base and should not be underestimated. I guess the code base is largely in a good quality and most can be copy-pasted with minor effort to resolve dependencies.

A more radical approach would be to drop the Signed account age witness model and use reputation as replacement for security against charge-back. This would remove a complex system and the load of data for supporting it (even if we restart the data model it will hit scaling issues at some point again).