Testnet exchange

I’d rather see a darkmarket beta test

1 Like

I think Ironbelly/grin++ are both open source and supports slatepacks. Did you have anything specific in mind?

I think it’s a good question how close we can get with send/receive and deposit/withdraw.
I think there are a few differences between a wallet send/receive and an exchange deposit/withdraw. An exchange will likely use SRS flow for withdrawals and RSR for deposits. Why? Because it avoids possible problems with the user not broadcasting the tx for whatever reason. Using these flows also helps the exchange not needing to lock the inputs in case we ever get payjoin deposits (for whatever reason we might want this). Another thing is that we don’t really know what problems exchanges are facing e.g. things like this Node API (3413) becomes unresponsive while compressing txhashset_zip · Issue #3550 · mimblewimble/grin · GitHub which may go unseen for a regular user with a wallet but become very visible for a poweruser. All the errors that happen at every 20th send/receive attempt might look good enough for a user, but exchanges would be getting frustrated if they had to do them more frequently.

I mean Custodial web testnet wallet, most like a exchange wallet without exchange function

2 Likes

This is a great idea! At one side, a testnet exchange should help to simplify the adoption of grin’s transactions by real exchanges, while at the other side it could provide the base code to build an exchange in the future, if the current exchanges would not integrate grin.

It’s true, we have TO and it’s good (for me it worked well)!
However, it has be be recognized that for now, it has not the same level of trust of bigger exchanges, neither the same levels of liquidity (compared to other pairs in other exchanges).

And even though it gets big and trusted enough, or other exchanges would finally adopt grin, I am concerned on what would happen if regulators become more restrictive and start pressing for KYC or start to scorn privacy coins, urging to delist them (in a similar way as bittrex).

In that case, maybe, the more viable solution will be to be listed on bisq, or maybe it will be more worthwhile to continue with the software built for grin’s testnet exchange, starting to think of a way to decentralize it.

I don’t know, but talking about decentralized exchanges, I think that privacy of developers and users is one of the keys and I think that this could possibly make grin one of the first movers in the future.

2 Likes

I’ve been trying to get some answers from Bisq without succeed.

Maybe we should wait until grin’s slatepacks become generally interiorized as a standard. In the meanwhile, we as a community, could open a thread collecting the more important information needed to be listed on bisq and the strenghts of grin.

When it’s the time we could collectively prepare an orderly request and each grinner that it’s interested could send it to bisq’s developers. We should also make a donation with the letter, say 10 grins each (or more for who wants), to apologize for the inconvenciences created in the beginning.

Bisq is the only one for which I would recommend doing this, because, for other exchanges, I would like them to ask the community if they can list grin :smiley:

Before you can start trading on Bisq, you’ll need a little bitcoin for a security deposit and fees (0.01 BTC should be enough). Each trader must lock bitcoin in a multisignature escrow until the trade is complete—this is part of what makes trading on Bisq highly secure.

I would not pay for that. (Expensive)

It’s better to use TradeOgre even though I can only buy and sell in small number. For information I have filled out the application form for TradeOgre to list USDT

Should be dirt-cheap on lightning or immediate payment channel to Bisq,
except for the one-time channel opening.

I would like to create a simple testnet exchange (withdraw/deposit) but would like to know what’s expected from the final product

2 Likes

Probably the answer will differ per person here on what they would like to see, this is what I think would be important.

  • Testnet exchange should be compatible with the workflow of real exchanges, e.g. by turning on the option mainnet, they should be able to use the code with minimal modification to implement Grin on their own exchange.

  • Should work as a minimal online wallet showing Grin saldo of the user. Users should be able to test receiving and sending coins from testnet to their own wallet.

  • Should work with slatepacks, e.g. showing the slatepack when logging in on the online exchange account. This is important since an easy to implement testnet exchange should empower real exchanges to implement slatepacks

  • Preferably this project should involve some exchanges since there is no other way to know what exactly is their current problem with implementing slatepacks. Pobably the problem is that reaction can bounce since they are interactive, meaning they need some queing mechanism, would need late locking and.

Probably others can better formulate a requirements list, but this is what comes to my mind.

1 Like

maybe someone can dm Tradeogre so he can create one and for sure he have experience

Is there any progress on this idea?

this doesn’t work if 2 services want to create a transaction (eg. from one exchange to another) since automated service (eg. exchange) can only perform steps 1 and 3, so when 2 exchanges want to create a transaction no exchange knows how to do step 2. You could add additional feature (so that exchange could perform step 2) or have the same flow for deposits and withdrawals. The latter is probably the way to go, so either both should use SRS or both should use RSR. Since having permanent addresses can lead to attacks (with auto-receive i can size-spam your node, with manual confirmations i can additionally make your “transaction inbox” huge) i hope we get some sort of ephemeral addresses (one-time addresses or per-user or smth like that). However this would mean that SRS becomes RSR and vice-versa (haven’t really though that much about that). So imo we should first figure out ephemeral addresses. Imo we should not think of exchange as being an exchange but rather just a service to which you can pay or which can pay to you (so exchanges, shops etc) since it’s more abstract and we should come up with this general solution that would work for all of them

1 Like

If you find some time, it would be great to write these ideas down. It would be a shame for new people thinking about this to go through the same steps again because we didn’t do that. What I have in mind is a document that would answer these two questions:

  1. Why we might want to have the same flow on both sides?
  2. Why we should abstract exchange and instead think of receive/pay flows as separate? (exchange uses both and calls them deposit/withdrawal while a store uses only one)
  3. Why it might make sense that the chosen flow is RSR?
  4. Why ephemeral addresses might flip SRS and RSR flows?

I’m willing to help discussing/researching this. No rush though.

I think this is something that I can assist you with working out. Would the objective of the document be summarised as an asset that can shared with exchanges, wallet devs, et al. business to 1)gain working knowledge of the grin tx.flow and 2)provide this asset in a clear and concise way as to facilitate better 3rd party dev support … ?

Probably more of a suggestion what could be implement if people would find it a good path. Most of it would be a research that takes quite a bit of time to do. Only when it is implemented, tested and agreed on would I share it with exchanges. Likely a multimonth project for volunteers given the current pace and free time (this doesn’t include code).

which method is more robust for shop merhcant integration? rsr or srs?

There are advantages to the shop finalizing the payment, to minimize uncertainty of the status of payment. Which is RSR.

3 Likes

in this situation ,can shop/merchant implement RSR at base layer or Grin needs hf or softfork for this ?

Transaction building has nothing to do with the chain itself. The chain only understands a complete transaction. It doesn’t care if you created it via SRS, RSR or some other method.

2 Likes