New trade protocol

[ManfredKarrer]

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

UPDATE: We have altered the initial idea to keep the arbitration as option. Details will get added soon.

TL;DR for the initiated

Here is a short summary of the key points of that proposal:

• We use a 2of2 multisig instead of the 2of3 multisig like now - there is no arbitrator anymore
• Additionally both traders sign a time locked payout tx to a donation address (defined by DAO voting, e.g. Tor project but could be also a burner address). Lock time is about 1 month.
• There will be direct communcation between peers to resolve problems among themselfes
• If they cannot resolve it, they can request help from a mediator (customer care agent). Mediators are secure with a BSQ bond.
• If one peer is not cooperating the other can publish the time locked payout tx to the donation address and request for reimbursement from the Bisq DAO
• If only one trader is doing the reimburesment it can be assumed that the other peer has tried to scam and the requester is honest, so no need for additional proof.
• If both are requesting they need to deliver proof to the mediator similar like now in arbitration (Pagesigner, if that is not working screen sharing + ID verification). The mediator give a suggestion to stakeholders. Stakeholder can follow that suggestion but no guarantee that they will.
• As reimbursement comes with costs (BSQ fee, only 90% of loss will be refunded, time and effort) it should keep scammers out. They don't want to risk and invest with little chance of success. Repeated attempts will be even harder (ID verification, stakeholders might become more critical for accepting requests,...).
• The basic assumption and goal is that those reimbursements are exceptional and rare. They mainly are the tool to eliminate the blackmail risk with pure 2of2 multisig.

Overview

