Adjust parameters for JPY order book to reduce friction for new users #98
Comments
|
All those are very interesting points that are discussed every once in a while within the community. I think that making changes to the trading protocol is not an easy task at all. Mabye @ripcurlx or @sqrrm can help more on this. But in any case I fully agree that if possible, it could be great to reduce friction for new markets while bootstrapping. The problem of not requiring a security deposit is that people are lazy and without it they often do not comply with the trade by not showing up (f2f) or not making the payment (fiat bank payment). But maybe Japan is completely different in this respect. |
|
I welcome this feedback very much. Us veteran users have become accustomed to the complexities of Bisq and often forget what a hurdle they are for newcomers. Onboarding definitely needs to be simplified. That being said... my opinion on these suggestions:
I am generally in favour of making everything optional and letting users choose which Bisq tools they need. However if you want to do an F2F escrow-less trade... you don't really need Bisq at all. A simple shared spreadsheet will work. Or you can do a small Bisq trade and on meeting F2F then do a second escrow-less trade with the same person. I see no advantage in removing this. 👎
I would definitely allow users to decide on this. For test trades and tiny trades it could be useful.
Bitcoin tx miner fees are pretty good anti-spam, especially for multisig txs. Additional hurdles are probably redundant (including the minimum security deposit and minimum fee). 👍
Bisq fees are tiny. Much smaller than mining fees for small trades. I see little value in removing them. Somebody not willing to pay 0.10% of a trade in fees is probably not making a serious offer. 👎 |
|
I don't exactly know how hard it would be to do minor changes to the trade protocol but I don't think it's that hard. The UI side might be harder and since we're talking about making onboarding easier then the UI is probably the main point. Some things are easier to present than others and perhaps it's better to first think of what we would like to have and then see if it's doable.
Making escrow optional is not obviously a bad idea to me. Bisq functioning like a message board could have some value in bringing in people that later want to get the full Bisq experience. Another point of getting rid of the escrow is that we're already looking at removing it in general since the arbitrators are currently the weakest link regarding decentralization. In that case it would be replaced by something else though, like 2of2 multisig or BSQ bonds. If we get rid of arbitrators and let users post f2f trades they could then use the trader to trader chat to arrange a meeting. Sounds like it could work but also sounds ripe for social engineering scams. Not sure I like this idea, but perhaps Japan is different and it would work there. Is it a good idea to tailor rules per currency?
I don't think this is a good idea in general. If the default was 0% for all currencies many users would assume that's recommended and reasonable which in most cases I would say it isn't. To implement that as some special rule for JPY trades might work. Perhaps for low value JPY trades only. It could possibly be a worse experience for many if the BTC is not released from the 2of3 multisig. Then the case would go to arbitration and that is going to be troublesome for those that don't speak much english. I don't know if the arbitrators speak Japanese but I assume not.
We haven't had any issues to obviously the anti-spam measures work ;) Maybe it's enough with the bitcoin tx fees to deter spam, it does make it easier to attack the Bisq network. I would say it could be worth trying as long as it could easily be reverted if there is an attack. It's not worth risking the whole network for onboarding but it's most likely the tx fees are enough to deter an unmotivated attacker and I don't think it's likely we would see a motivated attacker at this point.
I agree with @flix1, this is a very small fee, it's not complicated to understand and it's not complicated to pay. |
|
I agree with @jmaurice . I have been a bit disappointed when I tried to replace my localbitcoins flow by Bisq and could not properly do. I consider writing a localbitcoins equivalent only for cash trades if it keeps missing. (The community advised me lot's of other solution, but none beat localbitcoins) I wish Bisq can do it though. Cash are one of the most important use case IMHO. |
|
@NicolasDorier @jmaurice If you want a bulletin board to post offers without any commitment of security deposits, trading and mining fees or escrow maybe checkout the Mycellium mobile wallet's MarketPlace. I feel like some of these proposals stretch Bisq too thin. The trading fee is integral to the Bisq's network just like mining fees are to the Bitcoin's. You should have to pay to publish as keeping the network online isn't cost free. |
|
@huey735 Nobody use Mycelium wallet anymore, and their UX for local trader is still seriously bad compared to the simplicity of LocalBitcoin. That said, I will wait wiz presentation in Tokyo to better understand what can be done with Bisq. I don't think some fees are necessary a bad thing, it depends on how it is done and I admit I have not used Bisq now. |
I think this combined with no BTC trade fee for the buyer would be very interesting not only for BTC/JPY but for all markets. I was refraining from proposing this because there are many other important things that need to be implemented and developers are an extremely scarce resource, but since more or less it's been brought up, I´ll briefly describe my proposal regarding this: No security deposits and no seller´s BTC locking for small quantities (< $30 or $50) This could work for f2f and also for bank transfer payment methods, for the latter only sellers that have a signed account (see #93) of certain age would be allowed to make this type of offers, so they risk their bank payment bank account to be banned from Bisq if they misbehave. The seller would not send his BTC until the buyer sends the money first. The BTC could be sent outside Bisq, so SegWit or LN could be used. For bank transfers, since the seller already has a "reputation" (old account) he could optionally require the buyer a very small down payment ($3 or $5) through an easy and fast method such as Paypal or Venmo before engaging on the trade, to ensure he does not lose the maker trading fee (if finally there is any). This would require communication between traders. To cover the maker trading fees (if any) and the mining fees (if any), the seller could mark-up the BTC price of the transaction in order to cover those costs. All the above would help a lot bootstrapping markets, and it would lower the barrier of entry for buyers that don´t have BTC, which I think it is important for Bisq as a fiat on ramp. This type of small trades with "trusted" BTC sellers would not have security deposits, but in general for all other trades I agree with @flix1 not to make the default security deposit 0% |
For completely new markets this kind of sellers do not exist, so we could do like we are going to do with mature markets by manually setting all accounts prior to 1 march 2019 as mature accounts (signed), but instead of a date it could be based on a bootstraping group of Bisq pioneers. For example @jmaurice or @NicolasDorier could provide a list of Bisq onion addresses from people they trust for which all payment accounts would be manually set as signed by an arbitrator or developer. This would be just a one-off manual procedure, after this all other accounts would mature automatically. |
|
Unfortunately there are real resource issues with both network and arbitration. There has been quite a few cases of lost messages, some due to Tor being slow (possibly under attack) and some likely due to the Bisq network itself. There is a plan to improve the Bisq side but I don't think anyone is working on it right now, not enough developers around. This also leads to more cases going to arbitration. If arbitration could be avoided for small trades that would avoid creating more arbitration disputes, that's one issue down. There still need to be some kind of anti spam protection but perhaps having BTC sellers pay the fee is good enough at this stage, and they would stop if people decided to take their offers without going through with the trades. It might be a bit tricky to implement this with the trade protocol though. |
|
Yeah, Ideally these small trades should not have the possibility to go to arbitration. This type of trade would rely on the honesty of old users and their willingness to onboard new users. Maybe I am naive, but I am very optimistic that it would work well. The risk of scam would be very low for this quantities, it is very unlikely a scammer wouldt risk a stolen account to be discovered for such a low quantity (for more security the number of this kind of trades could be limited for buyers). If a decentralized blacklisting procedure is implemented in the future for standard trades (which I am fully aware is big work), then these small trades could use that procedure. The issue with a decentralized blacklisting procedure is to avoid unfair slandering, but I think this could be solved if the unfairly accused can defend through a challenge (with a challenge trade or by bidding BSQ). So as I said, big work :( Regarding network issues, I think the seller maker fee should not be removed even for this small trades. |
Well yes, we had a great shared spreadsheet called localbitcoins for many years, but it was shut down by some government. So now we want a decentralized shared spreadsheet (i.e. bisq order book) but without huge friction to create a post on the spreadsheet. On localbitcoins they had different order books for different types of trades - if bisq wants to keep everything on the same JPY order book then perhaps you could indicate "non-escrow" trades somehow? |
@mpolavieja If this can be done with relative ease... We should do it. Two caveats: |
|
Discussed in today's growth call: bisq-network/growth#143 Most agree on creating a simplified trade protocol that allows offers with no escrow and no arbitration for small amounts. Main issue: How many dev hours would be required to implement? |
|
Just a quick note: Changing the trade protocol is not trivial. Specially handling multiple protocol versions would be a nightmare. That was the reason why we decided that the new trade protocol will be not backward compatible. So just kicking out security deposit and arbitrator can be done but to make it compatible to run in parallel with the normal protocol is getting complicated. The protocol architecture was not designed for supporting mulitiple parallel protocol versions. |
|
Great, thanks for green lighting this. My initial thoughts (knowing nothing about the protocol or code base) are that we wouldn't have to modify the protocol so much, just set a parameter that escrow = none and have the clients handle this gracefully. Could you elaborate a bit on why this might be difficult? |
|
The trade protocol is basically a sequence of tasks getting executed. Some are interactive and require user input and can have a delay of a few days (e.g. confirm payment receipt). The trade protocol is closely coupled with the Trade and Offer object and many other domain objects. Changing the trade protocol requires that all old nodes are compatible with the change. P2P network objects cannot be changed a lot as that would break backward compatibilty. Adding a different behaviour would require to have either tons of options which get carried along and then make switches of behaviour or to have a different protocol which gets executed. I investigated options for supporting 2 protocols when we started working on the new trade protocol a few months ago and we decided to make a hard-fork when launching the new trade protocol as maintaining 2 in parallel would be a huge pain (engineering effort, maintainance, risk for bugs,...). |
|
Ok, but at this moment it is possible to change the security deposit, so that option already exist. So if it could be set to 0% in a new version, that would mean skipping one of the tasks within the sequence and old nodes would fail to handle this, correct?. But if there is a hard fork and all nodes are forced to run the new protocol where setting a security of 0% is possible, that would still be problematic because for those specific trades the task sequence would be different from a trade with non 0% security deposit? |
|
Let's go step by step...
2, 3, 4 can all be done easily. It's just requires changing parameter values. It could be ready for the next release if all approve. 1 is more complicated. Let's continue to study it or see if we can find a workaround. For BUY offers it's not an issue as there is no escrow. For SELL F2F offers a possibility is to make the offer small (0.001 BTC) and then once communication is established between buyer and seller a secondary trade for a higher amount without escrow can be negotiated. |
|
My first comment wasn't well-considered, so this is a replacement. If the Bisq software will be challenging to adapt, another route to consider is encouraging the use of another peer-to-peer software platform to facilitate a censorship-resistant medium to post offers without escrow, deposits, fees, etc Scuttlebutt comes to mind as one possibility, but there may be others. |
Something that was brought to the attention here: bisq-network/bisq#1140 Feels greatly counterintuitive. |
|
@marsrobertson I think that making the validation step on BuyerAsMakerTrade interactive (on-chain transacion) instead of requiring user input (confirming the trade) would allow at least nocoiners BTC buyers to take existing trade offers by getting loans from bitcoiners. The loan platform/vehicle would exist outside the software and Bisq would only enforce the reimbursement of the loan. |
|
What we should/could consider when launching the account signing feature, that we only require signed accounts to lift the initial limit for mature markets. This would help to bootstrap new markets like JPY. We could already start signing accounts in the background in disputes and if we have sufficient signers or have scammers in the market we can apply the signing requirement. |
|
There is a solid community of 20+ people in Tokyo who I could vouch for as "not scammers" who all want to provide liquidity and act as market makers, perhaps we can bootstrap their reputations somehow? |
I think the account signing process should allow this to be done quickly. |
As you may have heard, our Tokyo Bitcoin Hackers meetup group is supporting the launch of the bisq's new JPY order book to its members. In preparation for the launch event, some of our co-organizers have been conducting test trades. I traded with with @flix1 on the JPY order book today and they went very well, but we have identified some friction points which I would like to propose adjusting, so that new users in Japan who create trades on the JPY order book will have a smoother experience:
Make escrow optional
What we really want for face to face trades is just a message board to post contact information and trade terms, like we used to have on localbitcoins.com - let users decide if they want to use the bisq escrow or not. For in-person cash trades, users typically only use a service like bisq to find people to trade with, and after the first trade they contact the counter-party directly for future trades, and wouldn't use bisq at all after that. @NicolasDorier said it well: https://twitter.com/NicolasDorier/status/1135370176285700096
Reduce the minimum security deposit to 0%, and make the default 0%
The current minimum of 5% security deposit in Bitcoin for a face-to-face cash purchase is impossible for users who don't currently possess any Bitcoin, or who are out of Bitcoin. Again, let the users decide how much risk they want to take, and not encourage requiring it for now. If there are issues we can always increase it later, but for onboarding new users this is a major friction point.
Reduce the anti-spam measures
New users will want to experiment using bisq with very small order sizes, which the current system detects as spam and requires extremely large security deposits, trading fees, etc. - we should remove these, at least temporarily or until there is an actual spam problem on the JPY order book.
Consider reducing trading fees during the introduction period
For example, a user did a test trade for $100 and the trading/mining fees were about $6 - people interpret this as bisq being very expensive and costing 6%. Another user tried to make an offer for 1 satoshi and saw the security deposit was 5000% - we should really look at reducing these and only increase them later if we have actual problems. Japan doesn't have a scammer problem (yet).
The text was updated successfully, but these errors were encountered: