Fee models for the Bisq 2 MuSig protocol

[HenrikJannsen]

As the discussion about the fee model in #2439 became more extended I thought its better to create its own discussion entry for it.

Goals

• The fee model should not extend the protocol's round trip messages, number of transactions or increase significantly miner fee costs
• It should not harm privacy of individual traders or DAO participants
• It should not require additional resources, tools or dependencies
• It should have as little friction as possible
• It should be cost effective to the DAO, e.g. avoiding a lot of small transactions with accumulated high miner fee costs.
• It should not decrease the level of decentralization
• It should not require a BSQ wallet and DAO data in Bisq 2 (beside the data provided by the oracle)
• It should not require an external wallet or non Bitcoin wallet

Considered fee models.

• Using Lightning network for fee payment
• Using a similar fee model as in Bisq 1
• Using a reputation based revenue model similar as in Bisq Easy

Using Lightning network for fee payment

Obviously using LN would be a very cost effective and fast way to pay small amount of fees. The problems though are that we would need the infrastructure both on the trader side and receiver side (Burningmen). Follow up problems are how to verify a fee payment and how to dynamically provide the invoices. I am not that familiar with LN, so I will focus on the more obvious hurdles which make it IMO already a show stopper.

Pro

• Fast, cheap transfer
• Acceptable privacy even if Tor is not included for LN nodes (not custodial wallets)

Con

• Requires a LN wallet for traders. Using an external wallet would be bad UX. Integrating a LN wallet would require extra resources and dev effort.
• BM would be confronted with the complexity of running a LN node and doing channel management. It would likely reduce the number of BM who are willing to put that extra effort into it.
• In case custodial LN wallets are used by the trader privacy is degraded.
• Newbies need to acquire Bitcoin on LN and need to learn the basics about LN.

Conclusion

IMO the requirement for a LN infrastructure is too much of a burden at that stage. Later once a LN wallet is integrated for a LN based trade protocol thus hurdle would be resolved and that model could be re-evaluated.

Using a similar fee model as in Bisq 1

A similar model as used in Bisq 1 could be used with some adoptions to not degrade the benefits of the new MuSig protocol.
The fee payment transaction which serves also for reserving the UTXO for the deposit tx in Bisq 1 must be avoided as otherwise we lose the benefit of the 1 tx protocol.

The BM data for receiver distribution can be provided by the oracle, e.g. by publishing at each block the distribution table of the BM. As that is deterministic, multiple oracle nodes would publish the same data and there are no synchronization problems beside the timing of the publishing. This synchronization issue can be resolved by some lenience in the traders verification to exchange not only the most recent distribution table but also the previous one and tolerate if the peer has not the most recent as long there is a match with the last one (could be extended to more than 2 if needed).

The fee payment can be paid in BTC only as there is no BSQ wallet in Bisq 2 at that stage. Thus all the trade fees go to the BM, not only the BTC part as in Bisq 1.

We can improve the BM model to separate the fee payment part with the delayed payout tx (DPT) part to allow to let any BSQ stakeholder become a BM, in contrast to the current model where only DAO contributors can participate as well as remove the 11% cap. Those restrictions are for security reasons in place but are only required for the DPT use case. With such a change the number of BM can grow and the competition for burning can increase which should result in lower costs for the DAO.

The output for the fee payment can be added to the deposit transaction in the protocol. Though here we have a major problem that it destroys the privacy benefits provided by MuSig (which makes fingerprinting of trade transaction unfeasible) as it would be very easy to mark all transactions which lead to a BM address (public data) as Bisq trade transactions. This does not only degrade users privacy but also provides information about the trade volume (Bisq 2 will not use trade statistics).

There could be a model where the user run Bisq 1 with their BSQ wallet to pay the trade fee in BSQ by themself. But this would require some dev work to support that interaction and require the user to run both Bisq 1 and Bisq 2 in parallel and degrades generally the UX. The only benefit would be that it would avoid above mentioned issues but at a grave cost of dev effort and UX.

Another potential improvement could be that BM use xPub keys to generate receiver addresses. How to exactly manage that and how to make it verifiable and what are the security and privacy implications would require more analysis.
Assuming that such an improvement is feasible, it still would degrade the privacy of the deposit tx as it's structure become more easy detectable.

Pro

• Economical model is same as in Bisq 1, therefor does not add risks
• Users know the model and are comfortable with it
• No other currency or Layer 2 solution needed beside Bitcoin which is anyway required for both traders
• Easy to understand for users and fees are linearly correlated to the trade amount

Con

• Degrade the privacy of the deposit tx and in case usage of xPub keys is not feasible for BM, simple chain analysis reveals all Bisq trade transactions and trade volume.
• If the usage of xPub keys is feasible for BM it will require extra implementation effort
• Slight increase of miner fee due the extra output
• BM are not very cost efficient for the DAO and as it is currently its not a very large group, thus posing risks. This could be improved as discussed above by separating the BM models but that would come with considerable dev effort.

Conclusion

IMO this model is only acceptable if the usage of xPub keys is feasible for BM.

Using a reputation based revenue model similar as in Bisq Easy

As already discussed in #2439 (comment) we can explore the option to use the reputation model as revenue source as well as an add-on to security. I will summarize here gain the main idea.

There would be no direct trade fee in MuSig but the max. allowed trade amount would be not only determined by the users signed account age witness (assuming we have a solution to import that from Bisq 1) and the risk of the payment method used, but additionally by the traders reputation. Other as in Bisq Easy reputation of both buyer and seller would be considered and only if both traders reputation is sufficient they can trade a give amount.
To not cause high barrier of entry a free tier is supported, so users without or low reputation can trade up to TBD USD (lets use 200 USD as a starting value, but the numbers need to be evaluated in more details later).

This model is also used now in Bisq Easy v2.1.1 in which we match the max. trade amount to the sellers reputation.

Assuming we use the same algorithm and reputation framework as in Bisq Easy, we can derive the max. allowed trade amount by a simple formula like:

Reputation score / TBD = max. trade amount

Lets use 10 as divisor value (need to be evaluated in more details later). Thus a score of 100 000 (e.g. 1000 BSQ burned) would allow a trade amount if 10 000 USD.
We have to keep in mind that Bisq 1 fee is about 0.8% in total. Lets take 0.5% for both sides for simplicity, thus a trade of 10k USD would cost 50 USD for each trader. With 20 such trades the user has spent 1000 USD.
As said the numbers need to be discussed later more in details, but to me it seems that is not totally out of balance.

We have to consider that high reputation allow users to trade with better price premiums and that there will be some level of competition. Beside that the reputation will have dual use for Bisq Easy and MuSig (and potentially other protocols later).

One question is if a never decaying score would become a problem long term when most traders have sufficient reputation and have no incentive to burn anymore. The competition might be a certain factor that still there might be growth, but its questionable if that is enough. Another aspect is that if Bisq would stall to a static user base it would not be a good sign overall, and Bisq should try to attract new users.
To counter that problem (if it is one) we could add a decay function.
In Bisq Easy we have even a time based boost to double reputation over the first year.
One option to dynamically adjust to that issue would be to make the decay factor dynamic on the metrics of the overall profitability of the DAO (or other related, feasible to measure metrics). The amount of burned BSQ / DAO cycle could be used and a revenue target could be vote on in the DAO (like we adjust fees via DAO voting). If the burned BSQ is below the target the decay gets more aggressive, otherwise it gets more relaxed. That way we could manage the incentives for existing traders who have burned sufficiently that they continue burning over time.
There might be better options and more simple ones... A fix static decay might work as well if correctly tuned.

An additional benefit and incentive would be if we correlate the reputation with the require security deposit. It is a reasonable assumption that users with high reputation are less likely violating the protocol thus a lower deposit is justified. Though we have to be aware that reputation has different security properties. We cannot know how many trades a user is doing in parallel thus dividing the skin in the game but that number. Security deposit is per trade and has not that problem. Thus a certain level of min. deposit need to remain, but I would estimate a reduction from 15% to 5% for a 100k score reputation would be justified.
This would benefit pro traders to whom the locked up capital in deposits is a burden and can be reduced by investing more in reputation.

Furthermore MuSig traders who are initially not interested in Bisq Easy might become more motivated to act as sellers in BE when they have anyway already reputation and they could benefit for free from potentially higher price premiums in BE.
This would serve as another additional incentive.

