[bisq-network/proposals] Trust-Minimizing Solution for Onboarding New Bisq Users Without BTC Ownership (Nocoiners) (#214)

[dav1dpgit]

> The security in that model would be based on the value the signed account has to the seller.

Thanks for your feedback @chimp1984.

Let me respond, starting with your last point and the premise of this proposal.  Bisq currently does not offer a way for nocoiners to start on Bisq.  As you mention, they must go to an ATM if it exists, friends, meetups, etc.  They are likely to centralized exchanges (in my opinion.)  The lack of a Bisq onboarding method for nocoiners is detrimental to the growth of Bisq and misses opportunity to put non-KYC bitcoin into the hands of the people.

**The security in that model would be based on the value the signed account has to the seller.**
That is a part of the security model; please see your additional clarification, below.

**The Multisig is not needed as there is no mutual lockup**
Agreed, I keep this in place to minimize the impact to the current Bisq process flow and coding required.

**(please note there is no "Bisq moves offer to multisig" - the users do that, Bisq has never access or control over the funds otherwise it would be custodial).**
Yes, my mis-characterization.  It should say, “seller moves offer to multisig via Bisq”; I will correct the original post.

**The Buyer need to trust the seller that his signed account is more worth to him to not scam the buyer.**
That is part of the security to the buyer; the other security comes from the ability to claim a chargeback due to the seller not fulfilling their contractual obligation and further negatively impacting the seller’s banking and/or finance app standing external to Bisq.

**What happens if the seller does not send the BTC?**
If the seller does not send the BTC the buyer initiates a chargeback to retrieve the monies the seller invoiced.  In this scenario the payment interface company acts as a “recovery intermediary”.  This is quite negative for the seller.

**Then his account need to be blocked which is a centralized feature and should be only used as last resort.**
I haven’t thought much about blocking sellers’ accounts if they are failing to deliver.  If that is an option then for provable scamming tactics might be worth considering.

**What happens when the buyer is never sending the Fiat? The seller loses time and the buyer has nothing to lose, so no incentive to play to the rules.**
Both seller and buyer lose time, same as in all Bisq trades where a buyer defaults, but the seller is able to relist without economic loss. A defaulting buyer that shares real information risks their 3rd party payment system account. A defaulting buyer that shares fake information in Bisq, combined with this:
**Could be also used for a sabotage attack (create many payment accounts, take all offers never pay, remove availability of those offers).**
In this sabotage attack, it becomes a war of attrition.  This is why a limit on the open offer count makes sense from a time-loss perspective. Should this product become a popular aspect of Bisq and we want to remove the count limit, we can rethink how to add a form of security for nocoiners (multi-party vouching?) that will prevent a sabotage attack.

**The price must be sufficiently higher to motivate sellers to make such small trades.**
Agree, suggest the DAO work out what price cap should be.

**Restriction to one trade per new user is difficult and can only be applied to 1 trade per payment account.**
Why would a restriction at the user level be difficult?  Per payment account is workable, too, even though it results in a single user potentially trading multiple times using this method.  Not a deal-breaker…

**I think its in all an interesting approach but I am not sure if its worth the implementation effort and increase if UX complexity (users need to understand the difference of the 2 models and the concept of the signed accounts, which is not trivial).**
Thanks, and agree it is not a trivial change.  I see this increased Bisq marketability far outweighs the increased UX complexity.

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