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

[fareastbeach]

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'

[fareastbeach]

The system should probably also only allow a 'Taker' to avoid supplying a deposit, if they have less than the necessary deposit amount in their wallet. This is the normal case for someone trying to purchase XMR for the first time.

It also applies when a trader has emptied their wallet....but even in that case it prevents the need to have an extra Monero transaction on the bockchain just to return funds to Haveno.

[fareastbeach]

@monerobull has suggested that 'XMR exit' scenario (#2) is less important than the no deposit initial purchase scenario (#1). I agree. Since my main concern in suggesting this change is to remove an important barrier to using Haveno for people who wish to start acquiring Monero.

So I suggest any support for case #2 is deferred to some future date as separate issue.

[privacyOG]

Totally agree onboarding is very important for new users to Monero. I believe a limit should be put in place for such trades to say 0.4 XMR

[fareastbeach]

Totally agree onboarding is very important for new users to Monero. I believe a limit should be put in place for such trades to say 0.4 XMR

Having any system enforcing small limits to trade is a very political thing to do. So I disagree. It is the Maker that is taking the risk in this scenario .. a deliberate choice of risk on his part.

How is it anyone's business to dictate limits to his trading choices. As a similar example. currently HSBC UK limits customers to a maximum of £2500 to be sent to Kraken per month ... which is deliberately interfering with trading ... a real life example of political interference in money flows. Unofficial capital controls really

You are proposing a similar thing for the Haveno trading system for Monero - the global, sound money, private currency. The exact opposite of encouraging both freedom and personal responsibility for your actions (as a trader).

You also just say 'I believe ...' without providing any explanation of why you believe this is a good idea. Saving traders from themselves perhaps? Maybe they don't need or want your arbitrary controls. I sure don't want the HSBC limits, and the grilling they gave me when they instituted those limits - against my pre-existing setup of many years.

[monerobull]

Removing security bond already massively reduces the security of the trade. This feature is specifically for people who have 0 XMR and it is unlikely that anyone will buy large amounts when it's their first time buying.

Since it is specifically for the purpose of getting enough XMR for the security deposit, limiting the max amount makes a ton of sense. There is a reason why security deposits exist and we want people to use them.

Not requiring a deposit is enough of a compromise already, there is no good reason for why large amounts should be tradeable this way.

[fareastbeach]

While you are right that there is no good reason to trade large amounts without a security deposit, I object to just saying 'I believe .... [insert number] as a maximum no deposit purchase '

So what is a 'large amount' of a trade ? That varies from person to person .. from my days of using localbitcoins.com many trades were tens of thousands of USD in value ... and that was many people doing that. Escrow instead of security deposits so a different model. My first purchase there was several thousand GBP because I had experience with quite a few exchanges and had non-trivial trading intentions.

But there needs to be some discussion about the purpose and setting of a maximum no security trade value... since there is also a requirement that your wallet is empty to accept the no deposit trade, you need to buy enough to support the security deposit(s) for your next trades.- within the maximum trade limit of the system (528 XMR if I understand correctly). So 0.4 XMR is probably not high enough for next security deposit. (about USD 80 today)

If the initial purchase limit is too low, you are forcing people to go through several iterations of trade if they wish to get to larger amounts. Cumbersome .. for no particular reason .... but just like 'large' ...' too low' is a fairly subjective thing.

It is probably Ok, to have a limit if a purpose for the initial purchase limit is articulated AND

• the explicit limit is well documented
• the effect of the limit is explained
• the way you can 'bootstrap' that initial trade into obtaining larger amounts is also explained.

[fareastbeach]

Removing security bond already massively reduces the security of the trade. This feature is specifically for people who have 0 XMR and it is unlikely that anyone will buy large amounts when it's their first time buying.

There is no profile information about first time Haveno traders that shows that to be 'unlikely'. I suspect it is, but we really don't know and if you attract professional traders (compared to the current users) they will have much larger numbers in mind for trading.

Since it is specifically for the purpose of getting enough XMR for the security deposit, limiting the max amount makes a ton of sense. There is a reason why security deposits exist and we want people to use them.

THIS is a good description of the purpose behind setting an initial purchase limit as a refinement to the proposal goals.

I might add that the other limits to trading in the system, though documented a lot, are complex in detail when you first realise they are there and a bit frustrating.

[woodser]

If the initial purchase limit is too low, you are forcing people to go through several iterations of trade if they wish to get to larger amounts. Cumbersome ..

The limit is currently set to 0.5 XMR in #1463.

I'm fine to bump it to 1 XMR. After that I think the user can be expected to trade normally with security deposits.

[shortwavesurfer2009]

At 1xmr the next trade can be 4.98xmr with a 20% security deposit.

[privacyOG]

My reason for trading limit without any security bond as we are humans and we can make mistakes especially for new users to Haveno so a limit to trading without security is a protection not as you have put it "controlling mechanism".
What the chances someone going to trade 1 xmr and over without any form of protection for the trade chances are very little but it may happen and it could happen by mistake without releasing there is no protection in this trade.
Last thing we want for new users joining monero is getting ripped off for large amounts and Haveno networks are powerless to do anything about it and therefore turning off new users to Monero and creating negative ripple effect. We need people to trade using the security deposit model we have in place. My proposed 0.4xmr was just proposed figure 1 xmr might be a bit high but better than no limit.

[shortwavesurfer2009]

The seller's client generates a passphrase that has to be given to the buyer in order for them to be able to take the offer. I've seen the buyer screen where you are forced to enter the passphrase. At the current moment, there isn't a way for the seller to enter any kind of contact details that show up on the buyer's screen. So it has to be done through like the Reto chat. But otherwise, it does work. At least from what I can see.

[fareastbeach]

@shortwavesurfer2009 later discussions with @woodser drew out a fact that I was unaware of when I created this gitbub issue.

The design I laid out was intended to handle the authorisation of zero deposit Taker request when the Taker and Maker may not be online at the same time. Haveno does not support that situation at all. Both traders must be online for everything that Haveno does.

So the interaction can work as @woodser has coded it .. there is no need to show a screen of how the Taker can contact the Maker .. that P2P interaction can happen directly without using the network shared Haveno data.

perhaps there is a slight risk because the passphrase hash is in the shared network data, but that attack vector can not really be used as a denial of service attack, and any success at sneak authorising a trade can only trade 1XMR or less, the trades allowing no deposit will almost certainly be at an unattractive premium cost, and you still need to actually complete the trade anyway.

I have deleted the comment you responded to, because in the light of what I have just explained, it was not correct

[shortwavesurfer2009]

Correct me if I'm wrong, but wouldn't there still need to be a way for the taker to contact the maker through some sort of chat or email or phone call or something in order to get the password? Not everybody would be in the retoswap room, etc and even if they were, the maker probably wouldn't want to give out their password over that medium since somebody could come along and take the offer before the intended taker could do so. Therefore, unless I'm missing something, I would still see a need to have a way to contact the maker privately.

[fareastbeach]

Nothing prevents using other communication channels between the Taker and the Maker .... but I had proposed at way to show contact details as part of the process. That is not implemented ... it could be but it is not.