haveno-dex / haveno

Decentralized P2P exchange platform built on Monero and Tor
https://haveno.exchange
GNU Affero General Public License v3.0
1.03k stars 116 forks source link

Remove security deposit for small amounts and/or trusted peers #999

Open nihilist001 opened 5 months ago

nihilist001 commented 5 months ago

How about implementing 2:2 trades with no security deposit nor any arbitration, but ONLY for the peers that you trust:

by default you (bob) trust noone so you can only do 2:3 trades (as it is currently)

TRUST SETTING: 1) by default you trust noone unless if specified into YOUR trusted peer list 2) if chosen, you trust your trusted peer list and their trusted peers ? (idk if thats possible, ignore if not easy to implement) 3) if chosen, you trust everyone (very dangerous!)

scenario: if you're fed up with the security deposits, and you want to only transact with peers that you know are trustworthy, you can select to trust a peer (Alice) (identified by her .onion link?) and rename her with a nickname for ease of access, into a small contacts list (stored locally)

-and from there, you can create 2:2 offers, that don't appear to anyone unless if they trust you.

-so Alice and you are friends, she also marked you as trustworthy and she sees the 2:2 trade offer appear

-of course make sure that these trades appear in bright red with a warning saying it's dangerous and the haveno network cannot help if you are being scammed, that since YOU CHOSE TO TRUST the peer, nothing (no security bond, no arbitration) can protect you from any scam attempt.

That could be a direct fiat->XMR onramp without requiring any initial monero, which works if you have a friend within the monero community, on haveno.

TLDR: you dont need arbitrators, and no security deposit in the context where you manually choose to trust the other peer and that other peer trusts you too

EDIT as of 25/06/2024: the main goal is to have a way for Bob to get monero on haveno without having monero in the first place. Meaning the idea is to have a possibility to have a 0% security bond in a trade.

I think a valid context for this kind of trade is when Bob trusts Alice IRL, and he added her as a trusted peer in his haveno dex (and alice also added bob as a trusted peer!), and for her specifically he can do 0% bond trades.

does not matter if this is a 2/2 trade or 2/3 trade setting, as it's much easier to implement in a 2/3 setting.

nihilist001 commented 5 months ago

additional justification why this should be in haveno: 1) to do it in a decentralised P2P way, people shouldnt be forced to go on telegram or on a chatroom 2) to make sure trade shows up in the stats with the other trades 3) so that it shows up in bob and alice's list of trades on haveno

in the case where you have 10 friends from previous CEXs, you trust them all, and you can put an offer 2:2 that only them can pick up, thats also made easier by haveno

preland commented 5 months ago

I like this idea, although I think it should also be possible to have a version of this where each party is covered with a 100% bond;

Let's say that Alice and Bob don't trust each other that much, actually. However, they are both willing to accept the risk of a "stubborn parties" situation (more on that later), and are willing to transact. Both Alice and Bob create 2:2 with each side putting forward 100% collateral. Then Bob sends payment to Alice, Alice sends payment to Bob, and all is happy :)

If things are not so happy, that can get resolved. Let's say that Bob sends to Alice, but Alice does not send to Bob for some reason. In that case, then Bob will refuse to resolve the issue until either Alice pays up, or Alice agrees to release their side of the 2:2 bond. This gives little to no incentive for either party to scam the either, while also not giving one side power over the other (the most one party could expect to gain would be nothing, but the most one party could expect to lose would also be nothing, as if they scammed and released 2:2 they would still be breaking even).

There are many caveats to this system. For one, if one or both parties refuse to settle, then you get a "stubborn parties" situation, where the bond is effectively considered lost as neither party will settle the transaction. It should also be noted that this transaction method assumes that the value of the assets traded (ie XMR and fiat for most) remains stable throughout the course of a transaction, or that price volatility is reflected somewhat in the "premium" of a transaction. If this assumption is false, then a party could intentionally behave stubbornly in order to capture an arbitrage opportunity. It should also be noted that any loss in the middle of a transaction (ie payment is "lost in transit") would not be covered by the bond. If this were to occur, then both parties would receive their bond back, and the party that send the funds would bear the cost of the loss.

