Haveno trades for initial purchase using only fiat or complete exit into fiat
Summary

Haveno as currently designed requires a security deposit of XMR to allow arbitrated trades. This prevents two legitimate kinds of trades where the trader may not wish to have that deposit reserved.

The two scenarios are:
#1 - Initial purchase or XMR with fiat (Taker has no XMR to provide the deposit)
#2 - Trader wants to completely exit ownership of XMR (Maker needs to release all XMR in his wallet)

The first scenario actively reduces the usefulness of Haveno by adding barriers to new potential users. It is both complex and expensive to get some initial XMR from other systems just to be able to use Haveno.

A design extension can support both these scenarios without compromising the existing system.


Design enhancement details


Reason for the security deposit ?

It allows the arbitration process to have mandatory financial incentives that apply to traders forcing them to behave well, and strangles bot trading which could hurt the Haveno eco system.

But the system can be extended to allow individual traders to decide for them selves on a trade-by-trade basis whether they will accept a deal with someone not providing a security deposit.

It is pretty simple to implement to. The core extra data item that Haveno needs to (optionally) manage is a 'password' that can apply to trade to accept a deal. Haveno would only ever store a hash of the password - and validate when a password is needed by calculating the hash again from data entered and compared to the hash stored when the offer was created by a Maker.

So the process becomes.   Taker wants to accept an offer (Buy or Sell) and does not want to supply a security deposit... if the offer might allow that (IE has a password hash stored with the offer), the Taker is shown a text screen associated with the Maker, and asked to enter the 'password' for the offer.

That 'text screen' associated with the Maker has the details of how to contact the Maker to get the 'password' for this offer.  That contact process can be anything. It is not handled by Haveno.  It would normally be some well known P2P communications App ... but it could be writing a letter, sending email or making a phone call. That is all up to the Maker... and it remains up to the Maker to decide whether to proceed with trade without a deposit  ... if he does decide to continue, he provides the 'password' for the offer, and the Taker enters it into the screen.

At that point, as long as the password hash matches the offer password hash, the trade proceeds as normal, but with an extra workflow decision in each case.

For a Taker buying XMR who supplies a valid password, they can accept a sell offer which has an associated security deposit without supplying their own security deposit. They can NOT accept a sell offer which has no security deposit attached (exit XMR type of offer), unless they do provide their own security deposit.

For a Maker selling XMR for a complete exit of their XMR position, if they create that sell offer with a password hash, it must have a security deposit unless they elect to empty their wallet. 

So in all cases at least one of the traders is supplying a security deposit. This allows the usual arbitration workflow to continue unchanged ...

Offers to sell XMR with a 'password' hash AND a security deposit can (optionally) be taken without supplying your own security deposit (case #1).  No deposit requires you to supply 'password'. The Maker (seller) signifies that they accept the risk of trading with you without a security deposit by providing the password to the buyer

Offers to sell XMR with a 'password' hash and NO security deposit can (optionally) be taken if you supply the password (case #2). This shows that you have obtained the password from the Seller and you accept the risk of trading with them without a security deposit from them



Because the 'password' conversation is some arbitrary P2P interaction, no bot can ever abuse this style of trade.

There are some ease-of-use UI things that probably should happen too. 

- That 'text' to be entered by a Maker of each offer allowing no security deposit should probably have a default text stored/edited by the Maker as part of their profile
- for each offer, the Maker can just used the default text OR edit it for the specific offer being made


EDIT

**Haveno no security deposit passphrase.** 

Any possible trade which may be taken without supplying a security deposit is protected by a passphrase.  In discussions on Matrix it has become clear that all the processes around the passphrase need to be very clearly described.  So that is what follows.

Originally described as a password, @monerobull correctly said it is really more of a passphrase. Implicitly that means a much longer string of characters including spaces.  Probably words that are memorable to the the person creating it.

That describes the first attribute of the passphrase - a long string of characters


In these discussions, it seems a number of people assume that Haveno will store the passphrase. Absolutely NOT.
That is a security hole the size of the moon.  What Haveno should store is a one way hash of the passphrase - the algorithm I propose is SHA256 - because it is very strong and the code for it is already available and tested.

When the Maker creates an offer to sell XMR and wants to allow no security deposit Taker trades, they indicate that by entering a passphrase along with the other offer details. The SHA256 hash of the passphrase is what is stored with the other offer details.


_Passphrase rules._

Just like passwords, Haveno realistically should have some rules for what it will accept as a passphrase. The first is minimum/maximum length.  The second could be required minimum includes of members of certain character subsets (capitals, numerics, special characters).... the third is prohibited character strings... eg. repeating patterns, well known weak words. These rules help prevent a user from making themselves vulnerable to dictionary attacks. But for rules like - must have one Capital letter, one Lowercase, one numeric and on special character, these rules can annoy people.  We must strike an impossible balance here.  So this proposal is just an arbitrary set of rules to achieve a decently strong passphrase.

- Minimum length - 24 characters
- Maximum length - 256 characters
- No substring is a repeating string longer than three characters ... IE Abhhyy8888kdj$hh is prohibited "8888" is a repeating string that is too long. (test: for each 4 character substring .. can not be all the same)
- No substring is a incrementing/decrementing string longer than four characters ... IE Abhhyy12345kdj$hh is prohibited "12345" is a incrementing string that is too long. (test: for each 5 character substring .. can not be incrementing/decrementing characters)
- No substring can be a prohibited word .. just a small set of words should be ... like "paassword" the coders can add more at their preference
- Not an exact match for the generated hint just shown to the user (see following section)
- if the start of the entered passphrase is the same as the generated hint, the entered passphrase must be at least 8 characters longer than the hint.


_Generating passphrase hints._

Haveno can help the Maker create a decent passphrase, yet not be open to the attack that allows other people to guess the passphrase that is used. It can do this by generating a random base passphrase to be shown as a 'hint' during offer creation, but require that the hinted passphrase be amended on entry.

We can generate a reasonable password hint as follows. 
- create random 6 digit code
- use the BIP039 word table to select 6 words that reflect that random code
- display that set of 6 words as the passphrase 'hint'






