Testnet exchange

41

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.

42

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 … ?

43

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).

44

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

45

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

3 Likes
46

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

47

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