For the DAO such a model would be beneficial as there is no costs on the BM as middlemen to convert Bitcoin fee payments to burned BSQ. The BM would lose the revenue form fee payments from Bisq 2 (it will take a while until Bisq 1 is totally faded out). They can adopt to that by starting to burn less as it will likely take 6-12 months until the majority of fee payments have dropped (if XMR will get supported initially is an open question). So I think concerns that BM face loss of investment is not justified as there is plenty of time to adopt burn behavior.
Though for the DAO there might be potential loss in the transition period as BM will likely burn less to reduce their risks. It also might impact the BSQ market if more contributors sell BSQ instead of burning and as long the model is not in operation there will be no significant increase in demand, so the BSQ price might get negatively impacted. But those dynamics are very hard to predict as they are all interrelated - e.g. less good trade opportunities might change mind of BM again to burn more again...).

To reduce the role of BM would be overall beneficial to the DAO profitability as well as for decentralization (BM are a smaller group than DAO stakeholders).

One need also to consider that the aggregated miner costs for small fee payments, the costs for consolidation and potentially coin joins for BM adds costs to BM which are delegated to the DAO. A model where users can pay in form of larger batches as in the case when they burn BSQ is more cost efficient.

To avoid that traders need to use Bisq 1 for buying and burning BSQ we could add a "shop" like system which allows traders to top up their reputation directly with Bitcoin (or LN, XMR, or any currency/payment method the shop supports).
Lets call that system RepUp (short for reputation-top-up).

Anyone can run a RepUp service. It's a Bisq 2 node combined with a Bisq 1 node (similar as oracle setup) and require to be a bonded role.
The Tor addresses of all services get published in the Bisq 2 P2P network similar as other bonded role nodes.
They offer an API to request the list of accepted currencies and their rates (how much reputation for x amount of the chosen currency).
A trader who does not want to burn BSQ by themself can select one of the available services and send the amount they want to burn in the accepted currency to the service and will get displayed the amount of reputation score they will gain from that payment. The conversion rate will be different by currency and services and includes the service fee for the service.
As the trader need to pay upfront there need to be some security mechanism (like reputation) to avoid that malicious service run away for traders funds. Beside the BSQ bond we should find a way to show past transactions in a privacy preserving way (to be investigated).
The payment is followed by a message consisting of the profile ID of the trader which will be used by the service for the burn BSQ transaction.
The service once received the payment will start the burn BSQ transaction with the provided profile ID (calling a Bisq 1 REST API). That transaction once confirmed in the blockchain is picked up the oracle node and published to the network in the same way as in case the trader burns BSQ by themself.

For Bisq contributors this might be an attractive alternative to being a BM for trade fees. They could use their earned BSQ to burn on behalf of traders and make some profit for offering the service. Other then in the BM model that is more a predictable risk/profit model. For increased security we could even consider that only DAO contributors are permitted to be a RepUp service.

The effort for that lays from my estimation mainly in the shop-layer side as other parts are already used in similar manners. The role is just another variant of existing roles. The Oracle model has a similar setup of Bisq 2 to Bisq 1 interactions. I guess BitPay server might be a good candidate to explore for such a use case. I have no experience with shop systems or BitPay server, but I guess the dev effort for that should not more then 2-4 weeks.

This was a long read.... lets consolidate the core points.

Summary

• Trades under 200 USD do not require any fee payment or reputation
• For higher trade volume both traders need to have the required reputation
• Requirement for security deposit can be lowered with higher reputation, reducing capital requirements for power traders
• Reputation system is same as Bisq Easy, only the metrics and algorithms used to derive MuSig parameters are new
• To incentivize continuous burning we could add a decay function, either fixed or dynamic (e.g. based on burned BSQ/cycle and voted burn target)
• To not require that traders run Bisq 1 for buying and burning BSQ we can a shop-like system (RepUp), allowing traders to pay in Bitcoin/LN/XMR for topping up their reputation
• Trade protocol has not pollution with the trade fee
• Role of BM will get reduced to DPT from arbitration cases

Pro

• Trade protocol is free from fee payment interference
• No costs for fee or reputation needed for lower trade amounts
• Investment in reputation lowers required security deposit
• Reputation adds some additional level of security
• Adds incentive to become a seller on Bisq Easy
• Higher reputation can come with higher price premium
• Reduce cost for the DAO for BM acting as middleman
• Contributors providing a RepUp service can use that to convert their BSQ to Bitcoin and make some profit from the service fee

Con

• New economic model with uncertainties and risks
• Less straight model and harder to understand (though a typical model used like limited number of prompts in ChatGPT in the free tier model).
• To avoid burden to run Bisq 1 for buying and burning BSQ we need the additional RepUp service
• Traders who want to quickly trade large amounts need high up-front investment (though overall this leads to higher security to keep out potential scammers and motivate traders to lower amount trades and repeated trades - long con game)
• If initial parameters are not well tuned, it might require changes which might upset some users (same for BE, can be mitigated by clear communications that rules are not set in stone)
• Potential loss for the DAO in the transition period due the uncertainties of the BM fade out period and BSQ market dynamics
• Privacy leak for traders using the RepUp service by leaking their profile ID to the payment source (e.g. BTC address). Though for users who are concerned about that they can use CJ or user Bisq 1 themself.
• Some users might prefer to stick with Bisq 1 if they want higher amounts with fees per trade. This might be actually a good measurement if our parameters are well tuned and if MuSig protocol and Bisq 2 adds sufficient value to do the transition. It can be seen also positive that Bisq 1 might have for longer a use case for certain types of users (beside BSQ and altcoin trading).

Conclusion

I think the main benefit of that model is the decoupling from the trade protocol and the flexibility as well that it merges with Bisq Easy (and potentially other protocols). The main burden to deal with BSQ can be mitigated by the RepUp service.

The core downside is the risks due that change of the economic model. Though its similar like in Bisq Easy and there it surpassed at least my expectations. More BSQ than expected got burned and many users repeatedly burn, which shows that it works for them. It was clear that Bisq Easy will not generate considerable revenue.
The economic risks for Bisq can be mitigated by dynamic factors, adding a decay fucntion and open communication that things need to get adjusted over time until it works well for both sides.

Combinations of both

We could also consider to combine the latter 2 models to reduce risks and give user more flexibility, similar as with having the option to pay the fee in BSQ in Bisq 1.

We could take into account the degradation of privacy for users who prefer the traditional fee payment (both sides), thus it would not require changes in the BM model with xPubKeys as users with higher privacy preference can simply choose the reputation model.

For the reputation model it would reduce the risks on the economic side as well as on the acceptance side and give more flexibility to traders to choose which model fits best for their profile.
If combined we could also at least initially drop the requirement for he RepUp service, as users who prefer convenience can opt in to the traditional fee model (with degraded privacy).

The main downside is that it adds more dev effort to support both models and that it partition the market as the traditional fee model degrades privacy for both sides (though that could be maybe handled by UX, e.g. let users choose to accept both models).

Pro

• Combines the benefits of both models and let the user the choice which one fits best to them
• Reduce risks if one model turns out to be problematic
• Relaxes the requirement for extra efforts to mitigate some issues with the models (e.g. no mandatory need for BM xPubKey support, no mandatory need for RepUp service)
• Less severe impact on BM model

Con

• More effort (though as the extra features are not hardly required that might be balanced out)
• Might partition the market to some extent
• Adds overall complexity

Conclusion

The combination of both models seems to me the winning strategy. Once LN is integrated we could also consider to allow LN as another fee model. The overall theme of Bisq 2 to leave the user the choice for different options with different trade-offs applies here as well and it feels natural to support multiple fee models. The offer domain has already a FeeOption class for allowing different models (was designed with BTC, BSQ fee in mind).

Maybe there are other alternative ideas. If you have any, please share. For those who are more experienced with LN and know the details of Bisq's tech base sufficiently to judge the feasibility of the LN option, please share your opinion. Maybe my negative conclusion is drawn from my limited LN experience.

[suddenwhipvapor]

Lightning

