# An open discussion on Non-interactive transactions

**URL:** <https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510>\
**Category:** Development and Technical Discussion\
**Created:** [March 3, 2021, 5:16am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510 "2021-03-03T05:16:51Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\
**Post date:** [March 3, 2021, 8:15am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/2 "2021-03-03T08:15:32Z")

</div>

No cryptographer here, but what I think is the most realistic approach is to use some modified stealth transactions (Diffie Hellman) as Tromp and others discuss here and in many other posts, se the bottom of this linked post for all links:

> [@Eliminating finalize step ReLoAdEd](https://forum.grin.mw/t/eliminating-finalize-step-reloaded/7817):
>
> Recently, @david proposed the seminal idea [1] to use a signature scheme (for our kernels) that would remove the need of the last communication round, making potentially (if we can find a secure scheme for that) Grin transactions quite more user-friendly. He proposed that the sender would deterministically generate the partial excesses and nonces for the receiver. Later in the thread, I proposed a detailed scheme bringing into practice this idea, in particular by using ideas from the Stealth Ad…

Or Mingle Jingle:

> [@Minglejingle: Scalable blockchain with non-interactive transactions](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288):
>
> Feel free to review and comment. Should be relevant since discussions about non-interactive transactions have taken place here in the past.

A second approach which is a more wallet based, is to use HD wallet key derivation to generate and share derived public key m’/44’/Use/n. E.g. The exchange can use this derived public key to derive more next level public keys with an exchange to allow one sided transaction for that exchange. For each such gateways a separate use key is shared derived from a hardened ancestor from which children keys can be derived. Such transactions are probaly not private, so their only use is to facilitate communication with gateways, e.g. exchanges and mining pools to stubborn to implement slate packs.

The added advantage of having transparant gateway transactions would be that they make Grin complient with government rules for having KYC endpoint for the receiving wallet. From there on, the user can obsfuscate all transaction that come in by sending the funds to him or herself using normal Mimble Wimble transactions, so the privacy leak is not that big. Because such transactions are not normal Mimble Wimble transaction they could be put in a side chain, extention blocks, or possibly a whole separate Grin-Gate or Grin++ chain that preferably shares its proof of work with the Grin main chain. The idea is that only a fraction of the transactions, e.g. 5-10% would be these kind of transactions. I am only not sure if such an approach could be linked to normal Mimble Wimble transactions, e.g. by burning on the main chain and creating on the side chain with the proof that all coins are togther equivalent to (time-(time0+1))\*60. To avoid slowing down validation on the main chain, maybe the total amount of Grin on the side chain can be put in each block header of the main chain.

Now again, not cryptographer here, so probably the above solution is not even technically possible or making sence 🙃.

---

_[View the full topic](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510)._