Trust-Minimizing Solution for Onboarding New Bisq Users Without BTC Ownership (Nocoiners)

[dav1dpgit]

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

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 pays for the Bisq trade before BTC 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 cap to be set and updated by DAO, e.g. 10% above market 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.

As noted in a comments below, add POW measures to increase effort involved by the nocoiner buyer to provide skin-in-the-game proof and/or CAPTCHA upon buyer lifting offer to prevent Sabotage Attacks.

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), seller moves offer to multisig via Bisq 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 address to the multisig address 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.

[Bisq-knight]

I think this requirement is a guarantee for failure.

Fixed price of +1% above market

When someone is market making they need to be able to set the spread they want. I market make with over 10% spread in some payment methods that are even lower risk than this. For 1% I would never take this risk and I doubt anyone else would. It would be only charity.

Likewise, if someone wants to do charity and put 0 spread. They should be able to. I think this constraint should just be removed as I don't see a point in it. The market is good enough to find its own spread ;)

[Conza88]

I like. Great work. My concern is with #2 & 5. Don't think fixing the price will work. Economically speaking: Price controls = shortages.

Also setting a limit of five offers per market? Interested in why? Surely with scale this wouldn't be enough? Also leads to shortages in supply, given high enough demand.

[dav1dpgit]

I think this requirement is a guarantee for failure.

Fixed price of +1% above market

When someone is market making they need to be able to set the spread they want. I market make with over 10% spread in some payment methods that are even lower risk than this. For 1% I would never take this risk and I doubt anyone else would. It would be only charity.

Likewise, if someone wants to do charity and put 0 spread. They should be able to. I think this constraint should just be removed as I don't see a point in it. The market is good enough to find its own spread ;)

I had the fixed price (to be set by the DAO and adjusted as necessary over time) because originally I was considering only one offer to be available for a given currency+settlement option at any given time. If only one offer is available someone could come in with a 1,000% markup to block the process; this could be done with a of 10% cap instead?

[dav1dpgit]

I like. Great work. My concern is with #2 & 5. Don't think fixing the price will work. Economically speaking: Price controls = shortages.

Also setting a limit of five offers per market? Interested in why? Surely with scale this wouldn't be enough? Also leads to shortages in supply, given high enough demand.

Thanks. I think a limited number of offers (1 to 5 slots) per currency+settlement methodology isa good place to start to ensure it does not overtake normal trading patterns. This could be throttled up over time if it is successful. Same with the price cap I responded to in the above comment.

[MwithM]

Seller sends a payment invoice to buyer: That reveals account details of veteran Bisq users for free.

Utilization of a BTC onboarding transaction by a buyer is a one-time opportunity.

Unless buyers create a new Tor address and new payment account.

BTC buyer sends payment to seller within payment methodology, which the seller confirms within Bisq

f the fiat payment is already received, there's no need to use multisig or security deposit. Seller could just release the bitccoin to settle the trade. What if seller does not confirm? Seller is at risk of losing an old payment account, which could be sufficient to make them confirm the trade. But not for a 1% spot price. For small trades just mining fees can be over 1%.

[dav1dpgit]

Thanks for this and will respond, but changed the premise of a fixed spread to a capped spread as many people pointed to this as a weakness.

[dav1dpgit]

Thanks for the comments.

Seller sends a payment invoice to buyer: That reveals account details of veteran Bisq users for free. First step in the process is the buyer revealing his/her account details to which the BTC seller sends an invoice. Bisq could maintain a list of name-and-shame scammer accounts if this is an ongoing concern against which any subsequent trades could be checked by the seller. Additionally, if a seller wishes for information to be protected some payment services allow for pseudonyms or pseudo-accounts to be used for invoicing counterparties. I’ll check around for others but this kind of anonymity is available for certain payment options. Overall, a Bisq user does not have to provide these kinds of offers should this concern her or not have an anonymizing opportunity available to him.

Utilization of a BTC onboarding transaction by a buyer is a one-time opportunity. Unless buyers create a new Tor address and new payment account. Yes, hence limiting the size of the transaction and putting the burden of payment of all fees onto the buyer. We could also increase the Bisq fees for this kind of transaction if there is concern they are not sufficient given the trading burden, but that would incur additional coding, I am sure.