A lightning node is actually not that cumbersome to install, at least for someone who has a full btc node running already, plenty of guides and pre-made scripts. The biggest issue I see is that to receive payments, you need to have inbound channels, and those can be hard to come by if your node exists only to receive payments and has to source inbound liquidity by itself. Besides, all implementations support connecting through tor only, as long as you setup the relevant option, which will make the node much slower as a router, but receiving payments will not be penalized, as long as you provide to always be online.
I guess the lightning model will need a central Bisq node that receives the fees from the traders and then relays them to the BMs, in which case this Bisq node could open private channels to the BMs nodes (solving the issue for BMs to find inbound balance) and push the balance to the other side as fees arrive, which would cost nothing in LN fees as BMs would be direct peers. This would in turn require Bisq to allocate a certain amount of funds to open said channels, and when the balance to the BM was all sent to him, this central node should automatically close the empty channel and open a new one with fresh funds. Said BTC funds could be allocated by a bonded role who runs the node, much like it happens for RA.
This is not by any means complicated to setup, payments to BMs could be done with simple keysends rather than invoices, and fee payments from traders would be received by Bisq node using invoices generated on the fly.
Something to additionally consider is that a LN node for Bisq would probably be a favourite target for other nodes on the network to open channels to it, given Bisq brand reputation, and will probably be needed anyway once the LN trading protocol is added to Bisq2.

Bisq1 model

I started thinking about using an xpub before noticing you already had listed that option.
Still, a transaction where there is a small output other than the mining fee, often for very similar amounts, even if to a different address each time, could still be to some extent marked as "suspicious bisq trade". Then, the receiving BM will consolidate those small outputs from different addresses all together (as it would be necessary doing at some point) so while there are no publicly known BM addresses used, this would but require an additional step for a chainalyzing party to break. The only privacy advantage left, is that those fee payments wouldn't all be linked together, but rather in batches of consolidation as time goes by. But unless those consolidation batches go each into a different coinjoin, they will end up being further consolidated down the line until the whole list of fees paid to a BM will be linkable.
As usual with privacy matters, aims need to be established. A privacy conscious trader will mix his outputs no matter what, so even if the single trade is identifiable on the blockchain, it will not lead to anywhere linkable. What I have seen users caring about, is not linking multiple trades of theirs together, rather than not making it show there was a bisq trade. In this matter, using btc utxos for fees that are not linked between themselves is a strong mitigation, but lightning is even better.

Reputation

My personal conviction is that, without decay/increasing target, the returns for the DAO would become insufficient in the medium term, and with decay/increasing target in mind, even more "normal" users would be scared by the protocol than the no-decay version, and this would happen unless the free-tier is increased to an amount large enough that would in turn even further decrease the DAO returns. As you observed though, this is all to be seen, as you cannot exactly guess the reaction of the users ahead of time, with so many variables being involved.
Regarding the rest, while I understand each element of your schema, and it shows an indeed complete strategy, it carries a very great deal of complexity, with decaying reputation, variable target, bisq1+bisq2 setups, RepUp shops (which would require BMs to setup a system that is not easier than a LN node in my opinion, while being much more niche than a LN node), bonded role for shop owners, reputation for bonded shop owners, market strategy to sell the burning service in order to maximize returns... I was at the same time impressed by the architecture of the system, and also made uncomfortable by it.

Combination

The probability of a market split could become higher than one would think, because the requirements of the Reputation model are not just for the seller, as in BE, but for both. So the probability that a trade will not happen in one platform is actually doubled, as any one of the two peers could have reason to not choose that one version of the trade model but rather the other one.

Conclusion

I would prefer to have the existing model in place, even if with some modifications as you listed, but I think an evaluation of the old BM model vs its suggested evolution should be considered in relation to what BMs themselves prefer.
Lightning is a not-so-close second, if the Bisq LN node is the one opening private channels to BMs and pushing fees over.

[HenrikJannsen]

Re LN:
Thanks for the input. To add central fee receiver node would be a degradation for decentralization and risks (similar as old BM). We should not get back to old problems which got solved already.
But my main point is that as long we don't have a LN wallet integrated the UX is IMO a no-go. If users need to use their external LN wallet to pay the fee, the trade process would be a mess, and we need to verify that, as if not automatically done by the app not paying the fee would be way too easy.
All this changes of course when we have LN, but I guess that will not happen before 1 year more has passed and to add the requirement to add also a LN wallet for MuSig is an overkill and would delay MuSig considerable. We even don't have a concept yet how a non-custodial LN could work in our environment (assuming most users will not run their own LN node).

because the requirements of the Reputation model are not just for the seller, as in BE, but for both

This is not said that this is required. It would require further detail analysis but I assume it is possible that users with diff. fee models trade with each other if they agree to accept the other model (as it has also security implication).

UPDATE: The privacy implications when using the Bisq 1 like fee model will not affect the other trader if he use reputation as there will be 2 separate deposit txs for each trader from the latest version of the protocol:
bisq-network/proposals#460

Example:
Lets assume Alice has reputation of 30k allowing him to trade up to 3000 USD.
Bob does not use reputation but pays fee by trade.

Alice is restricted to trade never more then 3000, but Bob can trade whatever amount we allow as max. limit.
If they match for a trade, Alice would NOT suffer from the privacy degradation as her deposit tx does not contain a fee output.
Bob would have degraded privacy.

The security implications will depend on the details, but if we assume the min. deposit is lower when using reputation, Bob need to consider if that different security model fits his preference. But I assume most users would not care about that too much and will not have spent enough time to understand the nuances in that regards. If we apply those changes carefully the impact should be rather minimal anyway.

So there is a trade off between privacy and fee payment strategy (one cannot say whats cheaper as it depends on the trade profile).

But overall I agree that some form of partitioning of the offers are produced by that. But that also apply to signed account age witness or payment methods. This does not mean that we lightly should add more factors for partitioning...

decaying reputation, variable target, bisq1+bisq2 setups, RepUp shops

decaying reputation: Is technically simple, its just UX and harder to get a intuition for it. BE had initially decay built in.
variable target: that depends on the solution. the most simple would be to adjust the values by security manager as we did with min req. rep score. In that case its also simple.
bisq1+bisq2 setups, RepUp: bisq1+bisq2 setups is only needed for RepUp and not related to BM. I just mentioned that this could be a new replacement for contributors being BM. But as long there is one RepUp the system would work. And its not mandatory in the combined model, as users who dont want to run Bisq 1 and buy BSQ can use the fee model (similar as in Bisq 1 with BSQ fees).

[suddenwhipvapor]

Thank you for taking the time to explain.
I have to admit it, when pressing "Comment" I had the uneasy feeling that a central Bisq LN node, while technically unsurpassable by any other standard as a means of fee distribution, was actually an issue because of centralization.

As a prospective candidate for a shop owner, I would have to carefully consider the weight of the required bond and maybe the additional cost for needed reputation, as both of them would probably be a high bar to entry for competition. Running a service just for that is not an issue per se, on the other side. I guess the bond could be small enough to cover for the first few trades, while reputation is built up, and reputation itself could be build by the number and size of past transactions? Or would this still be vulnerable as in BE because of the possibility of self trades by a malicious party?

Alice would suffer from the privacy degradation as her deposit tx does not contain a fee output.

did you mean "would not suffer" here? Alice is the one using the reputation fee model,where Bob uses the traditional fee model.

If the combination allows for traders to pair up even across different fee models, that's more flexible than I expected.

[HenrikJannsen]

Still, a transaction where there is a small output other than the mining fee, often for very similar amounts, even if to a different address each time, could still be to some extent marked as "suspicious bisq trade". Then, the receiving BM will consolidate those small outputs from different addresses all together (as it would be necessary doing at some point) so while there are no publicly known BM addresses used, this would but require an additional step for a chainalyzing party to break. The only privacy advantage left, is that those fee payments wouldn't all be linked together, but rather in batches of consolidation as time goes by.

Yes, I agree and this makes the xPub key mitigation less effective as privacy protection mechanism.
Beside that, as @stejbac mention we should try to avoid those many small utxos as those are harmful for the blockchain and are not future proof (at some points if Bitcoin is successful mining fees will be higher than the value of those utxos, rending them to spam).

It would be a pity if we do not mange to develop an improvement to Bisq 1. To change or improve later on that will be much more challenging and problematic as now when we have a green field. Also privacy leaks cannot be un-done.

So I see basically only 2 solutions for that:

• LN
• Batched fee payment

A batched fee payment comes though with the problem how to do the accounting and might lead to a futile attempt to design a new payment system.

