Remove maker fee tx and taker fee tx

[chimp1984]

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

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.

As the deposit tx will have change outputs to both traders we might get the benefits of child-pays-for-parent in case of stuck deposit tx. In fact it is likely that one or both users are spending the change outputs and thus extending the tx chain and make it more likely that the deposit tx gets confirmed faster, thus help to keep the miner fee low.

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!

[oscarguindzberg]

In general, I like the idea.

I like the idea of traders not having to prepare/assign funds exclusively to 1 trade.
It would be good to have a mechanism to mark offers as not available if user btc balance is not enough to do the trade. That process could run every N seconds or after each trade action (create offer, take offer, offer taken, etc)

About spam protection:

• I like the idea of a general PoW requirement for p2p messages
• The PoW difficulty increase is a bit more controversial: 1) There might be a problem in "As all nodes see roughly the same number of offers, the difficulty can be derived by that metric"... on PoW blockchains difficulty adjustments are based on all nodes seeing the exact same blockchain. But maybe we don't need a consensus on which offers are accepted/rejected. 2) An attacker with an ASIC or a bunch of GPUs could create lots of offers and make the difficulty to be increased a lot... then nobody with a standard netbook would be able to broadcast an offer.

[chimp1984]

It would be good to have a mechanism to mark offers as not available if user btc balance is not enough to do the trade. That process could run every N seconds or after each trade action (create offer, take offer, offer taken, etc)

Yes at any wallet activity at the user it can check if the balance can still cover all open offers and if not notify the user and deactivate automatically the exceeding offers. Thats a local operation. We do not need to protect that malicious users have open offers without funds, as that is also possible now and cannot be avoided as it cannot be verified without lot of effort. If that happens we have other means like banning the onion address.

1. There might be a problem in "As all nodes see roughly the same number of offers, the difficulty can be derived by that metric"... on PoW blockchains difficulty adjustments are based on all nodes seeing the exact same blockchain. But maybe we don't need a consensus on which offers are accepted/rejected.

I think I was a bit sloppy in describing that. There is no need for a global consensus about that. When you send a message to a peer who would have a different difficulty he can respond what is the required one and then you can re-send with an increased pow. The difficulty changes should be broad to not end up often in such fine-adjustment message handshakes.
Also the threshold where that become active is in attack scenarios and so far we never had such, so for normal circumstances there should be no effect. If the network gets attacked there can be some level of quality of service degredation but that should not prevent motivated users to use the network.

2. An attacker with an ASIC or a bunch of GPUs could create lots of offers and make the difficulty to be increased a lot... then nobody with a standard netbook would be able to broadcast an offer.

Yes it will have its limits. If attacker is powerful enough the pow will not be sufficient anymore at some point. That is why it nees probably a secondary model as well, to allow users who have proofen to be human an/and past Bisq users to shortcut the pow efforts.

We have to use a hash function where not ASICs exist yet - there is little incentive to invest in building a new ASICS just for sabotaging Bisq - no money can be made by that. But sure, ASICs and also GPUs can never be prevented and make the model ineffective at a certain point. But I think one need to keep the overall system in mind including the economics, motivations, threat models,...

[ripcurlx]

Yes it will have its limits. If attacker is powerful enough the pow will not be sufficient anymore at some point. That is why it nees probably a secondary model as well, to allow users who have proofen to be human an/and past Bisq users to shortcut the pow efforts.

I think we can improve security step by step. I don't think we are a target for state actors yet, so we need to prepare more for script kiddies or small organisations that try to bribe the Bisq network.

[initCCG]

The ideas sound good, but right now, watching a Bisq machine in which Bisq is taking 25% of the total RAM, while just idling. During trade, take much more, and then often runs the machine completely out of memory with some kind of heap of Java error.

I heard some makers run 2 instances to increase privacy, because makers have little trading privacy on Bisq.

So, to make these users have to run PoW calculations, would make their Bisqs run even worse.

We know that devs, especially in the West, naturally grow up on machines that are as much as a level of magnitude better (and more expensive) than world average. So, once adults, it's understandable they might think the whole world can afford such machines, or should. That's far from being so.
Our trader in an SE Asia territory had to spend literally twice as much as they would in the West to buy a refurbished machine strong enough to run Bisq securely, even though it was originally made in nearby China. That had a maximum memory of 16GB. A laptop with more memory than that is still not affordable to most users.

So, PoW and PoS features would further reduce the number of Bisq users, because they will not want to buy a dedicated computer for Bisq, when they get buy on other exchanges with just their cell phone, and paying for txs to fill the Bisq wallet.

[chimp1984]

The PoW would be close to zero in normal network conditions. It is only for attack scenarios. Currently an attacker would render the network unusable, with PoW motivated traders still can use the network.

[initCCG]

As argued in other thread, 99.99% of the cryptosphere is not interested in even using Bisq in the foreseeable future, much less attacking it.
Until that changes or even noticeably trends the other way, with all due respect, we oppose the devs spending time, effort and compensating themselves for working on attack scenarios.