Federated trade fee aggregators

[sqrrm]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

This is an idea inspired by bisq-network/bisq#5418 and recollecting the issues with an off chain protocol as discussed in #32

Problem

Trade fee transactions are low value transactions that cost a lot in mining fees and are difficult to handle. Currently they're paid as either BTC outputs to the burningman or by burning BSQ. Both cases cause extra costs on users, but the BTC case is the most problematic as it's causing small value txouts.

Previously Discussed

It has been suggested that a third party could be part of trades to burn BSQ for trade fee and receive BTC as compensation as part of the trade transaction. This still doesn't eliminate the problem of low value txouts.

Another related problem from the off chain trade protocol is to have a pool of locked up BSQ that could have a lien put on it to use as collateral for trades, problem here being that without a block chain it would be impossible to guarantee that the data is properly distributed on the network making it unreliable as collateral.

Fee Aggregators

• A Bisq contributor puts up bonds to act as a fee aggregator (FA).
• Traders that want to use FAs put up a BSQ bond for the amount of fees the want to be able to aggregate. This bond is tied to a particular FA with a hash or some other data.

The FA acts as a notary during a trade. The peers connect to the respective peers FA to let them know how much trade fee they are paying, including trade id and amount. Then they connect to the peers FA to verify that the correct amount was assigned.

The FA keeps a record of credit for each bond assigning them as their FA. The users prove that they are the rightful owners of the bonds and can deduct up to the amount of the bond as fee payments. If a user want to reset their credit they can buy the credit from the FA as a Bisq trade, receiving the verification of credit reset in the form of BSQ burnt by the FA.

Accountability

Traders can check with the counterparty's FA if fees are paid properly, this ensures that traders are paying fees. The verification from the FA is a signed statement from the FA.

FAs should continously publish a record of their outstanding credit, this could be a merkle tree with hashes of signed statements and associated values so that traders can verify that their payment is included. There might be other ways to handle this part better.

Non FA Users

A trader with BSQ locked for usage with a FA could pay for a counterparty that doesn't have such an arrangement in exchange for BTC as part of the deposit tx.

If both users aren't setup with a FA this wouldn't work.

Other Usages

Using a similar arrangement to solve the issue with the off chain trade protocol might work, but there's more at stake since the collateral is locked up and the corresponding "Collateral Aggregator" would have to post a much larger bond, I doubt it would be feasible.

Summary

I think this could be a way to aggregate the fee payment for BSQ users and those that they trade with. It still doesn't solve the case where both traders want to pay the fee with BTC though.

[chimp1984]

The FA would learn about the trade history of the users which have choosen that FA, right? If so that would be a serious problem.

[sqrrm]

The FA would learn about the fees paid, which would correspond on amounts traded of course. I think it's not necessary to use trade ids, a nonce generated for the trade could be used for verification of fee payment for a trade. Still, the FA would be able to get a reasonable picture of the kinds of trades made by the user, that is true.

[sqrrm]

There are two reasons to avoid merging the fee into the trade tx

1. The fee inputs and outputs cost extra, a segwit inputs are about 70 vbytes extra and segwit outputs 31 vbytes.
2. The fee payment acts as a marker on Bisq txs making them stand out on-chain. That is bad for privacy.

Compared to the current multi tx protocol it's better to merge the fees as it would result in lower mining costs and no change in traceability. This proposal is a way to move the privacy issue from on-chain to a single FA and lower fees. It would reduce issues with privacy even more if only one party paid the fees for both and the other party pays the fee paying party as part of the trade tx.

[huey735]

@chimp1984 @sqrrm Is there a way to make the trade transactions not public? In the current the protocol the Deposit transaction includes an OP_RETURN output with the hash of the trade's contract. Why is that? Plus it has a very distinct relationship with its previous and following transaction. Making the whole trade have a significant fingerprint.

If we are to always rely on the BTC blockchain to public stamp the following is unavoidable with Fee Abgregator (FA) or not:

The FA would learn about the trade history of the users which have choosen that FA, right? If so that would be a serious problem.

It would always be trivial to find Bisq trade transactions.

It has been suggested that a third party could be part of trades to burn BSQ for trade fee and receive BTC as compensation as part of the trade transaction. This still doesn't eliminate the problem of low value txouts.

The proposal to Replace Burning Man with Burning Woman suggests the use of coinjoins. So the Burning Woman would provide a BTC input of her own and get a BTC output in the same transactions. Avoiding this way the creation of lots of small utxos that would need to be consolidated in the future.

[sqrrm]

I think the contract OP_RETURN that's part of the deposit tx is not necessary. The same security could be had by both parties signing the contract with the pubkeys used in the deposit tx and have the parties save that copy locally.

As long as BSQ or payment to burning man/woman is part of the trade tx it would still be possible to profile Bisq trade txs so that's where the FA would help. The FA would be able to see how much fees a certain bond owner has paid, but not see which trades and not know anything more about that bond owner. It might be possible to associate likely candidate trades with certain fee payments, but it's not obvious. If we stopped publishing trade statistics it might not be possible at all since those Bisq trades would not have any specific signature on chain, especially if we can get the taproot single tx protocol running.

Burning woman still suffers the issue of many outputs, although they wouldn't have to be aggregated as a singular operation, but I think the on chain footprint is similarly large to the burning man. The extra output to the burning woman, the extra BSQ input from burning woman and BSQ change.

[pazza83]

Hi @sqrrm please can you review this proposal and either close it or move it forward. There does not seem to be much feedback currently on this proposal.

[sqrrm]

It's an idea but I don't think it has much support right now. I will close it.