The model for burning BSQ upfront has been proven as a working solution in the BM model and in Bisq Easy (substantial revenue generation was not a goal or expectation in BE).

A model of a "ticket" service or "fee-node" as @pazza83 suggested below, should get more thought. Maybe the RepUp shop model could be extended for a fee payment per trade use case in addition to purchase a batch of fees?

[HenrikJannsen]

As a prospective candidate for a shop owner, I would have to carefully consider the weight of the required bond and maybe the additional cost for needed reputation, as both of them would probably be a high bar to entry for competition. Running a service just for that is not an issue per se, on the other side. I guess the bond could be small enough to cover for the first few trades, while reputation is built up, and reputation itself could be build by the number and size of past transactions? Or would this still be vulnerable as in BE because of the possibility of self trades by a malicious party?

I think we should tackle one problem at a time and not get too deep into the incentives for the shop operators at that stage. I don't expect those are show-stopper problems but fine-tuning issues.

did you mean "would not suffer" here?
Upps, yes was mistake. Will correct it...

[pazza83]

I understand that Bisq 2 works without the need for BSQ. This avoids the drawbacks caused by users having to be in consensus with the DAO.

That being said I still think it would be good for traders on Bisq 2 to be able to use BSQ to pay trade fees. Many traders will have purchased BSQ with the expectation they can use them in the future to reduce their trade fees.

I am not technical enough to know what is feasible so I will try and describe what my preference would be for the fee model for the MuSig protocol.

I would go for the following option 'similar fee model as in Bisq 1'

Would it be possible in this option for traders wanting to pay trade fees in BSQ to do the following:

• Burn an amount of BSQ to be used as future for their trade fees. For example Bob burns 50 BSQ in Bisq 1
• The amount Bob burns in BSQ is added to their BSQ balance and shown in the reputation dashboard against their name. For Example; User Profile: Bob, Profile Age: 200 days, Reputation Score: 30000, BSQ balance: 50 BSQ
• When Bob does a trade Bisq 2 will check to see if they have the BSQ balance available (I assume they will query a fee node of similar) if they have the balance the fee node will deduct if from Bob's balance. for example Bob does a trade that costs 1.9 BSQ and their balance shown reduces to 48.1 BSQ
• To reduce scaling issues and increase privacy balances that have not been active for 6 months reduce to zero. Traders are informed of this prior to burning their BSQ.

This way the fee transaction is removed from the transaction itself if someone chooses to use BSQ, AND traders wanting to get a ~50% discount for paying with BSQ can still do so.

if someone is not bothered about using BSQ to save fees they can just go down the route of using bitcoin to pay fees. They might also pay a little more for the on-chain transaction but this is their decision.

In cases where both the maker and taker choose to use BSQ their will be nothing on-chain to say the transaction was a BSQ transaction.

We can even give the makers of BSQ offers a 50 BSQ a 'Better Privacy' badge or the like to let takers who are more privacy conscious know what offers will not be viable as Bisq trades on-chain IF they use BSQ to pay the trade fee.

I might be applying the maker / taker fee model incorrectly to the new protocol, in which case I propose the offer maker could pay both the maker and takers trade fees with their BSQ balance. In this instance the offer would get 'Better Privacy' & 'Fee free' badge to display alongside the offer. Thus making their offers more attractive to takers.

We could also go down the route of having only the makers pay fees to simply things and reduce the number of fee transactions.

[HenrikJannsen]

it would be good for traders on Bisq 2 to be able to use BSQ to pay trade fees.

It would require then a BSQ wallet and that would require the whole DAO implementation. I do not see any option to delegate that to the oracle node in a way which would be acceptable from privacy, security and liability POV. And adding the DAO will inherit the yet unsolved scaling issues and make Bisq 2 as heavy as Bisq 1.

Many traders will have purchased BSQ with the expectation they can use them in the future to reduce their trade fees.
I think that can be mitigated (as with BM) by communicating in advance so users can adjust their behavior. Also there will be still use for BSQ if the user opt for the reputation system (BE or MuSig). But I agree that disruptions will have negative effects. Though not developing to better models and replicating old problems into Bisq 2 have even worse effects.

Regarding the fee node model:
Such a fee-node would add privacy, security and liability risks.
A similar idea was considered for paying for network usage (as alternative for PoW), but we got stuck with that concept when trying to define it more in details and it became unclear to me if its feasible as we basically create a new payment system by that, and if that would be that easy there would be no need for Bitcoin or Ecash.
As there are privacy implications, a blind signature based model like Ecash might be indeed a solution for the privacy problems, if a centralized entity is acceptable for that use-case. If you want to decentralize it you get the double spend problem...
But I agree if it would be feasible that would be reasonable solution. I will give it more thought and would not exclude that some solution might be possible (not in a pure form I assume, but by utilizing other features like from the DAO).

maker could pay both the maker and takers trade fees
Yes that is something we can keep in mind (similar as in BSQ swaps). But I would consider that an optimization feature and would delegate it for later when the models are decided and more clearly defined.

We could also go down the route of having only the makers pay fees to simply things and reduce the number of fee transactions.
Similar as above....but I fear that would create dis-incentives for makers. In Bisq 1 makers pay less fees. To move the fees to the price has the disadvantage that prices look bad compared to other exchanges.

[HenrikJannsen]

I made in the initial post a mistake to refer to the initial model of one deposit tx instead to the latest update [1] where there are 2 deposit tx for each trader, thus the privacy implications if case of a mixed fee model would not effect the other trader.

[1] bisq-network/proposals#460

[HenrikJannsen]

Based on the idea for a RepUp shop system we could apply that also to the normal fee model.
I would like to sketch out this new system to mitigate the privacy problems when paying the fee to the BM (even with xPub keys those are not sufficiently resolved as @suddenwhipvapor pointed out) and to avoid that small fee payments add up in the blockchain, which is unsustainable long term (mining fees will turn those small amounts into spam at some point) and ineffective.

There can be different ticket types for different use cases (MuSig trade fee, top up reputation, fee for other protocols, network usage fee,...).

Note, that traders who have BSQ and are willing to run Bisq 1 could be their own ticket service, short-cutting the payment and avoiding privacy and trust issues. It is not required to run the infrastructure in that case but only to run Bisq 1. The app would offer the UX for applying the conceptual parts of the process. Details about that, can be discussed at a later stage.

Emitter service for tickets

Requirement for the service

For security reasons the service need to be a bonded node similar like the oracle node.
It needs to run a Bisq 2 node, a Bisq 1 node and implements a BTCPay like shop system for accepting payments.
The service burns BSQ upfront which give it the authority to issue a ticket.
To manage the traders balance the service needs to maintain accounting per trader using a unique and private client ID. This ID is only know to the service and the trader.

Traders perspective

The trader can pay in whatever currency and payment method the service accepts.

• On-chain Bitcoin (service might accept 0 conf transactions for lower amounts)
• BTC over LN
• BSQ
• XMR

The trader choose what amount they want to purchase and the service responds how much BSQ-credit that ticket will contain. The fee for the service and the costs for conversion and miner fees are included in that rate. Different payment methods will have different rates.

Verification:

ProofOfBurnData

When burning BSQ the ticket service use a prefix and it's profile ID for the opReturn data (preimage in the UI). The oracle nodes publish all burn txs with the opReturn data to the network once the tx is confirmed.
Thus the network knows that the service has burned a certain amount. This is the same as already used for reputation but we add a prefix to distinguish it from reputation.

TicketData

When a trader buys a ticket the service need to check that it has still enough unconsumed balance (burned BSQ not already used).
After the trader has purchased a ticket the service sends the TicketData to the oracle node for publishing it to the network.
The oracle node verifies if there is sufficient balance of the backing ProofOfBurnData, otherwise it would reject publishing.

We use the oracle node as we need to avoid that the service can remove that data by themself which would reset their balance.
This data is an AuthorizedData which comes with the protection features used for data published by oracle nodes or other bonded roles.

The data contains (not covering here the oracle data):

• UID
• Service profile ID
• Service pub key
• Service signature
• Client ID (random UID only known to trader and service)
• Amount
• Tx ID of ProofOfBurnData which backs that ticket

Anyone in the network including the trader can verify that the service had sufficient BSQ burned to cover that ticket. The oracle would also not publish that data if that would not be the case.

TradeFeeTicketData

