-
-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove security deposit for small amounts and/or trusted peers #999
Comments
additional justification why this should be in 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 |
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. 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. |
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. |
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.
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 |
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. |
i might be wrong but i think i saw something related to hidden offers somewhere Trade would go like this: Seller creates a 0% hidden offer, gives the trade ID to the buyer via some external channel. Since the offers are hidden, it is way less likely that someone random third party will grief them via coinlocking. |
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:
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.
The text was updated successfully, but these errors were encountered: