search

AthanorLabs / atomic-swap

💫 ETH-XMR atomic swap implementation
GNU Lesser General Public License v3.0
344 stars 44 forks source link

add pairs #495

Closed stubbrn closed 1 year ago

stubbrn commented 1 year ago

Ability to select Pairs

Just a mockup for now, as the logic of the future "getPairs" RPC endpoint requires to know whether there's a "hard" whitelist or not (as discussed in #491 and #178).

pairs pairs2

codecov[bot] commented 1 year ago

Codecov Report

Patch coverage: 18.97% and project coverage change: -0.61% :warning:

Comparison is base (f7c6a1d) 61.02% compared to head (8f93cb6) 60.42%.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #495 +/- ## ========================================== - Coverage 61.02% 60.42% -0.61% ========================================== Files 129 131 +2 Lines 12817 12952 +135 ========================================== + Hits 7822 7826 +4 - Misses 4176 4303 +127 - Partials 819 823 +4 ``` | [Files Changed](https://app.codecov.io/gh/AthanorLabs/atomic-swap/pull/495?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None) | Coverage Δ | | |---|---|---| | [common/types/pairs.go](https://app.codecov.io/gh/AthanorLabs/atomic-swap/pull/495?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None#diff-Y29tbW9uL3R5cGVzL3BhaXJzLmdv) | `0.00% <0.00%> (ø)` | | | [rpcclient/pairs.go](https://app.codecov.io/gh/AthanorLabs/atomic-swap/pull/495?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None#diff-cnBjY2xpZW50L3BhaXJzLmdv) | `0.00% <0.00%> (ø)` | | | [rpc/net.go](https://app.codecov.io/gh/AthanorLabs/atomic-swap/pull/495?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None#diff-cnBjL25ldC5nbw==) | `47.89% <5.45%> (-17.55%)` | :arrow_down: | | [cmd/swapcli/main.go](https://app.codecov.io/gh/AthanorLabs/atomic-swap/pull/495?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None#diff-Y21kL3N3YXBjbGkvbWFpbi5nbw==) | `48.84% <35.00%> (-0.52%)` | :arrow_down: | | [rpc/server.go](https://app.codecov.io/gh/AthanorLabs/atomic-swap/pull/495?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None#diff-cnBjL3NlcnZlci5nbw==) | `77.20% <100.00%> (+1.42%)` | :arrow_up: | ... and [12 files with indirect coverage changes](https://app.codecov.io/gh/AthanorLabs/atomic-swap/pull/495/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

dimalinux commented 1 year ago

Since this PR is not linked to a well documented issue, can you provide more documentation in the PR description.

Describe:

There are lots of images that are imported. Can you mention where they came from and what their copyright is?

stubbrn commented 1 year ago

The use case that the PR is trying to solve

Providing a RPC endpoint, a swapcli command, and a UI to see Pairs. It wouldn't be a good UX on the UI to mashup all offers from all assets into the same table (If you have a decent amount of offers); This is a first version to segment offers from all peers by asset.

What a pair is

A pair is simply an abstraction over offers (a summary), it doesn't contains any offers, just metadata about them, grouped by assets. For now, it isn't stored/cached anywhere, just generated on the fly when the Pair RPC endpoint is called.

Example output of swap-cli pairs:

Pair 1:
  Name: ETH
  Token: 0x0000000000000000000000000000000000000000
  Verified: Yes
  Offers: 2
  Liquidity XMR: 220
  Liquidity ETH: 5.50

Name: Name of the asset Token: Address of the asset Verified: Whether the token is in the verified-list or not (Not implemented yet, that will be for another PR, always set to false, unless its ETH that's always set to true) Offers: The amount of offers with that token Liquidity XMR: The sum of Max Amounts of offers (of that particular asset) [How much you can get at most from all offers from a particular asset in XMR] Liquidity ETH: Same thing but converted in ETH/Token [How much you can get at most from all offers from a particular asset in ETH/Token]

What follow-up work is needed to make this PR useful.

None

It sounds like it depends on a whitelist. Describe how you think we should solve that problem.

It doesn't depend on it, it's just that for now it's always set to false unless it's ETH.

There should be a verified-list somewhere, that is parsed by swapd. The goal is to warn the user to double-check addresses. Ability to change this list from the UI directly could be considered from the very first implementation.

Asset Images

https://github.com/spothq/cryptocurrency-icons/blob/master/LICENSE.md

dimalinux commented 1 year ago

Let's say someone makes the following absurd offer with a 2 million USDT to XMR exchange rate and half of a monero being offered up.

$ ./bin/swapcli make --token 0xdAC17F958D2ee523a2206206994597C13D831ec7 \
    --min 0.12 --max 0.5 --exchange-rate 2000000
Published:
  Offer ID:  0x20739776aae60ad00d7591165ef8efbbbec34b07d137f3a48169a1a234621194
  Peer ID:   12D3KooWQQRJuKTZ35eiHGNPGDpQqjpJSdaxEMJRxi6NWFrrvQVi
  Taker Min: 240000 "USDT"
  Taker Max: 1000000 "USDT"

Would this PR then report that there is a million dollars of USDT liquidity in the network?

stubbrn commented 1 year ago

Would this PR then report that there is a million dollars of USDT liquidity in the network?

Yes, and if you put something absurd for XMR you get something similar as there's no proof of funds for creating an offer.

If you don't like it we could:

dimalinux commented 1 year ago

Let's see what @noot or someone else thinks. Are there any exchanges that print numbers like this or that have similar concept of what "liquidity" is? At least if end users are using our software, they can't offer up more XMR than they have. Offering up exchange rates that are extremely far from what anyone would take at the moment is 100% guaranteed to happen. I've never seen it not happen on any platform. I don't think having a single offer that is legit but absurd affect a network wide statistic is desirable behavior.

noot commented 1 year ago

@stubbrn sorry for the late response. overall, I like the idea and I think it helps give a nice snapshot view of the network. but yeah, false liquidity reporting would be an issue. we could change the definition for now to say "reported liquidity" or something like that? I've thought a bit about how to add proof of XMR liquidity (#75) but there are still issues, as the maker can just transfer their funds to another account or something after sending the proof. I think for now, potentially changing the definition/adding a specific definition would be good.

stubbrn commented 1 year ago

Ok, so I'm probably going to:

If we're able to solve the problems with XMR proof-of-reserves, they could also maybe serve as part of heuristics for attempting to prevent false offers spam (you won't be able to just buy/borrow IP addresses for $10 or maybe less with tor exit nodes + generate PeerIds and cancel everything after step 1 of the protocol, as a taker could potentially see that N different makers have the same proof, so it would be more difficult to spam, although if you need to take the offer to be able to see it it wouldn't work), but that's outside of the scope of this discussion