When the trader requests a ticket for a trade fee from the service, the amount for the trade-fee-ticket will be deducted from the service's balance and the TradeFeeTicketData is sent to the trader and exchanged with the trade peer in the trade process. Note, that this data is not publicly visible but only know to the 2 traders and the service.

The data contains:

• Service profile ID
• Service pub key
• Service signature
• UID of TicketData which backs that TradeFeeTicketData
• Hash of trade ID

For verification we look up the TicketData by the UID and check if that is valid.
The trader verifying the fee payment, checks if the hash of the trade ID is correct and if the signature of the service is valid.

We do not need to verify if the TicketData has not been over-used as the service keeps track of that balance and has no incentive to cheat. With their signature they confirm that the balance was covered.

Privacy implications

The service learns about the number of trades and depending on the privacy of the ticket payment the trader might leak a linkage to the deposit tx. Outside observers cannot derive that.

The turnover of the service will be publicly visible due the published TicketData.

Pruning of used TicketData.

To avoid ever growing network data we can prune used up TicketData once the backing ProofOfBurnData is consumed as well.
Once the service sees that the trader has used up their balance, and the balance of the ProofOfBurnData is used up from all used up TicketData we can prune the TicketData which reference the tx ID of the ProofOfBurnData. The service sends a PruneProofOfBurnDataMessage to the oracle. The oracle then publishes a InvalidateProofOfBurnDataMessage indicating that the ProofOfBurnData is consumed and removes all TicketData using the tx ID of the ProofOfBurnData as well as the ProofOfBurnData itself. Thus we remove an unbounded number of TicketData + 1 ProofOfBurnData and add a new InvalidateProofOfBurnDataMessage which has a very small footprint (tx ID should be sufficient).

Leftovers

A small problem will be with remaining balances at ProofOfBurnData and at TicketData. I think that is a minor issue and solutions can be explored later.

[pazza83]

Based on the idea for a RepUp shop system we could apply that also to the normal fee model.

To help me understand your proposal from a user experience journey for trading on Bisq2 via MUsig I have broken down the steps. Please can you let me know if I am on the right track?

Trader with no BSQ

• Trader with no BSQ with bitcoin wants to sell 0.1 BTC for 6000 Euros. They download Bisq 2
• They try and make an offer to sell their bitcoin but have no ticket balance, they are prompted to buy at least 2 BSQ from the shop
• They go to the RepUp section on Bisq 2 and ask for a quote of buying 2 BSQ worth of tickets. Repup shop quotes them a price in lightning they are happy with so they send the bitcoin via their lighting wallet to the invoice address provided in the QR code
• They then have 2 BSQ worth of fee tickets (it can be lower then 5.46 BSQ because it is a ticket not actual BSQ).
• They then place their trade to sell their bitcoin using their ticket balance as the trade fee.
• Their trade completes successfully. They are happy and choose to purchase more tickets for their next series of trades next time they will purchase 20 BSQ tickets for 10 or so trades.

---

Trader with BSQ

• Trader with BSQ wants to sell 0.1 BTC for 6000 Euros. They download Bisq 2
• They can burn some of their BSQ in Bisq 1 to give them a ticket of the equivalent amount for trading. They burn 50 BSQ and input this date on Bisq 2. Their balance then increases to 50 BSQ.
• If they do not want to do this they can use the RepUp shop. It might cost them some additional fees, but these fees might be cheaper than the on-chain costs that come with burning BSQ in a high on-chain fee environment.

---

Trader that does not want to touch BSQ or any associated token

• Will this trader still be able to make take an offer?
• If 5,000 sats are to be considered spam in the future can we set this price so it can be dynamic? For example it could be increased to 10,000 sats with a DAO vote.
• It would be nice for someone still to trade without interacting with BSQ if they did not want to.

---

RepUp shop owner

• A BSQ holder is interested in running a RepUp shop
• They are happy to take payment in bitcoin and lightning
• For each there will be different fees and minimum amounts of tickets they are happy to issue. For example they are happy to do small purchases of 1 BSQ tickets for lightning payments but on chain bitcoin causes them utxo management issues so they do not want to sell less than 20 BSQ tickets at a time. For each lightning trade they want to charge a shop fee of 5,000 sats for using their service to cover their time and the costs of providing the nodes. For on-chain purchases the shop fee will be 10,000 sats to cover the extra utxo management fees. On top of the shop fees they will also want to sell BSQ tickets based on the average price of BSQ for the last 30 days + 5%. The prices they decide will have to be a competitive market price as anyone with BSQ, time, and technical abilities can run a RepUp shop can do so and provide competition. Likely there will be more than one RepUp shop for traders to choose from.

---

In the above examples the DAO revenue will come from the RepUp shop providers, or individual Bisq 1 users, to burning BSQ to get trading fee tickets.

The DAO will also collect some revenue from burning men still burning BSQ for the small amount of DPTs (and ? some trade fees still paid in bitcoin) but this might reduce if more people end up using the RepUp shop providers, and less trades end up needing arbitration.

[HenrikJannsen]

Yes, thats all basically correct.

RepUp shop was from the reputation based idea. Now I would use a different term. Maybe Ticket shop or TickEm (ticket emitter)... but thats more a branding task...

The unit for the fee might not need to be BSQ, though it might be good to make the thing more visible which enables all.
The use case where the trader burns BSQ themself need to be more worked out in details. It should be as frictionless as possible.

I think its better if the ticket service does not use fees but just a rate.
E.g. :

• You pay x in BTC and get y on ticket units.
• You pay x via LN and get y on ticket units.

The x/y ratio depends on many factors like amount, miner fees,... This allows for better dynamic adjustment if fees spike for instance.
The UI could be a list like:
Buy x units via LN and get y units by service z where the user selects x and the transfer type. And based on best rate (and probably some sort of reputation) selects the service.

and ? some trade fees still paid in bitcoin

I do not consider to support that as it would add more complexity and is not really needed. If users hate BSQ they should use Coinbase. Bisq does not work without the DAO and those who dont get it dont deserve our service. But to mitigate those stupid problems we should maybe use another unit in the UI (maybe Bitcoin and Fiat as that is what matters for users).

Trader that does not want to touch BSQ or any associated token

Same as above. I think there is no need to make the fee explicit as BSQ, but better to rather show it in the currency which matters to users, which is BTC and converted to Fiat with market price. Only users who burn themself gets more confronted with BSQ.

[pazza83]

Thanks for the explanation. I like this proposal as an option.

I do not consider to support that as it would add more complexity and is not really needed.

What about if the maker or taker does not have any tickets then they can still trade but the payout transaction sends their fee payment to burning men (deducted from their deposit).

So in trades where either the maker or taker chose not to use a ticket there would be 3 payouts:

• Buyer
• Seller
• Burning man

For example:

0.01 BTC trade
Deposit 0.0015 BTC for buyer and seller

Maker/Seller uses a ticket
Taker/Buyer does not use a ticket

Buyer payout: 0.01145 BTC (0.01 BTC trade amount + 0.0015 BTC deposit - 0.00005 BTC trade fee)
Seller payout: 0.0015 BTC
Burning man payout: 0.00005 BTC

In trades where neither the maker or taker chose there could still be 3 payouts as one random burning man can be chosen at the point of the offer being taken.

For example:

0.01 BTC trade
Deposit 0.0015 BTC for buyer and seller

Maker/Seller does not use a ticket
Taker/Buyer does not use a ticket

Buyer payout: 0.01145 BTC (0.01 BTC trade amount + 0.0015 BTC deposit - 0.00005 BTC trade fee)
Seller payout: 0.00145 BTC (0.0015 BTC deposit - 0.00005 BTC trade fee)
Burning man payout: 0.0001 BTC

I am not thinking so much of cases where users hate BSQ. More of case of not using tickets means there is one less steps for a buyer or seller, simplifying the process, and if all trades go via a ticket system then BSQ loses its utility of being a trading token that gives a 50% on fees.

The number of on chain transactions would stay the same. The additional payout to burning man would be not a very significant additional miner cost. People choosing not to interact with the ticket system would pay a higher price. This also enables traders purchasing tickets to get a 50% discount off their fees.

Using the example of Coinbase it would be similar to buyers choosing to buy bitcoin using their debit card for ease of use without interacting with the exchange. This simplifies the process and Coinbase charges a premium for it. I do not see why Bisq can't have a more simple option that traders can use should they wish.