We suggest a change of the current Bisq trade protocol which is based on a 2-of-3 MultiSig deposit transaction where an arbitrator is the 3rd key holder who helps in case of disputes and can make the payout transaction with one of the traders. The new protocol would be based on a 2-of-2 MultiSig deposit tx where only the 2 traders are the key holders. We would delegate the dispute resolution (which in fact is 99.9% customer care work and no real disputes) to the users as first step and if they cannot resolve the issue themselfes to mediators. In case the peers do not cooperate to sign the payout transaction as defined in the trade contract there is an option for the victim of getting reimbursed for the lost BTC amount by the BSQ stakeholders. If the request gets accepted in DAO voting by the stakeholders he get issued the amount of BSQ which is equivalent to the lost BTC. To avoid abuse we introduce a time locked transaction which will send the fund from the 2-of-2 MultiSig deposit tx to the receiver of the Bisq donations (see #48). Before being able to request for reimbursement that timelocked payout tx to the donation receiver need to be confirmed.

This model actually is an insurance model where in case of damage for one trader he can get compensated by the BSQ stakeholders. For the BSQ stakeholders it still is much cheaper than spending lots of funds on arbitrators. It is assumed and need to be achieved that reimbursement requests are rather rare (not more then a few a month - or even less). The system is flexible and there is no automatation which leads to reimbursements, so it can be adjusted over time to optimize the results.

Problem with current arbitration system

The current arbitration system comes with several problems:

• It is not open and decentratlized yet bcause of unsolved security risks. Plans to secure the roles by BSQ bonds will make it better but is still not a fully satisfying solution as well. Bonds will be very high and therefore limit the potential candidates. The higher the trade volume on Bisq the higher are the required bonds as well, which creates a scaling issue.
• Bisq cannot scale if we cannot distribute that role to non-english speaking arbitrators.
• It carries legal risks (some jurisdictions might interpret holding a key in a Multisig tx as shared control over the funds and therefor interpret the arbitrator as financial intermediary).
• It is expensive: Arbitration work requires lots of knowledge about Bisq and is a high-trusted role. Locking up high bonds need to be compensated by some sort of "interest" payment.
• It is very inflexible: An arbitrator cannot revoke short term if he wants to make holiday or is sick. Private keys (BTC and Tor) cannot be handed over to a deputy.

Solution: Get rid of the arbitrators

Bisq actually started with the idea of a 2-of-2 Multisig deposit tx and only after concerns regarding potential blackmail risks in such a scenario we dropped that idea and introduced the arbitration system with the 2-of-3 Multisig.

2-of-2 Multisig transaction

The trade protocol is similar like now just that there is no 3rd key in the Multisig deposit tx. the 2 traders are the only keyholders. In case the trade gets successfully completed both traders sign the payout transaction as defined in the trade contract.

Timelocked payout transaction to donation receiver

After the traders have created the 2of2 Multisig deposit tx they will additionally create a payout transaction which is timelocked for about 1 month and where the receiver is the donation address defined by the Bisq DAO (see #48). In case both traders do not cooperate to make a normal payout any of the 2 traders can (but don't need to) publish that transaction and therefor spending the funds from the deposit transaction to the donation receiver address. If both agree they can still wait longer and can still create a normal payout at any time. But any of the 2 traders have the power to terminate the trade by publishing the alternative tx. This will be the requirement for requesting a reimbursement.

The technical details which form of timelock (nLocktime, CLTV) we will use is up for discussion and need more investigation.

There is a non-atomic process of the co-signing of the timelocked payout tx (TLP). The seller has more to lose (as he has the trade amount added in the deposit tx) so we will let him be in the role of the deposit tx publisher. He will hold back the fully signed deposit tx before he has received the fully signed TLP tx.

Here is a rough sketch of the protocol:

1. The seller sends his tx input data to the buyer.
2. The buyer creates with the sellers input data and his inputs the deposit tx and signs his inputs and send it back to the seller.
3. The seller signs his inputs. He now creates the TLP tx and sign his part of the multisig and send that to the buyer.
4. The buyer signs his part of the TLP and send it back to the seller. The buyer at that point has the full TLP tx but he could not broadcast it because the deposit tx is not broadcasted and therefore it would be invalid.
5. The seller has now the fully signed TLP tx and broadcasts the deposit tx.

The seller has the security that his trade amount is only locked in the deposit tx if he has the fully signed TLP tx which would enable him to request for reimbursement in case the buyer do not cooperate.

The buyer will only send the fiat/altcoin payment if the seller has followed the protocol and sent him the TLP tx. If the seller would have broadcast the deposit tx without a TLP tx the buyer would not start the payment. The seller cannot request the reimbursement as there is no TLP signed by both. In such a case the buyer would also lose his deposit but the seller has much more to lose, so it would be an economically irrational strategy.

Conflict resolution

From our experience as arbitrators we have seen that the huge majority of cases are no disputes but cases with bugs, banking problems or usability issues/user mistakes. Real disputes have been maybe 1 or 2 - I even can't remember any. Sometimes a user does not respond and with the currently short tolerance of 2 days response time such cases get closed then in favor to the other trader. Other cases are "future trades" - in times of high price volatility the trader who would have a disadvantage by completing the trade with the "old" price "cancels" the trade by not completing it. Only the BTC buyer can do that. This is the reason why we have a higher security deposit for the buyer (which he loses in such cases). We need to increase that security deposit to make such cases very rare.

We want to delegate most of the conflict resolution process to the traders and if needed to mediators. There will be a direct in-app messaging system (like the current one in the arbitration system) which provides encrypted and signed communication. This is important to be able to proof abuse (trolls, scam attampts in chat,...). This communication will be on a per-trade base, so with each trade you can see the history of the messages.

The mediator is basically a customer care agent who can help if needed. The details of that need more discussion but it should be implemented with scalability and flexibility in mind. It should be easy to become a mediator. The current support section in the Bisq Forum is close to such a goal. It is open if that need to be a bonded role but likely it will be. Mediator migh play a role for applying negative reputation score (#27) in case of misbehaviour.

The whole traders communication and mediator area needs more discussion and refinement.

Traders defined alternative payouts

The traders can agree to change the normal payout as defined in the contract in case something went wrong or if a peer violated the trade protocol. We got several cases of such "light" violations: Paying too late, using a different bank account as defined in Bisq or using BTC in the reference field, etc. Such "light" cases could be resolved by the traders agreeing to an alternative payout (e.g. a part of the security deposit goes to the other peer). Another scenario is that the fiat transfer failed (e.g. banking problems) and the seller need to get the refund.

The process would be that the peers agree on a payout and then send their signed payout tx to the other peer who will then broadcast the tx.

Reimbursement

In case a trade does not get completed because the peer is either not willing to complete, not responding or a scammer, the victim can make a request for reimbursement of his lost BTC. He need to broadcast first the timelocked payout transaction where the funds goes to the donation address (can only be done after the lock time has passed). In the voting phase the stakeholders will vote on that request and if it gets sufficient support he will get the BSQ issued which are the equivalent amount to his lost BTC. To avoid abuse we might set the reimburesement rate a bit lower (e.g. only 90% get reimbursed).

Risks for abuse

With the requirement that the funds in the deposit tx are spent to the donation address we avoid that a scammer could run 2 Bisq nodes, trade with himself, simulate that he got scammed and request a reimbursement. After he received the BSQ he could make the payout to himself and thus have gained the BSQ without haveing lost any BTC. As we require that the funds are spent to the donation address this attack is not possible. Furthermore we add a small loss by only reimbursing 90%. Beside that it requires time and effort to get the reimbursement which should limit it to those rare cases where the traders cannot come to a cooperation.

It is assumed that the donation receiver address is a NGO-like organisation (e.g. Tor,...) or personality with a very high reputation (like Andreas Antonopoulos,...) and that those donation receivers will change from time to time via voting. Thus the theoretical risk that the donation receiver is the scammer (or colluding) and doing reimbursement requests as described above is very low. Beside that, the BSQ staekholders do not need to accept requests and if they are too frequent or there is some suspicious for abuse they can decline it. They can also change the donation receiver if there is any reason for doubt.

Non goal

It is not intende to be used for those cases where makers or taker lose the trade fee because of technical problems. We will continue to reimburse those in a non-beaurocratic way and those amounts are too low to justify the friction and costs it would create to use the reimburesemnet request model.

Deployment

This change will be a kind of hard fork on the trade protocol level. We could support both protocols in parallel but probably it is better to make a hard change. Old client will still be able to trade between other old clients but all those who will update are moving to the new protocol. We should also have a defined timeout for not supporting the old protocol anymore and to make it possible to revoke all arbitrators. We should try to implement a conversion of existing offers to the new protocol so the makers are not losing already paid maker fees.

Details about the deployment need further discussion.

Relation to other proposals

There are several other open proposals and we need to consider if we should combine those if do a bigger change and a "hard fork":

• Would it make sense to go directly to the off-chain trade protocol idea instead of sticking with a multisig based protocol (#32 )? If so, would this replacement for the arbitration work there as well?
• Can we find a way to get rid of the trade fee transactions so that we have only 2 instead of 4 trade transaction (no proposal and no concrete idea how to do that but should be investigated if there is a way)?
• Can we add support for offline offers (#44)?
• Integrating a reputation system (#27)

[ManfredKarrer]

I want to add here some discussion regaring an alternative approach using a more complex script with 2 execution paths similar like that example in https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki:

    IF
        <now + 3 months> CHECKLOCKTIMEVERIFY DROP
        <Lenny's pubkey> CHECKSIGVERIFY
        1
    ELSE
        2
    ENDIF
    <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG

If we could implement the time lock in the deposit tx we would not need the extra handshakes required for the timelocked payout tx as descibed in the proposal but it would be one atomic tx.

But there are some drawbacks with such an approach. But lets sketch first how such a tx would look like: The 2 execution paths are: Path 1: Both traders sign the 2of2 Multisig and do the payout as agreed. As soon the paypout tx is confirmed the output is spent and therefore the second path irrelevant. Path 2: After lock time has passed the pubkey of the donation address is the receiver. As soon the donation receiver spends that output in a paypout tx the first path becomes irrelevant.

And here we have the problem. The donation receiver would need to actively monitor and make a tx to harvest those potential funds. If he does not do that the traders can still do the payout at any time in the future. That will destroy our feature for securing the reimbursement against scammers doing later a payout from the locked funds to themself.

Another drawback is that if the donation receiver would make as soon as possible the payout there is no flexibility for the traders if they need more time to resolve the problem (E.g. bank delay and both want to continue just need more time).

[flix1]

I very much like the 2-of-2 multisig approach without the arbitrator. It is simpler and requires cooperation. Complexity and support can be added outside the transaction itself: mediators, etc.

However I don't see clearly if the advantages of the the second part outweigh the added complexity. By creating the timelocked tx to a donation address and the insurance/reimbursement by the DAO in BSQ you are adding many different players, uncertain outcomes and complex incentives. Maybe it is the best way to do it... but I think it needs more explanation/testing. Scalability is also an issue... we cannot have the DAO voting on 100s of reimbursements a month when Bisq grows to 1000+ trades per day.

I see how replacing arbitrators with DAO voting solves legal issues... but the ideal solution lies in eliminating the need for arbitration, be it through atomic swaps or P2P 2-of-2 multisig enforced cooperation, not by decentralizing the arbitrator.

[ManfredKarrer]

I see that the donation aspect carries some concerns for some and it might be true that it make incentive stucture a bit more complex. But as that donation address can be set to anything by voting we can set it to a burner address as well and therefore change to a burn BTC model if needed.

The scaling issue is for sure an open risk. The suggestion has the limitation that it much not exceed a handful of requests per month. If it does we need to solve the reason why so many cases end up in non-cooperation. I am not too worries about that as we have learned that real disputes are super rare.

Sure atomic swaps would be nice and once fiat is replaced by pegged coins that might become more feasible. But there is stil a long way to go and who knows maybe we are earlier at the point that there is no need for fiat anymore and then the problem has been solved as well ;-).

The added complexity with the locked timeout tx is valid concern as well, specially it adds extra rounds for handshakes and increases the risk that the take-offer process fails. But maybe we find a way without that locked timeout tx but use a conditional script as described in the other comment.

[oscarguindzberg]

Hi, I am new to bisq so these are just thoughts from a newbie

What if both seller and buyer request to be reimbursed? How do BSQ stakeholders know who is the victim?

[ManfredKarrer]

@oscarguindzberg Thanks for your input and a pretty good question!

In earlier versions of the idea we had the requirement that the victim need to deliver some proof to the mediator (we us PageSigner/TLSNotary [1] which gives you a cryptographic proof if a bank transfer happened or not). But with the timelocked payout we don't need that anymore as there is no way the user can gain from a scam.

The case that both users request would only make sense if they have a real dispute and could not resolve it. I would suggest that they need to consult a mediator first who can request proofs from both sides for their statement in a similar fashion as it is done now in arbitration cases: First try PageSigner, if that is not available/possible make screensharing and ID verification (I know that causes a lot of criticism, but in reality it was used 1 or 2 times) and if even that does not lead to a clear result make a payout according to what the arbitrator sees the most fair outcome or do not make any payout at all. So we coould use a mediator for that role and his suggestion will be taken as base for the decision of the stakeholders.

There is also a fee in BSQ to be paid for making a request. If the request gets declined that fee is still lost, so that helps as well to keep out scammers as they risk money to lose.

Another idea we had earlier was to use BSQ bonding. Scammers do not want to invest and risk money (thats probably why we have nearly no scammers as with the security deposit in a Bisq trade they need to invest/risk something). So if we require a long term BSQ bond from anyone who wants to get reimbursed we keep most scammers out. But that requirement became also obsolete with the new model with the timelocked payout. But maybe we could still use it for such edge cases that the stakeholders require something extra to filter out the scammers. E.g. if both request they have to put up a BSQ bond which is locked up for a long time to provide some sort of "reputation".

Just some ideas, nothing perfect, maybe something better can be found. But I think/hope such cases will be super rare as they are now.

[1] https://tlsnotary.org/pagesigner.html

[clearwater-trust]

How does the 2of2 wallet provide the mediator any authority over the trade? How are the mediators selected? As the user base grows the trade disputes will increase and be more complex. I think the bonded arbitrator is the best idea. Requiring a BSQ trade bond is almost like requiring all trade fees to be paid in BSQ. Maybe this would provide a closed loop for the BSQ economy? Maybe I'm in error to think the BSQ market needs to be a closed loop system?

[ManfredKarrer]

The mediator has no authority over the trade! That is the important change to the current arbitration system. The details are still up for discussion but I would suggest that by default the users try to resolve their problem and only in case they cannot find a solution they request a mediator. How the seltion will be done is still open but I would prefer that its up to the traders who they choose.

The bonds still will exist for all other trusted roles and will be used for the off-chain trade protocol. Just the arbitration will get removed as it is the most centralized and risk carrying element in the current system.

[sqrrm]

I really like the idea of burning (or perhaps donating) the output before asking for reimbursement. That makes this scheme viable and I would support that if we go this way. It's a nice way to get around the arbitrators and the incentives seem to align quite nicely.

Using an atomic setup tx would be nice but I don't see how that could work with the current bitcoin scripting as you mention. It doesn't seem possible to avoid relying on the target address, or in fact impossible in the case of burning the BTC.

The main question is for me if this is worth implementing and pushing out if there is going to be another big change to the trade protocol using bonds. Perhaps they could work in parallel as not everyone will want to use the bonded way. This proposal seems like the fastest way to get rid of the arbitrator however and that is a good thing.

[chris-belcher]

Here are some of my random thoughts, feel free to ignore.

If I may be so bold as to summarize: This proposal replaces the single arbitrator with a bureaucratic democracy of the DAO. If so, then it seems worse to me as voting has its own problems; Each member of the DAO would have to spend their time, attention and energy on learning about all the reimbursement cases so they can vote properly, and they would have less incentive to do this. It seems more incentive-aligned to have a single person be the arbitrator, who does the work in return for their arbitration fee. Obviously I'd need to analyze what I just said more to flesh out the incentives, right now it's just a feeling.

This proposal would benefit by explaining more about exactly how this new 2of2 multisig method avoids the blackmail problems of the old 2of2 method.

If there are a lack of arbitrators then they should get paid more. This would incentivize more people to become arbitrators. Just throwing some numbers out: if an arbitrator gets involved in a deal they should earn a high fixed fee plus 20% of the trade amount, costs paid by the loser. If they don't get involved then they earn nothing. The best analogy to look at is the judicial system in normal business. Going to a courtroom and paying for lawyers is very expensive so is only used as a last resort, more than 99% of all business contracts are actually settled cooperatively without one side suing the other. Judges and lawyers are highly skilled and highly paid professionals, and they are avoided if the contract is settled cooperatively. Similarly in bisq arbitrators must be high-knowledge, but if a buyer and seller agree then they don't even need to pay an arbitrator, their two private keys are enough. Thinking this way should drastically reduce the workload on arbitrators, and allow a small number of highly-knowledgable arbitrators to serve the entire bisq system.

Mediators could be introduced into the 2of3 model as well. The high cost of arbitration incentivizes the buyer and seller to come to an agreement, they could look for third-party mediators to help them and figure out issues with bugs, banking problems and user mistakes. The buyer and seller could together even pay a mediator they find, which would incentivize mediators and still be cheaper than using arbitrators, and wouldn't burden the arbirators with more workload.

Some other thoughts about the problems of arbitrators:

• Why does non-english speaking arbitrators mean bisq cannot scale? I'm wondering because multinational corperations are able to scale to many different languages and locations, they just need somewhere along the chain of command somebody who speaks more than one langauge, or translators. Maybe Bisq could use machine translation, I dont know how well machine translation works for chinese or hindustani, but for many european languages it works pretty well.

• As for legal risks to arbitrators, from my perspective the point of bitcoin and bisq is to break the law, we can expect that eventually almost all jurisdictions will ban bitcoin and bisq. The way to beat that is to be small enough to hide and be decentralized enough so that each participant shares only a small amount of risk. Arbitrators are well suited to this because it sounds like they can easily operate only behind tor and not have to give up any personal information, also they can arbitrate from anywhere in the world via the internet and so could be out of the reach of a particular state. So for the legal risks I say arbitrators should tolerate them because they have the technology to do so effectively and they get paid for it.

• Noted that it is expensive, but in the cooperative case where buyer and seller agree, no arbitration fee needs to be paid because the arbitrator didn't do anything.

• About being inflexible. How about to make it possible for an arbitrator to create a signed message with the meaning of "for the next two weeks this account wont be arbitrating", that message is somehow broadcast or published on a notice board. Then before a trade starts and an arbitrator is chosen, the buyers and sellers obtain all these messages and simply don't use an arbitrator's pubkey if they are on leave. This would allow an arbitrator to go on holiday, take sick leave or anything else. They could also make known working times (e.g. an arbitrator works only 9am - 5pm UTC)

Thoughts on altcoins and fiat:

• For altcoins, atomic swaps are probably a much better solution than anything else because they essentially remove counterparty risk and don't require an arbitrator or mediator at all, so it is much cheaper and more predictable. Note that the naive version of atomic swaps is vulnerable to a holdup attack, because essentially one of the traders purchases an option to trade, and they could just do nothing up until the timeout if they want. But this problem shouldn't be too hard to solve with a slightly different way of doing atomic swaps, these have been written about somewhere, try searching the web.

• On the other hand, with altcoins and atomic swaps, possibly the whole system of bisq is not needed. It could be replaced with a simple website for only order matching and have all the trades happen via atomic swaps directly between counterparties. The website could maybe be on a tor HS so the site can be anonymously hosted in a censorship-resistant way. Note that any cryptocurrency which uses ECDSA and nLockTime can do atomic swaps using 2P-ECDSA and scriptless scripts. See the conference talk here with transcript here. So not all cryptocurrencies (e.g. Monero) need a scripting language, and also this is much better for privacy.

• Right now most of Bisq's trade volume right now is altcoin/btc not fiat/btc. Then using atomic swaps would drastically reduce the workload on arbitrators.

• Fiat trades are more complicated and more interesting IMO, atomic swaps obviously dont work because fiat is not a cryptocurrency. It's unlikely that pegged fiat coins will ever work, because the pegging institution is a central point of failure that can always be attacked. Most of my thoughts on arbitrators are related to fiat, because we can expect the fiat banking system will throw all kinds of tricks at Bisq in the coming years, to me highly-skilled human arbitrators seem the most flexible way to deal with them.

[ManfredKarrer]

Hi @chris-belcher thanks for your feedback!

I will add a description about the blackmail issue with 2of2 Multisig and why this proposal is not vulnerable to it as a separate post.

Here are my replies to several issues you brought up:

Real disputes are very rare

Maybe I need to emphasise that more and get some numbers from the current arbitrators but real disputes are super rare or nearly non existant. Of course that does not mean that they can happen and we need to prepare for that, but it can be expected that those cases which goes really to voting for reimbursements are very rare.

As I noted on the introduction it must not be more then one or two a month or even less otherwise we need to fix that problem by adjusting the system. If there is only a request from one peer of the trade there is no investigation required as he has nothing to win (see later a more details expalination). Only in those case where both request we need a judge. The BSQ stakeholders are not required to do the dispute resolution work by themself as that woud also carry privacy problems (you don't want to share Pagesigned docs with many stakeholders). There will be a specialized entity (medidator) who will act as semi-trusted entitiy and the stakeholders will take their word as recommendation. The details about those areas still need more thought but I think the flexibility here is a feature not a bug. It allows us to tune the sytem on demand, something which I miss with the current system.

The stakehodlers act as execution entities not as judges. It adds separation of power to the current system where the arbitrator is judge and executor.

Not the lack of arbitrators is the problem but to secure that and scale that up

Currently to become an arbitrator you will receive a private key rom myself to be able to register. That is required as an arbitrator could collude with a trader and could do fraudulent payouts. So in the worst case a scammer registers as arbitrator makes many deals with a colluding peer and take out the funds to him and the colluding party. To avoid that risk we have only high trusted persons who are in fact co-founders of the project, so beside that I trust them personally the economic incentive that they act honest are aligned as they are major stakeholders in Bisq and by scamming they would hurt Bisq and their investment. With BSQ bonding we will make that even more secure but it has scaling problems. To cover the max. damage an arbitrator could cause he need to lockup that amount of BSQ bonds. First problem is that the max. damage depends both from trade volume on Bisq as well as the BTC price. Adjusting BSQ bonds frequently is problematic as they have long lock times. Beside that there are simply not be many people atm who have such high amount of BSQ and for those who have it they might be just not willing to lock up so much and do the arbitration job - which is not a fun job by the way... So to get the few arbitrators motivated we have to pay a lot. Atm they do it mostly for altruistic motivation (as far I can interpret).

Related to that is the scaling problem. We had already request from Bisq supporters in Vietnam who wanted to become arbitrator. But I would take a huge risk to give out the arbitration right to people who I don't know personally. They could even act honest for a while and then make a long con, or they could act as major market maker and being arbitrator as well, therefore having conflict of interest and Bisq would betraying those Bisq users who assume that the system is designed in the way that the arbitrator is not an active trader. So we have a scaling problem here as not many people have the required BSQ for bonding. Translation for complicate cases might be an issue, though maybe that is not the main problem.

Legal risks

As descibed above I give out the private keys so atm I would be the choke point - even with anonymous arbitrators they cannot be 100% anonymous as I would not trust a 100% anonymous person (ok I would trust Satoshi ;-)). Even if we find a more decentralizd version for that (e.g. using BSQ bond for enabling registration - there is work going on in that direction) there are some arbitrators who don't want to hide behind anonymity and therefore would be exposed to legal risks.

Flexibility

An arbitrator can revoke any time but there are some problems involved: He could have been selected in open trades and as max. trade period is 6 days he need to assume that he gets still cases for the next 1-2 weeks. Sometimes dangling cases come even much later. Being on sick leave is even harder to handle... Of course we can - and sometimes do - announce then on the forum that there will be longer response time as normal due special circumstances, so its not an huge problem but it still sucks...

Atomic swaps

Atomic swaps are for sure super intersting on the technical level (I even started once working on it for Bisq) but they have 2 main issues if you want to do it in a real decentralzied way:

1. Scaling issues on the engineering side: You can support BTC clones quite easily but it adds much more engineering effort to get it supported with the more intersting coins like Monero, Ethereum, etc... To support 100s of coins is quite a bit of work

2. Scaling issues on the resource side: If you run that in a similar architecture as we have in Bisq (SPV wallet) you have high resource requirements to support many altcoins. BitcoinJ can be already quite heavy with BTC alone. DOGE (when we had it als alternative base currency) for instance was much worse because of the short block time. BitcoinJ got really busy... Using different models lead either the bad usability or to centralisation. So if you require that the user runs a full node and connect via RPC you limit to a handful of coins - which can be ok as most people are only inerested in one or two trade pairs. But then the user need to have a full node for the altcoin. The other option to use something like Electrum as remote server will lead to a federated system in the best case or being fully centralized in the worst. You want at least to have the wallet managed locally so that will still add some engineering effort to support that for many coins.

Maybe there are solutions for all that or there are "just good enough" ways to do it, but at least it is a big problem where there are not clear solutions yet.

Doing it in a server based environment (like Mercury did) would work better but then you only gain on security not on censorship resistence and I fear the added disadvantages (speed, tx fees) are not worth the gains then.

Another issue is that each trade is on-chain and costs tx fees which is not long term viable. But of course that a problem with current system as well, thats why we want to go in direction off-chain trade protocol.

But thanks for the links I will check out those scriptless script ideas. As said I am also a big fan of it and probably it will become more feasible to do it some day but as you also said the Fiat side is the more relevant and for that it does not help anyway.

Btw: Arbitration cases with altcoins are very rare and if so they basically never are complicate as the arbitrator can look up the block explorer. Monero is an exception here but as XMR traders are very skilled usually there are also very few problems.

I will try to get a overview about the current arbitration cases (how many, what are the reasons, how long they take, num of scam attempts,...) to give a better idea how the acutal situation is.

Adding more costs for dispute resolution

I think that is a good point and we should work out that area more.

My current idea was to delegate it as far as possible to the users and as from my experience most traders act with good intenetions that should resolve 90-95% of the cases.

Then there might be more complicate cases because of bugs or banking issues. Here a specialist is needed to help. Currently the support area in the forum acts a bit like that beside the arbitrators themselfves. I think that should be a free service to the user and we pay those support agents as contributors (like now). Specailly with bugs its not their fault and it would decrease user experience if beside running into problems they even have to pay for help.

Then there might be those very few cases where the peer is not cooperating or a scammer which will become candidates for reimbursements. If only one peer (the victim) is requesting reimbursement we don't need to do any verification or judgement as there is no incentive for him to gain something - or if so the other peer would make a request as well.

If it is the BTC seller he has lost his trade amount in the timelocked payout to the donation receiver. So he get only 90% refunded by BSQ. Beside that he has to pay a rather high BSQ fee fro making the request (adds costs/risks for abuse attampts). The BTC buyer could gain something as he lost only his security deposit and could get 90% of the trade amount if he states that he has sent the Fiat. But here the seller will likely also make a reimbursement request as he has much more to lose. And then we would end up in the only real dispute case where we need a specailized entity (can be the mediator) who is doing the investigation and makes a recommendation to the stakeholders. As both have to pay a high BSQ fee (about 50 USD) a scammer would run into high risk that he does not get reimburesed and lose additionally to the buyer security deposit (which will become also higher as now - about 50-100 usd) the BSQ fee (and a lot of time and effort). So that should be enough to keep scammers out - they dont like to risk and invest money.

The mediator is a bonded role so it has some level of trust. A colluding mediator could not repeat many times as the stakeholders would probably start to question his decisions and in case they find that he colluded he risks to get burnt his BSQ bond.

The dispute resolution would be then the same what we use now in arbitration (Pagesigner, if that does not work screen sharing and ID verification - or alternatively maybe other options like setting up a BSQ bond - but that is an open discussion area). As in the Bisq arbitration such case have been super rare (I think I did only time screensharing but just because of the user using a diff. bank account, no scam attmept) it can be assumed that those will be also very rare in future.

Also we don't need to be perfect here, just good enough. If from time to time BSQ get reimbursed to a scammer it is still much cheaper as the current system and carries less systemic risks (security, legal).

One big learning from working on Bisq over the years was that we need to priotitize the problems the right way. Often we focus too much on theoretical problems (they are often much more interesting) which will not be real problems in practice but by trying to prematurely solving those we created real usability problems and those had real costs for the system. One such a case (of many) was to not support editing offers as there was no good solution for protection agains some ddos attacks. In reality we never got ddos'd but we lost many traders because they wanted to change the price without loseing the trade fee. Bisq can fail in any ways, not attracing sufficient users is the most likely (hope we are alreadt escaping that phase ;-)).

I think with the arbitration system we also need to focus on the customer care area which is 99% and not on the dispute/scam attempt areas which is nearly not existant.

[ManfredKarrer]

Description about the blackmail risk with pure 2of2 MultiSig and why that proposal is not vulnerable to it

Blackmail risk with pure 2of2 MultiSig

In a trade protocol with pure 2of2 MultiSig (as intended in the first Bisq concept) one peer has always more to lose then the other at a certain point of time in the trade process. The security deposit cannot be set so that it will have a symmetry before and after the transfer of the fiat/altcoin payment. This asymmetry can be exploited by a scammer to request an alternaitive payout as defined in the trade contract where he gets a part of the max. loss of the peer in case the scammer deny to cooperate to complete the trade.

Let's give an example to make it more concrete with USD rate of 6000 BTC/USD: The BTC buyer put in 0.1 BTC security deposit and seller put in 1 BTC trade amount + 0.1 BTC security deposit in the 2of2 MultiSig deposit tx. Before the buyer sends the fiat the seller has more to lose so the buyer could exploit that to blackmail the seller and tell him: Let's make a payout of 0.6 BTC to each of us otherwise you will never get out anything of your locked 1.1 BTC. An economic rational seller would agree to the blackmail.

If the seller is the scammer he would wait until he has received the fiat and then the buyer has more to lose as he has now sent 6000 USD + locked up 0.1 BTC. The seller has already received the 6000 USD for his 1 BTC trade amount so that cancels out to zero and only his security deposit is at risk to get lost in case there is no cooperation. So he can tell now the buyer, let's make an alternative payout where you receive only 0.6 instead of 1.1 BTC otherwise you will not get anything and lose additional to your 6000 USD the 0.1 BTC security deposit. An economic rational buyer would agree to the blackmail.

Some people argue that the security deposit can be set in a way that there is no risk for blackmail but that is not true as the fiat transfer is non atomic with the deposit tx. So the situation swaps before and after the fiat transfer.

E.g. If you set securit deposit to 1.1 BTC for buyer and 0.1 for seller then initially it would be symmetric: Both have to lose 1.1 BTC. So the first case that the buyer can extort the seller will not work anymore. But after the buyer has sent the Fiat it is even worse for him as now he can lose 6000 USD + 1.1 BTC. The seller has only 0.1 BTC at risk. Similar problem is the case if you try to secure the second part of the trade. It makes things just worse. Only way would be to reduce the difference if the security deposit for both is much larger then the trade amount but who want to lock up 100 BTC for a 1 BTC trade? And even that would be not secure just the relation of gain and risk would be better.

There are 2 other ways which limits the effectivity of that blackmail but both are not sufficient to build a exchange on top of it with scale in mind.

1. If you avoid that the traders can communicate directly (as it is basically the case in Bisq) the blackmailer has not way to get in touch with the peer. But that is weak as the scammer could use a public forum etc. to post information for the victim to get contacted. With financial loss at risk the victim will likely find the way to the scammer.
2. Some people will not agree to a blackmail just by principle even if they suffer financial loss (not econimical rations, but emotional/ethical motivated). That might be true for certain amounts but I assume everybody has a limit here. Even if the BTC stays locked for years, some day if BTC is worth 1M they will change their mind....

The most intersting approach for a protection was found by Dan Smith (TLSNotary dev). It is that both traders sign initially the payout tx as defined in the trade but delete afterwards their keys. That way the blackmailer cannot make a new alternative payout tx as there are no keys anymore for signing it. One problem here is that nobody can proof that they have deleted it and game-theoretically (as Adam Gibson argued) there is incentive to keep the key secretly. I am not 100% sure if the technical requirements to change the software to keep the keys is a good enough hurdle for the huge majority that the scammer cannot count on that. So in practive that might work good enough, bu tnot sure how well it would work in bigger scale?

There is alos another problem here: The blackmailer could also request an alternative payment which is not related to the trade tx. Asking the peer to send 0.6 BTC to his address otherwise he will not cooperate. But this has one big disadvantage for the blackmailer: The victim has no guarantee that the scammer will stick to his word after he sent the BTC. In fact there is no reason to trust him at all.

So all in all it was a complicate system which could not be built with solid security. It can still work in small scale (Bitmarkets used that but it never took off), but building a system with such a security risk is not a good idea.

Why that proposal is not vulnerable to blackmail

In that proposal the blackmailer cannot success as the victim will have the alternative option to request reimburesment. By doing that he need to broadcast the time locked payout to the donation receiver, thus guaranteeing that the scammer will never get out any BTC. If the scammer does not request for reimburesment as well, the victim has very high chances to get the refund even without the need to proof anything. If the scammer is so naughty to also ask for reimbursement he risks that he will lose even more money (the request costs some fee in BSQ) and both need to deliver some proof to a mediator. In case the cryptographic proof with PageSigner cannot be made, they need to provide something alternative to gain more trust fo their version (ID verification or BSQ bond,...). If the victim can prrof with PageSigner and the scammer not he has lost already. He does not know in advance if the victim will/can deliver a PageSigner based proof.

So it is not very attractive for a scammer to try to get reimbursed as if he cannot convince the mediator and stakeholders he risks to lose even more (security deposit, BSQ fee, time and effort). Even if he would succeed, it will be hard to repeat such scams as stakeholders will become more critical if there are more cases specially if that would be the same person. repeated reimbursements to the same person will be taken very seriously and have high chance to get rejected.

Btw: Alternatively to ID verification we might be able to use the bank account data to avoid repeated scams (similar to account age witness or proposal #27 ). But I assume both will be not be required as scammers don't even try it with so little chance of success.

[ManfredKarrer]

@cbeams just reminded me on one important function of the arbitrator which might get lost in the new system: That the arbitrators enforce the trade protocol rules and by adjusting the payout they can fine-tune the "punishement" for violations.

There are certain cases of light violations and we have to take care that user learn from their mistakes and don't repeat those. Examples are:

• Paying too late
• Forgetting to press "Payment started" or "payment received" .
• Not using the trade ID in 'reason for payment' field
• Using 'Bisq' or 'Bitcoin/BTC' in 'reason for payment’ field (more serious)
• Paying from a different account or wrong name (triangular scam risk - also more serious issue)

One way we could support that function in the new model would be to have a list of suggested "fines" for such violations. Most are pretty clear and if that list says "Paying from a different account" costs 50% of the security deposit (or a fix btc value) there should not be much discussion left to the traders to apply that rule to their payout.

The traders have themself the option to change the payout. Both need to agree on that and only then both sign the payout tx. By that we would delegate that punishment to the traders themself. If the wrongdoer would not agree it can lead in the worst case to the timelocked payout to the donation receiver and the trader who acted correctly can request for reimbursement. The wrongdoer will have little chance to get reimbursed if the case was clear.

Of course there will be a grey area and if traders are very non-cooperative such cases might become messy. But both risk that the mediator and stakeholders make a jedgement against them. For instance in case one trader has paid one day too late and can proof that his bank had issues or it was a long bank weekend holiday and the other trader show zero tolerance to that and require the full "punishment" and it lead to a real dispute, the one who show zero tolerance is also risking that the mediator and stakeholder are in favor of the one who paid too late.

It will be hard to predict and find rules for all such possible cases and we need to trust a bit on common sense and good intentions. Worst case we will have such cases from time to time and might lose traders because of a bad experience. That can also happen now if the arbitrator enforces a rule and one of the peer is not accepting it mentally and leaves Bisq because he felt unfairly treated (I am not aware of such a case but is possible it has happened). From my experience as arbitrator there have been much more cases of very nice behaviour where the wrongdoer suggested by himself to give a part of the deposit to the peer than intolerant or aggressive behaviour. And if we would lose such kind of user it would be not a problem for Bisq IMO.

Beside the financial punishment there might be other possibilities to ensure the trade protocol rules are followed. We could emphasize some sort of reputation system. Again the #27 reputation proposal might be one option here to add reputation based on negative score. Traders who are repeating violations will have it harder to find trading peers.

Moving from the current model where the arbitrator is the authority which issues the punishment to a model where the peers need to come to a consensus of what is a fair punishment can be considered a positive change. But of course things can become more blurry and the "human factor" creeps in more here. But Bisq is not built to eleminate the human factor but rather to tame it for increasing social cooperation.

It is important to note here that the core protocol is not related to those "detail problems". This flexibility to find solutions around the core protocol which to the whole process more smooth is a big advantage. Even if we don't get it right from the start we can adjust it over time without the need to change the protocol.

[ManfredKarrer]

Some more thougths regarding the off-chain trade protocol and the question if we should skip that current propsal and go directly to the off-chain trade protocol.

The off-chain trade protocol is heavily based on the Bisq DAO and the trust, maturity and stability of BSQ. For that reason it will be not feasible to move to that model too early. Also we will need to support both protocols as we don't want to force users into using the BSQ system as well we would have a chicken and egg problem (how to get your BSQ if you need it for BSQ bonding).

One main motivation for the off-chain trade protocol was to get rid of the arbitrators as well. This can be solved now with that proposal, so the big pressure factor is removed.

The other advantages like:

• independence of any base currency (you can trade EUR to USD or XMR to USD)
• no on-chain privacy issues
• no miner fee txs
• speed (BTC-LTC over lighning can be done in 1 sec)
• convenience (to not need to wait for block confirmation enables a lot of usability improvements)
• flexibility,... are less important for now but for sure very interesting improvement options for the mid term future.

[sqrrm]

@ManfredKarrer For the enforcement we could let the mediator set the payout structure and the local clients would do the payout according to the mediator settings. Most normal users would not be able or willing to invest the time to modify the software for a different payout structure.

[ManfredKarrer]

@sqrrm Ah good idea. We could leave normal not modified payout to the users and if they want a diff. payout they have to get the mediator involved and he acts as authority here. As both need to agree to the result modified software would only work if both users would do that, so I think that is a non-issue.

[ManfredKarrer]

I got from the arbitrators feedback about number of disputes and the rough distribution of the reasons.

Number of cases that month: 127 out of 1539 trades which is about 8% (-> still too high) Number of real disputes ever: zero

Reasons:

• Bugs: 40%
• Bank issues: 25%
• Usability issues: 25%
• Users not pressing sent/received button: 8%
• Future trades (cancel trade because of volatility): 2%
• Not responding at all: 0%
• Scams: 0%

So we see that so far it has worked out well that the protection mechanisms in place kept scammers out. I think it is a reasonable assuption for the new protocol as well that we do not need to focus too much on the abuse cases if the system is designed in a way that it is not attractive for those.

[ghost]

@ManfredKarrer , I presume the (not broadcasted tx) reason is included in the Bugs: 40% ?

[ghost]

@ManfredKarrer

... the victim can make a request for reimbursement of his lost BTC. He need to broadcast first the timelocked payout transaction where the funds goes to the donation address (can only be done after the lock time has passed).

So this means the victim will have to wait one month before being able to do that ? or should be before instead of after here ?

[ManfredKarrer]

@HarryMacfinned

I presume the (not broadcasted tx) reason is included in the Bugs: 40% ?

Yes

So this means the victim will have to wait one month

Yes, even longer as first the timelocked payout need to be done and then he has to request. As said it has to be assumed that those cases are very rare.

[ghost]

@ManfredKarrer wrote:

repeated reimbursements to the same person will be taken very seriously and have high chance to get rejected.

... but a scammer will very probably use a different BTC address and a different onion each time. In which case it's impossible to detect that it's the same guy scamming. The only barrier is the account age which will limit the amount of scams. But even with that, a scammer can open fresh new accounts regularly.

But I imagine 100% safety is unachievable and a rational compromise has to be built between protecting against rare case and protection costs for everybody/everyday usability.

On the general way I find this proposal very interesting on several angles. Thanks for all the thinking ! I'm also confident that good solutions can (and will) be found for all the points of detail. Reducing the number of involved tx would eg be fine.

[ManfredKarrer]

If both traders request then PageSigner or in case of altcoins ID verification is needed. So a scammer will not be able to repeat. If only one of the peers request it can be assumed that the not requesting one acted incorrectly (scammer), so no need to verify anything.

[ghost]

@ManfredKarrer wrote:

Another idea we had earlier was to use BSQ bonding. Scammers do not want to invest and risk money (thats probably why we have nearly no scammers as with the security deposit in a Bisq trade they need to invest/risk something). So if we require a long term BSQ bond from anyone who wants to get reimbursed we keep most scammers out. But that requirement became also obsolete with the new model with the timelocked payout. But maybe we could still use it for such edge cases that the stakeholders require something extra to filter out the scammers. E.g. if both request they have to put up a BSQ bond which is locked up for a long time to provide some sort of "reputation".

This is imo really a good way to go. Users should be allowed to define themselves, on a free will, the bond they are ok to attach to their account. And to increase/decrease this bond at their will. And they could of course exhibit their bond as a proof of goodwilling and professionalism (for some). I may be wrong, but I bet that on the maker side Bisq has already a majority of pro or quite pro traders. Giving them means to display their professional and good willing could be a interesting tool for those people who contribute daily to Bisq's success.

[ManfredKarrer]

Yes, the good thing is that we will be very flexible what to use, its not part of the protocol. Security can be provided by money (sec. deposit/bond) or by reputation (ID verification, tools using the bank account,...) to avoid sybils.

[cyphersphinx86]

I like the simplicity of having only two parties and the idea of building up online reputation. Being able to trade at a better price, due to traders picking you for your reputation rather than price, is in a way a profit similar to the one a scammer would get from scamming minus the lost deposit/bond, here just from doing good.

I'm a little concerned if money can be lost due to software bugs, where the arbitrator otherwise would have the ability to take action.

Donations sounds cool, though imo first priority should be to ensure the value of the Bsq token won't crash too hard, say for example around the 1st of each month or aften the token release. And right now overall 'debt' is around 3 mill if I'm correct. Of course a lot of 'debt' will be hodled by stake holders, I just stress the importance of sustainable economic housekeeping, before doing beautiful gestures like donations.

This thread was quite a long read, maybe we could divide it into more issues each based on a conclusion or resume of a topic discussed here?

[chris-belcher]

From reading the proposal, the time-locked refund transaction pays out to a donation address of a trusted entity (e.g. Tor), but the reimbursement comes from the Bisq DAO. So that means that every time a dispute happens then Tor would gain money and the DAO would lose money? (Presumably this would be expressed by the BSQ token falling in price) Would it be possible that if the rate of disputes is too high then the DAO would somehow go bankrupt?

Could it make sense to have the 2of2 refund transaction pay to an address owned by the DAO itself instead? I feel like I'm missing something, thanks in advance to anyone that explains.

[ManfredKarrer]

@chris-belcher The assumption is that those reimbursements are very rare. This assumption is based on experience with current arbitration system -> 99% of the cases could be solved by either the peers themself or with a mediator helping. Nr. of real disputes was zero. There are also quite high costs for Bisq for operating the arbitration system, so even if we have a few cases per months it will be still much cheaper.

The stakeholders don't need to agree to the reimbursement, if there are too may cases we need to fix the reason for that.

The donation could go to the Bisq BTC donation address, but that comes with centralization issues. You cannot distribute the BTC in the same decentralized way as BSQ. Burning the BTC might be another option. The receiver address can be cahnge by voting so the Tor example is just one possible option. The Bisq donation address will be likely the default address we start with.

[chris-belcher]

@ManfredKarrer The assumption of rare reimbursements might not hold in an adversarial situation. That could be used as a kind of DOS; an attacker could repeatedly open trades with himself that then fail and then ask for reimbursement, which could drain the DAO of money. Another way to do it is if a DOS vulnerability is discovered then an attack opens trades with many other traders and uses the DOS to make the trade fail, also requiring reimbursement and draining the DAO of money.

[chris-belcher]

I've maybe thought of a vulnerability to the proposal in OP. It works because voting power for a reimbursement being weighted by ownership of the BSQ token. Those BSQ tokens can be bought on the open market. So an attack would be that someone opens many trades on the orderbook and makes them all fail which locks up the bitcoins, and at the same time buys enough BSQ tokens to make themselves a majority voter of the DAO and use that to vote themselves the bitcoins they locked-up. This would be cost-efficent if the value of the locked-up trade bitcoins is higher than approximately half the BSQ market cap.

By analogy this is similar to in the world of joint-stock companies, where there is such as thing as a hostile takeover where an external entity quietly buys up >50% of the voting rights and then outvotes the existing board of directors.

[ManfredKarrer]

@chris-belcher The BTC in the trade are sent to the receiver address (can be a burner address as well or the Bisq donation address). So any attack would only make sense from that receivers perspective (e.g. If it is the Tor project and Tor supporters try to "donate" the BTC sellers funds there). The DAO staketholder do not need to reimburse and in cases of massive requests will highly likely not do that. Voting is based on meritocracy not pure stake based. So buying up voting power is very expensive and then the attacker is a majority stakeholder who would risk his investment if creating damage.

A majority attack (if >50% of stakeholders - incl. meriticracy) is always possible but its irrational and would prooke a fork.

[ManfredKarrer]

Neiman and Craig started working on that. I leave it open for reference / information.

[chris-belcher]

A majority attack (if >50% of stakeholders - incl. meriticracy) is always possible but its irrational and would prooke a fork.

This would be rational if the adversary can steal more money from traders than the cost of ~50% of all voting DAO tokens. This model then implies that the cost of the DAO has to be more than twice the value of trades happening in a given period.

Can you go into more detail of this fork?

[ManfredKarrer]

How should he be able to steal money? The control over the trade funds are in the hands of the 2 traders and nobody else. The reimbursement is only activated by stakeholder voting and not an automated process. Any weird scenario would motivate the stakehodlers to delay at least the reimbursement until situation is clear.

There will be no fork but an alternative trade protocol - the users can choose.

[chris-belcher]

Yes you're right, I was confused by something.

[ManfredKarrer]

I added a more detailed roadmap here: https://docs.google.com/document/d/160-74pYDowU4ok3czx-hG6QZYiH0tpNdUN-J4xIdVgI

[ManfredKarrer]

Update: We want to add the option to still support arbitration as additional optional feature. Details coming soon.

[clearwater-trust]

Thanks for the presentation. Very exciting new stuff here for reference: https://youtu.be/cZtg2sjXli0

I can see how the DAO allows for reimbursement through stakeholder voting. If there is a fee incentive for traders to use the 2 of 2 mediator protocol, I can see this becoming a preference. Especially for altcoin trades.

I like that the DAO and trader can save on cost by using the 2 of 2 mediator option.

I also like the option for a 2 of 3 arbitrator trade (because I’m frightened of change!)

The fee model for entering into a 2 of 2 trade should consider how much it costs a bad actor to clear the order book of competitively priced offers by locking up funds so their trades are the only ones listed.

Requiring a reimbursement request through the DAO for failed trades could be used as an attack on the DAO? If a bad actor were to inundate the compensation system with reimbursement requests it could directly affect the BSQ market?

A new fee model was mentioned for this type of trade, I’m interested to see what is proposed. A really great discussion and description of a complex system. Thanks.

[ghost]

Interesting presentation indeed, even if the topic is not so simple. One commentator mentioned possible synergy with openbazaar. I write it here also as a reminder for myself.

[ManfredKarrer]

The fee model for entering into a 2 of 2 trade should consider how much it costs a bad actor to clear the order book of competitively priced offers by locking up funds so their trades are the only ones listed.

By taking sell offers the attacker would lose his security deposit (he is buyer). With buy offers he would risk to lose also his trade amount. If security deposit is sufficiently high those attacks are rather unlikely. We plan anyway to adjust security deposit on volatility. So that should reduce that attack risk even further.

Requiring a reimbursement request through the DAO for failed trades could be used as an attack on the DAO? If a bad actor were to inundate the compensation system with reimbursement requests it could directly affect the BSQ market?

The stakeholder do not need to accept requests. If anything weird is going on they might reject all and wait for longer until the situation has been resolved. Requests can be rejected and repeated later again, so we an delay it if it requires more time to figure out what happened. I don't see it as a realistic risk but yes, there is some risk for "sabotage" attacks.

A new fee model ...

Not really a new fee model just an additional fee for the arbitration option which should reflect the costs of the arbitration system. But we take care to avoid that users are pushed to the new model. The fee can be defined in DAO voting and will likely start with 0.

[mpolavieja]

I was listening to the dev call about the new trade protocol and it caught my attention the problem of one of the trading peers becoming totally unavailable.

Would it make any sense that apart from the timelock tx to the Bisq donation address, the peers make also a timelock "Undo" tx with an execution date after the donation address one, which would pay the security deposits and the trade amount to the other peer?

So if one of the traders is not available during 1 month, the online trader could choose not to publish the tx to the donation address and publish the tx where he would get the traded BTC amount plus the security deposits without having to go through all the DAO voting and reimbursment process (and the pseudo-arbitration / underwriting process).

It could happen that if the online trader is the seller he gets everything if he intentionally does not confirm the payment reception and plays the game of the other peer not being available so he gets back his BTC after one month, but he would be very recklessly risking his security deposit. If the buyer does not initiate a dispute and does not care about publishing the donation address tx, well, then it is reasonable to assume that he is not going to claim any reimbursment anyway.

In any other case where the fiat / alt-coin payment did not happen, I don´t see the problem if the other peer did not care at all during one month, so he deserves to lose his security deposit.

EDIT: Another possibility is that the tx only pays the security deposits to the other peer and the BTC always goes back to the seller. This would make the protocol lean to protect more the BTC seller than to buyer, this is specially interesting for fiat pairs, and also to eliminate the risk of a race to publish the "Undo" tx once the date of the donation address tx is reached.

[chimp1984]

@mpolavieja Yes thats an interesting idea.

Actually I think we could just add 2 more txs which gets signed by both and have a timelock further in the future than the donation address tx. Those 2 txs are spending all funds to one part. Buyer gets a tx signed to receive 100% of funds and seller gets as well such a tx where he receives 100%. So in case ony of the 2 is not available the money goes to the active trader. E.g. Lets say the normal payment to donation address has timelock 2 weeks and the other refund txs have 4 weeks. In case of disagreement one of the traders need to publish the payment to donation address otherwise they risk that the peer is getting all funds.

[mpolavieja]

Yes, it would be 2 tx signed by both. But I think it would be best that both tx give back always the BTC to the seller, and the security deposits to the other peer.

In case of disagreement and both online, yes, any of the traders needs to publish the normal donation tx.

If the unresponsive trader is the BTC seller, I think the buyer would always also want to publish the normal donation tx, because if the BTC seller is dishonest and is faster publishing his "undo tx", the seller will scam the buyer. But if it is the buyer who is unresponsive (which I understand is the more likely scenario), the BTC seller is better off by waiting and publishing the "undo tx" instead of going through all the dispute nightmare.

[sqrrm]

@mpolavieja Good point, just reverting to the original state will at least cover the case of the non responsive buyer. Both are then ok with the BTC going back to the seller (assuming the buyer didn't send any fiat). I think it can work as an extra protection for sellers.

[chimp1984]

@mpolavieja Good point with the case that both could wait and then have a mining fee race for publishing at same block. So my suggestion would not work. If seller gets it the buyer has no incentive for doing that and I agree it is more likely the buyer who has less at stake and forget about the trade. Not so sure though anymore if this problem is worth the added complexity (not so much on dev side but more to communicate to user)? A high buyer security deposit might reduce that risk a lot as well, and having the arbitrator doing the reimbursement would not cause much trouble to the seller. Also waiting more time has maybe more costs than using the arbitrator?

I think it could be also added later probably without much backward compatibility problems, so we could keep it as an optional addition for later if we see it becomes a problem.

[chimp1984]

Actually it might add a new kind of risk: The seller could try to attack the buyers app via the p2p network. If the buyers app becomes not available due ddos he might not be able to act and the seller gets all the funds additional to the fiat/altcoin payment.

[mpolavieja]

I think the buyer would always also want to publish the normal donation tx,

Maybe this could be solved if the buyer "undo tx" is scheduled 2 or 3 blocks ahead of the seller´s? So the buyer will also prefer to publish the "undo tx" better than going to the dispute / reimbursment process?

[mpolavieja]

I think it could be also added later probably without much backward compatibility problems, so we could keep it as an optional addition for later if we see it becomes a problem.

Yes, I didn´t mention it but I was always thinking of it as a possible later improvement (if it is worth it)

Actually it might add a new kind of risk

Agree on that. I don´t know how likely it is that kind of ddos attack to be successful.

In any case my major concern is to avoid the DAO being involved in the reimbursment process. Not because of scalability but because of legal problems.

[mpolavieja]

Actually it might add a new kind of risk:

This could be mostly solved if the "undo tx" of the buyer is automatically published when the buyer clicks the send payment button (before seeing the payment details)

[chimp1984]

This could be mostly solved if the "undo tx" of the buyer is automatically published when the buyer clicks the send payment button (before seeing the payment details)

Don't understand that. Can you describe more in details? Payment details are exchanged in take offer process. A timelocke tx which is not valid yet will not be relayed by Bitcoin nodes.

[mpolavieja]

A timelocke tx which is not valid yet will not be relayed by Bitcoin nodes.

Yes. I did not realize that. It would not work.

[mpolavieja]

Actually it might add a new kind of risk:

Don´t we have somehow this kind risk already? For example if a BTC seller receives a payment and does not confirm it, he can ddos the buyer so he is unable to open a dispute / publish the donation tx. So after one month the BTC seller is in a position to blackmail the buyer and get for example half of his BTC back (Of course, he would be risking his security deposit).

So isn´t there a need for a manual procedure outside of Bisq to publish the donation tx (or whatever emergency tx)?