BTC buyer sends payment to seller within payment methodology, which the seller confirms within Bisq f the fiat payment is already received, there's no need to use multisig or security deposit. Seller could just release the bitccoin to settle the trade. I am looking to minimize the change to the transaction flow of Bisq, merging this process into existing framework.

What if seller does not confirm? Seller is at risk of losing an old payment account, which could be sufficient to make them confirm the trade. But not for a 1% spot price. For small trades just mining fees can be over 1%. Agree that the 1% may not be sufficient, so it could easily be set to something higher. 10%? I changed this in the original proposal.

[dextertd]

Thanks. I think a limited number of offers (1 to 5 slots) per currency+settlement methodology isa good place to start to ensure it does not overtake normal trading patterns. This could be throttled up over time if it is successful. Same with the price cap I responded to in the above comment.

Why would it take over normal trading patterns? If this offer type is more difficult, more risky, and has lower limits, sellers will prefer to place the normal offer type. This leads me to think that the DAO might be required to incentivise sellers to create these onboarding offers. However, if this new offer type is implemented, it's worth testing how often it's used in the market before actually introducing this bounty. I think a first-time buyer will not care about paying for a price premium, even if it's a double-digit premium - which is the incentive for the market maker.

[dextertd]

First step in the process is the buyer revealing his/her account details to which the BTC seller sends an invoice

@dav1dpgit Could you clarify this invoicing process please? How would it work? Thanks.

[dav1dpgit]

Thanks. I think a limited number of offers (1 to 5 slots) per currency+settlement methodology isa good place to start to ensure it does not overtake normal trading patterns. This could be throttled up over time if it is successful. Same with the price cap I responded to in the above comment.

Why would it take over normal trading patterns? If this offer type is more difficult, more risky, and has lower limits, sellers will prefer to place the normal offer type. This leads me to think that the DAO might be required to incentivise sellers to create these onboarding offers. However, if this new offer type is implemented, it's worth testing how often it's used in the market before actually introducing this bounty. I think a first-time buyer will not care about paying for a price premium, even if it's a double-digit premium - which is the incentive for the market maker.

Thanks @dexter-2 , I agree overall with you on your perspective and happy to leave it to the implementation team as to if, how and when to set up limits and test those theories. We want to incentivise existing process flow over this flow, hence the limits.

[dav1dpgit]

First step in the process is the buyer revealing his/her account details to which the BTC seller sends an invoice

@dav1dpgit Could you clarify this invoicing process please? How would it work? Thanks.

I can detail on a payment mechanism-by-payment mechanism basis, but overall I see the flow as follows:

Nocoiner buyer identifies an onboarding trade on Bisq, lifts the offer which causes Bisq to automatically send the buyer's information to that seller for that specific payment mechanism (say for example, Revolut.)

The seller receives the buyer's details and goes to her app to find that buyer and send him an invoice to pay her (https://blog.revolut.com/split-bills-instantly-with-revolut/, https://blog.revolut.com/introducing-rev-me/, other settlement apps or processes follow the same concept but call it invoicing.) Buyer then confirms (in Bisq) receipt of the invoice in Revolut and makes payment to the seller.

Seller confirms payment of the cash and proceeds on through the normal Bisq settlement process.

[chimp1984]

Some feedback:

The security in that model would be based on the value the signed account has to the seller. This might be enough for certain amounts and payment methods. The Multisig is not needed as there is no mutual lockup (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). The Buyer need to trust the seller that his signed account is more worth to him to not scam the buyer. What happens if the seller does not send the BTC? Then his account need to be blocked which is a centralized feature and should be only used as last resort. 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. Could be also used for a sabotage attack (create many payment accounts, take all offers never pay, remove availability of those offers).

The price must be sufficiently higher to motivate sellers to make such small trades.

Restriction to one trade per new user is difficult and can only be applied to 1 trade per payment account.

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). I am not convinced that a sufficiently large group of users suffer from the no-Bitcoin problem as its quite simple for most people in most countries to get their first BTC (ATM, friends, meetups, vouchers,...).

[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.

[dav1dpgit]

BISQ should become the go-to place for bitcoin purchases for nocoiners.

More thoughts on the sabotage attack prevention where Sabotage attack defined as create many payment accounts, take all offers never pay, remove availability of those offers.

a) As mentioned before, initially limit the open offer count to make it a slow-moving attack lowering the time-spent value of attackers. b) Without a count limit, either separate-party vouching or requesting for transaction through a separate medium such as keybase #general room or reddit. c) This is more extreme but possible: Create a proof-of-work equivalent concept for nocoiners to require them to invest computing power before they can lift an offer. This could be a POW similar to bitcoin (much less difficult so that it can be done on a home machine,) or it could be a POW that is contributed to a 3rd party (charity, etc.)