Mitigating the problem of having the DAO in consensus between traders.

Currently in Bisq 1 the DAO syncs every block. This creates a burden for buyers and sellers to always be in sync and creates a problem with scalability.

To mitigate this a price/DAO node could take a snapshot every 144 blocks (1 day). As long as the buyer or seller where in sync with the DAO within a couple of days the trade would go through.

This would allow for much less data, improve scalability and the difference would not really be significant between having buyer and seller in sync with the latest block.

Even if the ability for traders to pay in bitcoin fees is removed we will need a way to handle the creation of the DPTs between traders should they end up in arbitration so I anticipate they will need some DAO data to be in consensus with?

It might even be that case that the maker and taker do not need to be in consensus with each other for the DAO. As the fee / DPT is created at the time of taking the offer we could just have one of the traders being in consensus with the price/DAO node at the time of the offer being taken.

The actual data needed by the price/DAO node would not even be the full DAO. They just need the following data:

• Receiver percentages / bitcoin address for the burning men for trade fees
• Receiver percentages / bitcoin address for the burning men for DPTs

To keep the price/DAO node honest we could have a section in Bisq 2 that shows the burning men percentages for trade fees and DPTs including the block height the data was taken from. Any user would be free to see what the current percentages are for that day and when it was last updated.

To prevent burning men gaming the system and burning right before the 144th block each time we could update the DAO data randomly between 1 - 288 blocks. This would mean that no one is able to time their burn to get an advantage. But on average the data is updated once per day. Or alternatively the chance of a new DAO block being used as the next data point for users would be 1/144 each block.

[HenrikJannsen]

...sends their fee payment to burning men (deducted from their deposit)

Yes that's an interesting idea.
As we use 2 separate deposit txs the privacy issues when adding a fee output would be isolated to the user who choose that model. I think the fee can be paid already from the funding tx and the peer verifies the fee payment. This would have the benfit that the fee is paid at take offer time and not when the user chose to spend their output (as the one-tx model does not has a payout tx the user can leave the btc sitting idle on the deposit tx forever, which would also delay fee payment forever).

The downside is that it adds complexity and might motivate users to not care about the decreased privacy. In case most users would use that model the privacy gains from Musig txs are lost.

The motivation to avoid the friction of using the shop (or own BSQ) could also be achieved when the payment to the shop is just another output from the funding tx, thus instead of sending the fee to the BM it goes to the shop. of course the privacy issues are then the same if the shops btc address is well known (probably not the case as it will use xpub keys to generate new addresses for each client).
So user could get an option to choose:

• I want to save on fees and buy a batch of xxx BTC/USD on fees
• I want to pay the fee only for that trade

with latter the fee goes to the shop and technically its the same as a ticketpurachse for the amount of that one trade fee.

Benefit is that it does not add other fee concept/verification/implementation but use an extreme case of the shop use case (ticke for only one trade fee).

BSQ loses its utility of being a trading token that gives a 50% on fees.

I dont consider the discount when using BSQ as a conceptual goal. It was just to motivate ppl to use BSQ as it does not involve the burningman and Bisq did not want to force users to use BSQ.
BSQ as utility token for transferring value from trade activity (fee) to contributors is still in place. It is just more indirect via the shop, but as using BSQ was considered by most friction I think that is positive.

Currently in Bisq 1 the DAO syncs every block....

In Bisq 2 we intend to not use a DAO node or BSQ wallet, at least not in near future as that comes with those yet unsolved scalability problems. Users who wish to use BSQ have to use Bisq 1, and we will need some additional features there. Have not though out all that but to bring a BSQ wallet to Bisq 2 is at least for MuSig not feasible effort-wise.

...handle the creation of the DPTs between traders should they end up in arbitration so I anticipate they will need some DAO data to be in consensus with

The BM selection would be the only part needed and that has to be provided by the oracle node to the Bisq 2 network.
The sync problems can be resolved by tolerating the last x blocks data. E.g. buyer has block BM distribution date from 1234, but seller has not received that P2P network data yet and his lates is 1233. At trade protocol we can share both users latest block and take the lower one as long its < x blocks away from the highest block. thus 1233 would be used in that case and the buyer can lookup the prev. block for verifying the distribution data.

[suddenwhipvapor]

Single-trade ticket does sound good to eliminate steep onramps for Bisq newcomers.
How would the shops be selected by the client? From the description above it sounds like the client will refer the trader to a shop in particular to buy the ticket from.
I guess the client will choose automatically the one (of the) shop(s) which has the lowest price across the board, and that's fine.
But then, if no other automations are in place, it would be a pretty tedious job for ticket machine owners to keep on top of things by manually updating prices to follow the market.
So this would require an -optional- automation on the ticket machine side, too, for example the operator could enable the "autopilot", and set it to exactly replicate the lowest offer on the market, or downprice it by m%, or get closer within n% over that price, or any other feature. The automation mechanism could get way more complicated than that, but even better it could be (also) externalized by exposing an API to export the current ticket shop market offers, and accept as input a series of prices to update the operator's current offers with.

[HenrikJannsen]

There might be the opportunity to use the information if a user has invested in higher ticket values for a kind of reputation. E.g. it signals long-game commitment for future trades and is a metric for security. Thus we should benefit from it. As well it creates incentive to do such investments which are good for the DAO.
It need to be seen if that can be done in a privacy protecting way, but I guess it can.

[suddenwhipvapor]

This would effectively incorporate the reputation in musig without actually having to use reputation like BE, not a bad idea.

[suddenwhipvapor]

Just wanted to add a general privacy consideration for shop owners ("ticket shops"? or "ticket machines"? I am not strong on madeup names to give branding when there already are proper names in english for the same thing 😃 )
While lightning can be great for the privacy of the buyer, and in general for being unintelligible to an external observer, contrary to how the blockchain works, other than being cheaper and faster than the blockchain, it could be a privacy leak to the shop owner, and here's why.
When producing an invoice QR, the payer will be able to decode the pubkey of the lightning node corresponding to the shop, so a malicious party could buy a small ticket from each shop just to associate them to their LN pubkeys, in order to maybe start a DoS attack, a grieving attack if they are routing nodes, or anything evil in general.
In other words, shops are pseudonymous already, and with lightning their node pubkey will be part of the pseudonym.
Receiving payment on the blockchain allows to use different addresses each time, which can then be sent to a mixing service, so only those addresses, that are batched together in a coinjoin with the address known by the attacker, will become part of the pseudonym, and you can't DoS-attack a bitcoin address in any case.

[suddenwhipvapor]

Will it be possible for a ticketmachine owner to operate detached form their contributor's nym?
I am thinking that even if the protocol doesn't enforce it, the burn tx could be associated with the contributor if the BSQ comes from a CR, so in that case would be a no. But BSQ from CRs could be sold on the market, and new BSQ bought with anonymous BTC could be used for burning?

[pazza83]

The bond the ticket machine operator uses would also need to be free of their BSQ CRs / BTC received from DPTs for them to be anonymous. Depending on the size of the bond this might require some planning.

[HenrikJannsen]

Here a suggestion how the use-case for the trader using their own BSQ instead the ticket service could look like.

The trader has already BSQ or purchased it on Bisq 1.
In Bisq 2 there is a UI which instructs the trader what needs to be done, similar as for reputation. Furthermore it shows information about consumed trade fees and remaining balance.

The model has similarities to the ticket service but also some differences.
We use a new key pair for each burn event for restricting potential privacy leaks.

ProofOfBurnData

When burning BSQ the trader uses a prefix, a nonce (large random integer number) and their pub key hash for the pre-image used for the opReturn data.

pre-image = [prefix]_[nonce]_[pubKeyHash]

The nonce is used for privacy protection (see later).
The oracle nodes publishes all burn txs with the opReturn data to the network once the tx is confirmed.

TradeFeeTicketData

At a trade the trader creates the TradeFeeTicketData which will be exchanged with the trade peer in the trade process.
The trader has signed that data and the peer sends it to the oracle node for publishing it to the network.

The data contains (not covering here the oracle data):

• Encrypted amount
• Index
• ID
• Signature

Encrypted amount is using a private key derived from the nonce which is only visible to the trader and his peer.
The nonce is the one used in the opReturn data of the burn tx.

The Index is an integer number from 0 - 999 and used for enumerating a range of hash values.
The trader need to start with 0 and increment with each trade. Violation to that rule would lead to a failed trade.