This comes to a larger issue with transactions in general, regardless of method (centralized, decentralized, arbitrated, trusted, untrusted, or otherwise): There needs to be a reasonably immutable proof of sent/receipt (S/R). In other words, if Bob sends funds, Alice should be able to know that the funds were in fact sent, and that Bob isn't secretly holding the funds, or has fabricated the payment in any way. Examples of such fabrication would be not giving correct tracking information, lying about the nature of payment in some way, or giving payment with the intent to "chargeback" payment after a transaction has ended. The capability to prove that funds have been sent is proof of sent. Conversely, Alice must be able to know that Bob has received payment, and that Bob can't pretend to not receive payment after receiving it. Examples would be claiming that funds were never sent, that the amount sent was incorrect, that the payment was reversed or cancelled without it actually being the case, or any other method that would imply to Alice that Bob has not been fairly compensated. The capability to prove that funds have been received is proof of receipt.

Perfect PoS/R is impossible to have. Trustable PoS/R is very difficult to have, but it can be done. It should be noted that, when you look deeper, many of the issues that exist with the 2:2 transaction I have introduced are also present in effectively all transactions. Sometimes the peers you trust turn out to be untrustable. Sometimes the arbitrator makes the wrong decision, or finds a way to conspire against you with the other party. Sometimes the bank is closed, or the eggs you bought at the supermarket are already spoiled.

Airtight transactions aren't the goal; reasonably secure and trustable transactions are the goal, alongside education of the risks associated with transactions in the real world.

preland commented 5 months ago

Addendum (sorry about that rant up there, I couldn't find a better way to shorten it): It should be noted that the risks of 2:2 will be unacceptable for certain forms of payment, especially those involving large payment amounts (which has been pointed out to be necessary for certain types of payments). As such, 3:2 should always be left as an option alongside 2:2. While this will have the unfortunate side effect of decreasing the liquidity for some transactions, the benefits should greatly outweigh the downside.

nihilist001 commented 5 months ago

Sometimes the peers you trust turn out to be untrustable.

that can just be displayed as a warning: "warning: you decided to trust peer dwawd.onion, if you create a trustless transaction, no arbitration can come to save you! click cancel to keep arbitration with that peer!" as long as the user is aware of the risks and accepts them, you (as a haveno network admin) shouldnt' bother with the outcome if a scam happens as it's the users' fault for trusting someone that turned out to be a scammer. So yea, definitely keep the 2:3 trades with bond as default.

It should be noted that the risks of 2:2 will be unacceptable for certain forms of payment and certain amounts too! but that will be at the discretion of the peers that decide to trust each other. And yes 2:3 trades with bonds should always remain the default option in case if you don't trust Alice.

imo this solves the issue of "bob has no monero to get his first monero" if alice is his friend. He doesn't need to buy monero elsewhere, it's all possible on haveno

nihilist001 commented 4 months ago

Just to clarify after discussing this with Woodser:

the main goal is to have a way for Bob to get monero on haveno without having monero in the first place. Meaning the idea is to have a possibility to have a 0% security bond in a trade.

I think a valid context for this kind of trade is when Bob trusts Alice IRL, and he added her as a trusted peer in his haveno dex (and alice also added bob as a trusted peer!), and for her specifically he can do 0% bond trades.

Now as woodser pointed out, 2/3 may still be a valid option in case if the coins get locked permanently, plus it's probably much easier to implement.

In any case, if it's easier to implement it in a 2/3 trades, fine by me.

Later on if it is possible to transact in a way where there is no need for arbitrators (2/2) let's go for it, but it may require more effort to implement.

monerobull commented 4 months ago

i might be wrong but i think i saw something related to hidden offers somewhere could be bisq wiki, could be a random commit if hidden offers are a real thing and they work by looking for offer IDs specifically, that would be a decent feature with only little tweaking required for example: people could post trade IDs with 0 bond"get first xmr" room, ex LM traders can keep their reputation and chat with people via telegram or whatever but the buyers still have the escrow security this has a lot better UX than manually adding someone to your "trusted peers" since the data exchange needed before a trade is now one-way. A new user just needs to input data, not export anything that then needs to be re-imported by the seller.

Trade would go like this:

Seller creates a 0% hidden offer, gives the trade ID to the buyer via some external channel. Buyer enters the offer ID, takes the trade, everyone happy.

Since the offers are hidden, it is way less likely that someone random third party will grief them via coinlocking. This should drastically decrease abuse of the missing taker bond as a DoS vector.