We would like to get user feedback on what they want to see on Bisq in 2019?
All ideas are welcome. We can discuss popular ideas on tomorrow’s growth call that everyone is free to join.
Please post your feedback here or on GitHub following the link above.
2 Likes
OSNF2P
January 3, 2019, 7:28pm
2
I would like to see a centralized onboarding ramp such as Shapeshift.io that executes the trades on the exchange in the backend. It would be a massive source of funding and liquidity, and allows people to take advantage of the easy transactions in the same trusted manner they are already, while also helping Bisq.
OSNF2P
January 3, 2019, 9:32pm
3
Homard
January 4, 2019, 8:05am
4
Devs are only reading reddit very episodically.
Peoples who want to throw efficiently their ideas about Bisq should best use the github https://github.com/bisq-network , open issues or make PR.
tieck
January 5, 2019, 12:20pm
5
According to the new Trading protocol described here
opened 06:37AM - 25 Oct 18 UTC
closed 01:11PM - 08 Nov 19 UTC
was:approved
> _This is a Bisq Network proposal. Please familiarize yourself with the [submis… sion and review process](https://docs.bisq.network/proposals.html)._
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)
a new in-app messaging system will be introduced.
However such a system won’t solve the problem that the seller may forget the trade and so forget to release the coins after he has received the money. With this in-app messaging system it would not be possible for the buyer to notify the seller that he has to release the Bitcoins if the seller does not start the Bisq application after he has taken the trade and the money has already been sent to him. Such a case really shouldn’t take the long way through the new Bisq DAO resolution process.
To mitigate this problem a notification mechanism out of the Bisq system would be helpful. A simple solution would be the possibility to add a contact information (e-mail address) in Bisq that will be revealed if the trade has expired. A more complex solution that will protect privacy would be that this message is sent through the Bisq application itself including PGP encryption etc.
1 Like
Please could we have a feature which shows the Maximum BTC that can be traded based on the user’s current Bisq wallet balance. I find myself constantly guessing how much I need to allow for trading fees etc. I keep having to cancel and restart. And I don’t want to make another transaction to make up small differences and create more dust. I just want to use what is in there without having to guess and use trial and error.
Thanks guys and great job!
1 Like
Homard
January 9, 2019, 3:42pm
7
@donquijote
Devs are only reading here episodically.
Best for your idea is to use the github https://github.com/bisq-network , open issues or make PR.
i can obviously read… https://docs.bisq.network/exchange/howto/add-alternative-base-currency.html
However, it would be nice to see a regular (monthly) community vote for 3-5 new altcoins/month and easier on-ramp.
Specifically, trading of altcoin: LOKI
AndyCC
January 13, 2019, 3:14am
9
@banegaston
More scam “trittbrett driver” crypto ?
No thanks.
AndyCC
January 13, 2019, 3:25am
10
Including a https://tox.chat/ lib for a chat may be a good way for adding anonymous P2P chatting.
Homard
January 13, 2019, 9:23am
11
This document is rather outdated and does not correspond to Bisq’s mid-term long-term plans.
Bisq targets to be free from any base currency, and so will probably not add new ones.
95% of new altcoins got very few trades, often 0. So the listing work ROI is ~0.
Bisq devs have already enough to do with higher priority tasks.
If a community wants to have an altcoin listed, the best is:
to find somebody to do the job.
to do the efforts necessary to insure that real trading will follow
Homard
January 13, 2019, 9:56am
12
How would you see that done ? (technically)
AndyCC
January 14, 2019, 4:35pm
13
The TOX core lib allow you to “outsource” a secure anonymous P2P chat functionality.
File transfer, audio, video optional.
The TOX core https://github.com/toktok/c-toxcore can be started on demand.
I.e. when a Bisq offer is taken. A TOX chat group out of Maker, Taker and optional Arbitrator can be temporary build and used for communication.
1 Like
How about automatically returning coins if Arbitration is not completed in 30 days?
Make Bisq super easy for small coin to coin trades?
So simple that a college kid with a hangover can download Bisq and complete the first trade in 5 minutes. Save the pop ups and disclaimers for later and larger amounts. Let newbies have fun with tiny amounts. Are one click trades possible? BUY NOW
1 Like
Small suggestion to further increase privacy: Would it be possible to have a custom setting in the preferences under the Bitcoin Block Explorer options so that I might point Bisq to my own btc-rpc-explorer running on my own node to check on transactions and confirmations? As it is, it looks like I must choose among the common 3rd party block explorer sites. If Bisq can use my own btc node (which it is now), then it would further enhance privacy to use my own btc explorer which is gathering data from that same node.
Also, let me add how much I appreciate the Bisq project and what you are all doing. As we all watch so many decentralized exchanges seek sudden scale at the expense of privacy and security, Bisq is steadily and quietly living up to the ideal of a decentralized, secure and private exchange with decentralized governance (no small feat). Congrats to you all and keep up the good work. Bisq is that small pebble dropped in the ocean whose waves will eventually wash up on all shores of the world.
Northhill
1 Like