a & b above are speedbumps to slow down sabotage attacks but not perfect. 'c', the last idea above, solves @chimp1984 comment about the buyer not having incentive to play to the rules. @chimp1984 , would you agree?

[MwithM]

c) This is more extreme but possible: Create a proof-of-work equivalent concept for nocoiners to require them to invest computing power before they can lift an offer. This could be a POW similar to bitcoin (much less difficult so that it can be done on a home machine,) or it could be a POW that is contributed to a 3rd party (charity, etc.)

Proof of work can be done with CAPTCHAs, just like bitcoin faucets do.

@chimp1984 said:

What happens if the seller does not send the BTC? Then his account need to be blocked which is a centralized feature and should be only used as last resort.

Could the lock only be performed for these kind of trades and not the whole Bisq ecosystem? Like different signing account mechanism that allows an old Bisq user to perform this trades, and that can be revoked. Anyway, if the incentives are good, blocking accounts would be rarely needed.

I think that this conditions make this kind of trading feasible:

1. Small amounts (just to cover onboarding fees and deposit) and on order per account limit.
2. Old time Bisq users value their account.
3. Captchas and measures to increase effort involved into taking orders.
4. Free prices. Is the only way new and old users can benefit.

[caveman1973]

There's a big problem allowing nocoiners to open transactions without penalties. You're allowing people (Tax agents) to start opening buy trades for free just to gather information from sellers. This problem is rampant in exchanges like LocalBitcoins.com (and probably on HodlHodl.com).

[dav1dpgit]

There's a big problem allowing nocoiners to open transactions without penalties. You're allowing people (Tax agents) to start opening buy trades for free just to gather information from sellers. This problem is rampant in exchanges like LocalBitcoins.com (and probably on HodlHodl.com).

@caveman1973 this does not open transactions to nocoiners without pentalties: Note that in this transaction flow the nocoiner buyer must provide their own information to the seller, not the other way around, so the seller's information is protected. If a nocoiner defaults, whether or not the buyer does so with legitimate or fraudulent information in their Bisq account that is provided to the seller, there is no loss to seller except time. The nocoiner loses time and, as proposed in the POW solution above, computational and electricity costs. I will add this in the original proposal so people do not miss this nuance.

I do not have stats on tax agents or other scammers on LocaBitcoins or HodlHodl. The POW proposal above should eliminate freeloaders, but I imagine that if tax agents exist that are able to requisition bitcoin from the government coffers and are already on Bisq; this proposal will not create more opportunity that does not already exist.

[mpolavieja]

Very interesting proposal.

I think that if the seller account is signed and the number of this kind of offers is limited per payment account, there is little risk that the sellers fails to send the BTC.

Captchas should be required before taking the offer, and maybe should be required again before retreiving the seller's invoice. An alternative to captchas would be to require a small down payment (like $2) through an unsecure payment method such as Paypal (associated to the seller's offer but not a Bisq payment account). As far as I know, only an email is needed to receive a Paypal payment, but this would make the trade probably too complex.

The seller should be able to withdraw from the trade before the buyer has confirmed he sent the payment if he sees the buyer is not responding swiftly.

if tax agents exist that are able to requisition bitcoin from the government coffers and are already on Bisq; this proposal will not create more opportunity that does not already exist.

Agree with the above. But I think that the risk of harvesting payment account information from sellers is probably the worst downside of this proposal. I wonder if Captchas before retreiving seller's invoice are going to be deterring enough, that's why I suggest the small down payment through Paypal or similar method.

Regarding UX, for the sellers I don't see a big problem as they are going to be experienced users. For the buyers, a setup wizard offering this path could dramatically improve UX.

[caveman1973]

I think it adds too much complication. Better send new users to Cash app (or similar) and buy $20 in BTC to be able to start using Bisq.

[dav1dpgit]

Thanks for the response, but the proposal is to solve for how to onboard nocoiners who don’t want KYC hurdles. NB: it will take minimum about 0.007 BTC to trade on BISQ, not $20.

[MwithM]

Closing as stalled.