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

dav1dpgit notifications at github.com
Sat Apr 18 15:04:59 UTC 2020


> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

Issue
===================
Bisq requires users to be owners of BTC in order to access Bisq BTC markets.  This is a known barrier to entry for new Bisq users resulting in slower Bisq growth and preventing opportunity to put BTC into the hands of nocoiners.

Solution
===================
A nocoiner buy-BTC Bisq trade framework where the buyer takes the first economic transfer steps under cover of 3rd party chargeback process before the seller’s Bisq amount is transferred to a multisig wallet.  In this way the buyer settles the Bisq trade before settlement, proving financial interest in the outcome.
Leverage the existing Bisq transaction structure through a special BTC trade type where if selected at the point of Bisq BTC offer creation (maker sell), the trade has special designations, added steps, restrictions and settlement characteristics such as eliminating buyer BTC security and deferring fees.

How it works
===================

At the time of BTC sell (maker) creation a new checkbox presents the seller to designate the trade as a BTC onboarding transaction.  If the checkbox is selected, the following criteria are changed for the offer:
1)	Size restriction of 0.01 BTC
2)	Fixed price of +1%
3)	Can only be created as a “BTC sell maker” trade
4)	BTC sell account must be a signed account or have at least 180 days of existence for the given settlement and currency combination
5)	Only (one)(five)(TBD?) BTC onboarding offer(s) can exist in the market for a given settlement and currency selection, i.e. onboarding checkbox is disabled until the number of offers for a given currency and settlement method on the network at the time of offer creation are less than this amount
6)	Limited selection of settlement methodologies—BTC onboarding offer only available for rapid settlement, payment invoicing methods but with low-but-potential chargeback such as Revolut, Zelle, SEPA Instant or equivalent
7)	BTC seller does not incur an upfront Bisq fee to post the offer
For clarity, if the BTC onboarding checkbox is selected, all other criteria remain the same, including the BTC seller’s security deposit requirement.

Utilization of a BTC onboarding transaction by a buyer is a one-time opportunity. Upon successful completion of the BTC onboarding trade the BTC buyer taker’s account would be flagged to designate having taken the onboarding offer, and unable to take another BTC onboarding offer in the future.

Settlement information sharing happens before the BTC is moved into a multisig account and the process is reversed for a nocoiner trade type: BTC buyer’s information is provided to the BTC seller.  The BTC seller uses the fiat settlement mechanism to send the BTC buyer a fiat invoice for payment.  The settlement mechanism for BTC onboarding trades must support invoice payment settlements.

Upon transaction by a qualified BTC buyer, the following changes occur to the trade process:
1)	BTC buyer security deposit is zero
2)	Trade listing is removed from the market bid/offer stack but does not process into multisig
3)	The BTC buyer information is sent to the seller, and Seller creates an invoice within the external payment methodology and sends invoice to buyer; buyer confirms receipt of seller’s invoice within Bisq
4)	BTC buyer sends payment to seller within payment methodology, which the seller confirms within Bisq
5)	Upon seller confirmation of 4), Bisq moves offer to multisig and generally follows the standard settlement process including reconfirmation of payments
6)	Bisq trading fees are subtracted from the settlement due the BTC buyer
For clarity, there is no transfer of BTC from wallet to multisig wallet due to the action of the buyer accepting the trade.  This only happens after the payment from the buyer is confirmed.

If the trade fails due to the BTC buyer before transfer into multisig, the BTC seller retains the BTC and since the trade was never moved from the original multisig there were no additional fees and no need to relist, only to rebroadcast to the nodes if space is available on the stack.  If no space is available then the trade can either be waitlisted to rebroadcast, cancelled and removed or converted to a standard offer.

Could be merged with Proposal #201 (https://github.com/bisq-network/proposals/issues/201)

 
Potential Risks and Mitigation Techniques
===================

Attack vectors by BTC buyers:  
--------------------------------
**Take advantage of trading without a security deposit**
This might be offset through having to pay upfront before any multisig ownership is available, as well as limiting the value of this attack due to the limit of the size and volume of potential transactions.
**Abuse BTC sellers by trading and failing the trades**
Trading and sending incorrect information is possible, but this is then discovered through the invoicing process, allowing for relisting by seller at no cost.
**Block other BTC buyers from trading through multiple transactions**
Limiting the number of trades per account, plus requiring to pay upfront limits the potential of any attacker to financial means.
**Claim for chargeback after receiving BTC**
No different than current exposure within Bisq.

Attack vectors by BTC sellers:
--------------------------------
**Sell BTC without incurring DAO fees**
This is a feature for veteran BTC sellers, allowing for a premium to make the market.
**Abuse BTC buyers by trading and failing the trades**
Sellers expose themselves to legal and regional repercussions of the 3rd party settlement system due to invoicing without delivery of services, account freezing and worse.




-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200418/5439940d/attachment-0001.html>


More information about the bisq-github mailing list