[bisq-network/proposals] Remove maker fee tx and taker fee tx (#265)

Mon Oct 19 23:26:41 UTC 2020

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

I want to present an idea **how we can get rid of the maker fee tx and the taker fee tx** and therefore saving about 50% miner fees for traders. 

### Maker fee tx

The maker fee tx serves 2 purposes:
1. Have a tool to protect against offer spam/dos attacks
2. Prepare the funds needed for the trade so the user cannot spend it unintendedly.

The first point could be replaced by **proof of work** (thanks @sqrrm for the idea). 

The second point becomes less problematic if the miner fee is paid exclusively by takers. The calculation how much funds need to be in the wallet to be able to serve the offers is much more simple if one does not need to take miner fees into account as unknown tx sizes would render such calcuation basically impossible. If the maker has no maker fee tx and the miner fee for the deposit tx and paypout tx is paid by the taker (as it is now the case) we only need to sum up all offer amounts and check if the wallet has enough funds. This will simplify also the internal wallet management with AddressEntries. Maybe they are not needed anymore at all.

The proof of work has to be dynamically defined from the network load. Every add-offer and refresh-offer message requires some level of proof of work. If number of offers goes over the normal level the work required will be increased. As all nodes see roughly the same number of offers, the difficulty can be derived by that metric. In normal condition the difficulty should be very low, so not causing any performance degradation for users. If the network would get flooded by smap offers, each node would accept and relay only offers which contains the required proof of work.

This idea fits to the general idea to add proof of work as dos protection for all p2p network messages.

### Taker fee tx

The taker fee tx can also be removed. Its main purpose was to protect against data harvesing attacks as payment account data are exchanged in the take offer process and it should add at least costs to a potential data harvester. Though that concept always was flawed as the taker fee tx cannot be verified in the short time of the take offer process and the costs are rather low.

A better alternative is to exchange the payment account data after the deposit tx is seen in the network or at an even later point in the protocol. If the payment account data would be fake or the account age/witness would be invalid the trade would fail at the moment before the buyer sends the payment (e.g. deposit tx is confirmed). And for the seller when he receives the payment started message. So before releasing the BTC he can verify the peers account. 
So the seller sends his payment account data with the last message after he publishes the deposit tx (`DepositTxAndDelayedPayoutTxMessage`). The buyer can then do the verification and if anything would be invalid the trade would fail before the buyer sending funds. 
The buyer would send the payment account data with the `BuyerSendCounterCurrencyTransferStartedMessage`. The seller can then do the verificaiton before releasing the BTC.

In that way we do not need new messages but can use the existing ones to share that data. This provides a much stronger protection against data harvesting as the attacker need to lock up the funds in the deposit tx.

The function to reserve the funds for the trade has less importance here as the time between take offer and deposit tx creation is very short and we do not need to deal with the case that the user could spend funds in that moment.

The trade fee will be included from both peers in the deposit tx as additional inputs and output to the fee receiver. It will be verified by the peer as part of the tx verification process. Also here we gain compared to the current status.

The implementation will likely require a new trade protocol version and maybe require a hard fork, specially the proof of work for the offers.

I will try to start a prototype to see if there are bigger problems and if there are some solutions to avoid a hardfork.

Any input is appreciated!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/265
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201019/6a2f7e37/attachment.html>