It sounds really like an online wallet.
1 Like
Agree, a pragmatic solutions is most needed right now. For that reason, would it not be most simple to pay someone working at an exchanges to actually build it?
In the end people working at exchanges best know the work and code flows that are used in practice. It would be ideal if there would be an enthousiastic Grin supporters working at an exchange who would be willing to build something like this both for the good of his or her own exchanges as well as for other exchanges and for the Grin ecosystem.
1 Like
So the conclusion of this discussion is to make a simple exchange with the GRIN-USDT as a first pair (better if it use USDT TRC-20). 
Galleon Rebirth
Grin Scratch Ex
I believe everyone is talking about a testnet exchange. You won’t be able to do any nontestnet stuff
1 Like
I fail to see why this testnet exchange would need a trading pair since that’s, at least from my understanding, just changing some values in exchange’s database. I would go with deposit and withdraw, since that’s the only thing where it communicates with grin node/wallet
2 Likes
I think an open-sourced online wallet , which support slatepack deposit/withdraw, is enough for an example.
exchange is too much for showcase and not quite specially relate to grin.
And Maybe I and my friend have time to implement it in the next month with grin fund support.
8 Likes
Custodial testnet wallet and faucet, so people can actually have some coins.
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
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 
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