The ID is the hash of the nonce+index and the pub key: hash([nonce+index]_[pub key]

With knowing the nonce and the pub key the peer can look up for the matching burn tx.
opReturnData= hash([prefix]_[nonce]_[pubKeyHash])

We define the rule that a burn tx can be the parent of max 1000 TradeFeeTicketData items.
Only the peer knows the nonce and can then iterate by incrementing from 0 - index to look up for TradeFeeTicketData items which have been used from the same burn tx. Thus allowing the peer to verify that the burn tx was not over-consumed.

To avoid that all 1000 iterations need to be executed we added the rule that the trader need to start the index with 0 and increment with each trade. Thus the peer can expect that only lower indices than the one he got have been used in previous trades. To avoid edge cases with parallel trades we can add a lenience tolerance (lets say 10), thus we iterate up to index+10 and tolerate found items.

To verify that the trader has not cheated on that rule a random set of higher indices are tested to be non-existent (no TradeFeeTicketData exist with such an ID). Lets say we test 20 random numbers higher than index+10. If the peer detects such a rule violation the trade fails and the case can be reported to the mediator and lead to a ban from the network.

Privacy implications

Only the trader and his trade peers with whom he use the same burn tx learn about the nonce and the pub key (also oracle as see later). Thus, those group of traders could learn about the number of trades and the trade volume, but nobody else. Of course all that is on the technical level and not visible to users, so as long the peer does not manipulating the code, those privacy leaks remain invisible. For a motivated spy it does not provide too much value, as it only reveals how many trades have happened, which volume as well as the link to the burn tx.
User who are concerned about that limited privacy risk can mitigate it by using small burn amounts thus lowering the group with whom they share the secret data. In the extreme case it can be one burn tx per trade.

Pruning

We want to prune TradeFeeTicketData which have been consumed the underlying burn tx balance. As the data is hidden for public nodes including the oracle that can only be triggered by the trader.
Once the balance of the burn tx is used up by the TradeFeeTicketData the trader can send a PruneProofOfBurnDataMessage to the oracle.

This data contains:

• Burn tx ID
• Nonce
• Traders pub key
• Traders signature
• Max index

With the nonce and pub key as well as the signature the oracle can verify the ownership of the burn tx.
By iterating the indices from 0-maxIndex and calculating the TradeFeeTicketData ID by using hash([nonce+index]_[pub key], the oracle can find all related TradeFeeTicketData items and remove those.

Leftovers

One way to deal with leftovers would be to allow multiple TradeFeeTicketData and aggregate the leftover and the missing amount from a new burn tx for the trade fee verification.
There might be other options but that one seems to be quite simple and would only require repeated verification of the TradeFeeTicketData by the peer.

[suddenwhipvapor]

To verify that the trader has not cheated on that rule a random set of higher indices are tested to be non-existent (no TradeFeeTicketData exist with such an ID). Lets say we test 20 random numbers higher than index+10. If the peer detects such a rule violation the trade fails and the case can be reported to the mediator and lead to a ban from the network.

This is more complex than the previous explanation posts, so not sure I understand the reason behind the random check: why not just make sure there is nothing beyond the first 10 values past index? So if index+11 is populated, the trade fails

As there is no incentive for the trader to not cooperate we can leave that role to him.

Wild conspiracy theory: could a malicious actor use un-pruned spent TradeFeeTicketData as a means of DoS?

[HenrikJannsen]

...So if index+11 is populated, the trade fails

We cannot 100% rely that all TradeFeeTicketData are available. Thus we cannot enforce that there are no gaps between 0 and index. With that the trader could choose a higher index outside the lenience tolerance for cheating.
We can trust though that the index we got from the trader is either the highest one in the network or in edge cases with parallel trades to have a couple of trades with higher values. But more than 10 seems unrealistic.
If data is missing we might miss to detect over-consumption. But as the trader has no control over our data he cannot count on that.

Would need more analysis to be sure if the model as described is safe and not containing unnecessary checks. But would leave that for later detail work. Maybe other ideas replace it anyway...

Wild conspiracy theory: could a malicious actor use un-pruned spent TradeFeeTicketData as a means of DoS?

DoS is always possible and there are more easy and harmful ways to do it. Most problematic is the mailbox message as its encrypted data and can be large.
Though some TTL will be added here as well, but we cannot set to too short term as it would allow then to reset the fee balance... But we can add also a expiry date to a burn tx and by that limiting the life span of the data.

Some better option might be to allow the peer to trigger the removal. The signature for the proof of ownership is not really needed as long the oracle can verify that the balance has been used up. So this model might change that anyone who knows the nonce and pub key can trigger the removal. The maxIndex is not required as the oracle could iterate up until no index matches data and this should be usually a rather low number. We can combine it that both trader and peer trigger it (once peer detects that his trade consumed the the burn tx).

[suddenwhipvapor]

I don't understand how a trader can cheat by using a higher index value, maybe I am missing a key step of the explanation.

[HenrikJannsen]

I don't understand how a trader can cheat by using a higher index value, maybe I am missing a key step of the explanation.

Assume I have 10 BSQ balance. I make 3 trades with 5 BSQ on fee each. First I set index to 0. All ok. Next trade I set index to 12. Peer will look up the network data and see there is a gap, but he cannot be sure that he simply miss that data, so he does not let the trade fail. My balance should now be consumed. But when I do another trade with index 1, the next peer will iterate 0 -> 1+10 and miss the data with index 12, thus do not detect my fee fraud.

If we could be sure that all users have all network data the gap would be discovered as proof of fraud, but we cannot rely on that.
If we could iterate all possible indices we would also discover it but it would be a bit wasteful on CPU (maybe its not a concern as hashing is cheap). We do not be perfect with detection as a fee fraud is not a substantial problem as long it does not scale. We only need a plausible deterrent so that the incentive to try such a fraud is low.

But anyway, would not stick too much on that as it a detail problem as it is not clear yet if that model will be implemented exactly as described. More important IMO is to focus on the analysis of the overall concept and implications for privacy/decentralization/complexity/UX/costs,...

[suddenwhipvapor]

perfectly clear thanks! I also understand nitpicking details, now that no clear consensus exists, is less than optimal.
In any case, the most incentivized to not have fee-frauds are DAO members, and even more so ticket machines owners, so since they all will have a local bitcoin node running, they could verify all indices by their past non-pruned issued tickets at a regular interval, and then be queried by traders to make sure the fee was paid regularly. At the same time they could also issue pruning requests when such checks on unpruned sold tickets come out with a fully spent balance.
Yes, yes, details to be defined after consensus :)

[MwithM]

I've read the entire thread, thanks to the one who shared it as I was missing it.

While reading the first post, I got the impression that the combined model was the way to go, and then found that it was proposed in that same post. I liked that new users could use BTC to pay the trading fee and then gradually move to building their reputation, just like in BE.
While the first post was easy to understand, the next posts were more difficult, but it seems the Bisq1-like fee payment idea has been abandoned. Instead, there's a way to make a per-trade trading fee pre-payment work, without the need to include the trading fee in the actual trade. This means the shop will have to be implemented. I suppose that's good, as long as users still have the option to burn BSQ themselves. It's a substitute for using BTC to pay a trading fee through a BTC transaction for each trade, and allows XMR and LN (I would also include L-BTC here).

I wanted to add that I personally like the idea of a trading subscription model paid in BSQ. Let's say traders burn 10 USD per week or 30 USD per month to trade all they want. This would incentivize power traders to trade as much as possible, which would increase volume, reduce spreads, and make Bisq more useful. The cost of making another trade would only be mining fees and the opportunity cost for time and security deposits. It may not be attractive for spontaneous traders as they would have to pay too much per trade, so a per-trade model would still be required.

From a marketing perspective, this could be revolutionary, but also it must be the most private way of paying trading fees as it won't require to reveal how much volume a user is trading. If Bisq revenue decreases because this model becomes too popular, the amounts required to trade could be increased. I would only consider monthly or bi-monthly max time periods for the subscription at the beginning.

[HenrikJannsen]

Just to make clear which of the different models discussed here are considered so far the most likely to get used:

Ticket shop concept:#2922 (comment)
And the variant where the user use their own BSQ instead the shop: #2922 (comment)

[ChrisSon15]

Trade fees in the Bisq2 MuSig protocol

One of the open concept not addressed in the Bisq2 MuSig trade protocol is how the trade fees are being paied.

Overview

In current Bisq1, the trade fees are distributed to the burning men by sending them to an fixed address per contributor. This is a privacy nightmare for the contributors and an easy way for an observer to learn that the transaction is actually a bisq transaction. Also, this approach creates a lot of small UTXOs (as transaction fees tend to have small amounts). In a high fee environment this might lead to substantial losses.

One fix for the privacy issue in Bisq1 would be to use silent payment as proposed in BIP-0352. Basically the sender gets a public key (much like an XPUB) from the recipient, then he derives a random address from it and sends the funds to that address. The receiver must observe the blockchain and test all UTXOs if he has the private key for them. Only he can do it as the private key is needed for that operation. That way all trade fees would go to different addresses and an observer cannot learn anything from the addresses used.

In bisq1 the maker does a reservation transaction when he posts the offer. This discourages spam.
Since the Bisq2 MuSig protocol does not have this step, spam must be prevented by other means. The trade fee could be used for that.

For the trade fees in Bisq2 Musig protocol there are different options we can consider.

Lightning payment from within Bisq

The trade fees shall be send as Lightning payments. This would require the burning men to run a lightning node. Since you can run a lightning node via Tor, I think this is acceptable for burning men as they should be technical savvy. The distribution scheme could be similar to what it is right now, just using Lightning instead of onchain addresses.
The lightning transaction would need a Proof of payment which commits to the trade. I am not too deep into LN and hope that Stejbac can come up with a technical concept for this problem.

Maker and Taker will check that the other party actually made a payment before sending the onchain funds for the trade transaction.

This solution would obviously need LN technology to be included. Even tough this would not need a complete LN wallet, as the payments can be automated, but still the following functionality must be provided:

• automatic opening of channels and channel management
• making LN transactions
• proof of payment

In the Lightning network, privacy for the sender is very good. The receiver can run the node on Tor, that will give contributor a much better privacy than right now in Bisq1.

Small payments are handled well in LN. But each bisq user will need a new channel. So it really pays only off, if the user is making many trades.

Obviously, the big downside is the technology stack which needs to be added to Bisq for doing LN transactions. its very questionable if that is worth it. However, since Bisq does want to go into the Lightning direction anyway, this could be seen as a first step towards a technology we anyway need. So this is really a question of how much effort we want to put into this.

LN with external wallet

We could use an external lightning wallet for Bisq users. Bisq would still need to do some operations, like showing an invoice and verifying if the payment has been done. This would use an existing lightning wallet of the user. Integrating with it could be done via a link, which opens the wallet and transfers the invoice if the wallet is installed on the same computer as Bisq. if the external wallet in on a mobile, Bisq could show the invoice as QR code. Since this relie on an existing wallet, the user will probably not need to open a chanel specifically for the Bisq trade, he could use his existing channel(s). Obviously this is the easiest to implement and inflicts probably no additional on chain transactions/fees and has very good privacy. For the contributors they would need to run a LN node as mentioned in the last chapter.
Proof of payment would be still an open issue.

paying fees onchain with silent payments

The simplest on-chain solution for trade fees is probably to add a UTXO to the single transaction, which will serve as the trade fee payment. To not jeopardize the privacy, we would need to implement an address recovery according to silent payment BIP-0352 as mentioned before. This would need to onboard some pretty recent technology. Its unclear to me if there are supporting libraries and if they are mature.

LN payment for listing the offer.

This is in essence the same as the LN payment above, but with one change. The maker must send the LN payment at the moment when we publishes his offer, so effectively it's not a trade fee it's a listing fee. Bisq users will get only offers displayed, where the LN payment has been verified. This would prevent anybody from spamming the offer book.

using Burned BSQ

Burning BSQ to effectively buy one or more tickets, is an idea which may be used for other things as well.
but those tickets which are bought through burning BSQ must be protected from double-spends.
The easiest way would be to have a central server for that, but that means running a server which represents the DAO and effectively sells tickets for BSQ. That of course jeopardizes decentralization.
This would need to implement some sort of server handing out tickets and verifying them. I would expect this to be a considerable effort.

unidirectional payment channels

This concept is a predecessor to the Lightning payment channels but much simpler. A full description can be found in 'Mastering Bitcoin'. This would establish a channel with one other address. The user could pay several trade fees with it, but the needs to allocate a certain amount of BTC and that will stay reversed until he cancels the channel. This make the unidirectional channels pretty unlikely to be used. Only advantage is of course that it is simpler to implement.

[ChrisSon15]

This is intended as an overview of possibilities we have other than the ticket shop explained by Hendrik

[suddenwhipvapor]

I like the LN suggestions, and running my own node wouldn't scare me. The only pressing issue I see with LN is that the receiver is required to be online, differently from what happens with onchain transfers, so if for any reason the lightning node has any issue (be it connectivity itself, or the client complaining about a config file after update, the latest vulnerability discovered by some nerd publishing a weird tx on the blockchain, hardware failure... whatever) the contributor will be unable to receive the fee. What happens then?

• will the user be prevented from going on with the trade? Bad UX
• will the user save on the fees? Bad for the DAO
• will the client automatically select a different contributor to send the fee to? Bad for the contributor if this means that the issuance is "lost" to another contributor, bad for devs if they have to incorporate a means to recover issuance shares for those contributors who had availability issues, as soon as that contributor's node comes back online.

I also like silent payments, but wouldn't them still be identifiable, when the contributor needs to consolidate those outputs? That would also make Bisq trades identifiable on the blockchain, as per the xpub approach, because trades will have consistent distributions of outputs.
The above is not an issue with me as a contributor, as those utxos will be mixed nonetheless, but it could be a missed privacy opportunity for traders.

[ChrisSon15]

re LN: if contributor is offline, then the traders should pay a different contributor IMHO. Its the contributors responsibility to keep the LN node up and running, there are enough easy solutions out there to have a uptime beyond 99%.

re silentpayment: yes, compared to LN this does degrade the privacy, compared to current bisq1 it increases by a lot (and strangely noone opposed the current bisq1 model). regarding consolidation of the fee, you can either mix the coins or spend the coin in whole (means when you pay something you can send a bunch of utxos and forget about the change). But still the on chain pattern of the trade itself is much better detectable, if there is a fee-output additionally. Also the spam issue is not solved using this payment.

[suddenwhipvapor]

I myself am not against keeping the current model going, personal-privacy-wise. Actually, that would make the most sense to me, considering the amount I have burned lately. I was rather trying to consider the suggestion on a selfless overall privacy level 😄

Subscribing to a VPS service good enough to host a LN node, in order to maximize uptime, would be a forced up-front fixed expense on top of the burned BSQ.

[HenrikJannsen]

In bisq1 the maker does a reservation transaction when he posts the offer. This discourages spam.
Since the Bisq2 MuSig protocol does not have this step, spam must be prevented by other means. The trade fee could be used for that.

We could also consider proof or work. BSQ swaps are using that. Also Bisq 2 has PoW for any message anyway as network level DoS protection.

each bisq user will need a new channel.

Yes is an additional hurdle beside that we need to ship a LN wallet. Also channel liquidity might be an issues, but not sufficient familiar with LN to judge if and how much of a problem that might be.

External LN wallet ....Obviously this is the easiest to implement and inflicts probably no additional on chain transactions/fees and has very good privacy.

As most mobile LN wallets are custodial wallet I would question the privacy statement here.
Also not all Bisq users will have a LN wallet or have used it so far. Not a huge deal but it shows that we add an external requirement.

paying fees onchain with silent payments

Are there real world usages for it already?

LN payment for listing the offer.

I think that would create a bias to be in the taker role. Or at least would push up the price of makers to compensate for the fee which would have negative impression when people view prices on Bisq.

Burning BSQ to effectively buy one or more tickets, is an idea which may be used for other things as well.
but those tickets which are bought through burning BSQ must be protected from double-spends...

I was thinking that road as well but the challenges how to avoid double spend in a decentralized way would basically lead to another crypto-currency. Finally it led me to the ticket service concept as a compromise to provide centralized, anonymous, permissionless services with limited privacy and security risks.

Another potential option might be Chaumian e-cash systems but that would require a new technical requirement and would also be a centralized service, thus I did not though further into that option.